# Registration

> Tag 3: the server asks the client to register the container, carrying the run’s id, the dependency tool templates the program declared and the secrets it takes, each by name to its mode, verbatim; the client answers with exactly one channel response, deployed with the secrets’ first values or an error, and the channel response finish; the server feeds the values to the container before it sends the id, and anything but a deploy and a feed is the run’s error.

Canonical: https://protocol.diverge.network/2.3.0/endpoints/containers-agents-run/server/registration/
Specification revision: 2.3.0

The server opens this channel when the `Begun` the proxy answered its
begin with carries one or more dependencies or one or more secrets:
the tool containers the container's program declared when it was
registered, each as a dependency tool template, which the client
deploys and serves to the container under the template's id; and the
secrets the program takes, each by name to the mode it takes it in,
whose values the client supplies. The client's answer decides whether
the run goes on, and carries the first values of the secrets.

- **When.** After the begin has been answered and before the id is
  sent, beside the FUSE mounts. Exactly once per run, and never on a
  connect scope. The server opens no registration channel when the
  list of dependencies and the declaration of secrets are both empty,
  and feeds nothing to such a container.
- **The id.** The server mints the run's id before it opens the
  channel, and enters the container among those it runs before it
  asks: a [containers::fuse_serve](/2.3.0/endpoints/containers-fuse-serve/) naming
  the id is answered while the channel is open, which is how the
  client serves the container's paths into the dependencies. The id
  the request carries is the id the server sends as the response
  after the channel has ended and the values have been fed, and no
  other. The container is listed by nothing and found by no connect
  before the response: an agent container is never listed and never
  connected to.
- **The request.** The tag byte `3` followed by the run's id, the
  dependencies and the declaration as JSON.
  [Request](/2.3.0/endpoints/containers-agents-run/server/registration/request/) states its form.
- **The response.** Exactly one channel response, deployed with the
  values or an error, and the channel response finish.
  [Response](/2.3.0/endpoints/containers-agents-run/server/registration/response/) states the sequence.
- **The feed.** When the answer is the byte `0`, the server opens
  exactly one [secrets](/2.3.0/container-proxy-endpoints/agents-begin/client/secrets/)
  channel on the begin scope of the container's proxy, carrying the
  values the answer carried, verbatim, and reads its answer to its
  finish. The proxy's `Fed` lets the run go on to its id. The proxy's
  error, and a channel response finish that no channel response
  precedes, are the run's error: the server stops the container. The
  server sends the id only after `Fed`.
- **Verbatim.** The server relays the list and the declaration as the
  proxy sent them and the values as the client sent them, and reads
  none of them: not the kind, not the scope, not the mounts, not the
  secrets' names, not their modes, not their values, not the
  permissions.
- **Two kinds.** A template's `type` is `transient` or `service`. A
  transient tool is deployed for the one run of the one agent that
  declared it and stopped with that run; its database scope is that
  agent's alone; it alone may name the agent's files and directories
  as mounts. A service is made once, under the scope key its `scope`
  names — the agent, the agent's template, or the template alone —
  and kept by the client from then on, started again whenever its
  container ends and at every start of the client's, for as long as
  any agent is attached to it: an agent is attached by a
  registration that declares the template and detached by one that
  no longer does, and a service no agent is attached to is retired
  by the client after its idle time. A service names no mount, and
  its database scope is shared as far as its scope says.
- **What the client does.** The client runs each dependency as a
  [containers::tools::run](/2.3.0/endpoints/containers-tools-run/) from
  the template's `image`, `memory`, `disk` and `arguments`, with the
  template's id as the run's `template`; answers the tool's own
  registration with values for the names the tool's program
  declares, each resolved through the vault key the agent the tool is
  deployed for binds the same name to; serves, for a transient tool,
  the agent container's paths the template's mounts name into the
  tool container live, as [containers::fuse_serve](/2.3.0/endpoints/containers-fuse-serve/)
  serves them and a FUSE mount of the tools run mounts them; gives
  the tool the database scope its kind names and an account holding
  the template's `permissions`, within which the word `self` reaches
  the agent a transient tool was deployed for and every agent
  attached to a service; and serves the tool to the container under
  the template's id among the MCP servers the client answers the
  container's tool calls with. For the container's own secrets the
  client answers, under every name the declaration carries, one
  value: for a `rotating` name a value it locks to the container
  until the loop's `Inactive` hands it back, and for a `fixed` name a
  value it reads and never takes back. A tool container declares no
  dependencies of its own, and makes no tool call outward.