Connecting an agent that brings its own tools

Some agents do more than read and write a container. When you connect them, they install a manifest: their own custom tools, the kinds of records they declare, and small functions they run on their own server before or after a tool runs. Wire shows you all of this before you approve, and lists it on the container afterwards.

This page covers what the connect screen shows, what each data flow means, how an installed agent is updated, and how to take an agent back out. If you are building an agent with a manifest, see the Wire SDK.

Who can connect one

Connecting an agent that adds tools needs admin access to the container. Installing decides which servers the container may call on your behalf, so it is the same level of access that turns tools on and off. The connect screen lists only the containers you are an admin of. You can also create a new container for the agent, named after it, and you are its admin.

Access limited to specific tools is not enough, even at admin level, because an agent’s tools can run tools outside that list.

What the connect screen shows

Everything on the screen comes from the agent’s registered manifest, checked by Wire. You approve that exact version: if the agent publishes a new version while the screen is open, approving is refused and the screen shows the new one.

Section	What it tells you
It manages this container	That the agent will decide the container’s tools and analysis while it is installed, what you can’t change until you uninstall it, and what stays yours. See An agent manages its container
Tools it adds	Each tool by name, the built-in tool it runs, whether that tool writes to your container, and whether the tool is on when installed and over which connections (MCP, REST, or both)
Actions on the agent’s server	Each function the agent runs, the host the container will call, the agent’s own description of it, and its data flow in plain words
Kinds of records it declares	The objects it writes, with their fields
Built-in tools it keeps	Built-in tools the agent can use beside its own
Wire’s built-in tools	Which of Wire’s own tools the agent hides from your other agents, and any it turns on, for example “Turns on SQL queries (wire_query) over MCP and REST. It runs read-only SQL over your container’s records.”
Analysis it sets	Which analysis graphs (analysis) the agent turns on, with what each costs per entry written, and which it turns off
What it tells your agents	The skill the agent adds (usage guidance your agents can read when they use the container) and the instructions they get when they connect. Read the skill and Read the instructions show the agent’s text exactly as written, before you approve
This agent ships an interactive view	Each interactive view the agent ships: its name and size, which tools show it, every domain it may contact or load from (grouped as network access, resources, frames, and base URL), and every permission it asks for, such as your location or camera. Source shows the view’s code as read-only text. The screen never runs it
Cost	Action calls are free. Each of the agent’s tools costs what the built-in tool it runs costs

For an existing container, the screen also says whether a version of the agent is already installed there (approving updates it) and whether any tool names clash with tools already in the container. A container that a different agent manages can’t be chosen: the screen names that agent and asks you to uninstall it first or pick another container.

When approving updates an installed agent, the screen lists first what the new version changes: tools that become available, new connections they are available over, new things a tool can do, built-in tools it now hides or turns on, analysis graphs it turns on or off, a skill or instructions it adds, changes, or removes, and interactive views it adds, changes, or removes, with each new domain or permission a view asks for on its own line. An agent is only ever updated when someone approves the update, on this screen or in the Wire dashboard. See Updating an agent.

What an agent tells your agents

An agent can give the agents that use its container two kinds of guidance:

• A skill: a usage guide in the Agent Skills format, which the container serves as skill://<name>/SKILL.md. MCP clients that support skills list it and load it when it’s relevant. Any client can read it as an ordinary resource.
• Instructions: a short set of rules every MCP client receives when it connects to the container, for clients that don’t read skills. An agent with a skill and no instructions has its clients pointed at the skill instead.

Reading a skill is free. It isn’t a tool call and it isn’t a file download, so it never costs credits. The skill isn’t stored as entries either, so searching, exploring or querying the container never returns it. It’s part of the container’s setup, and it stays with the container, including in copies.

Interactive views

An agent can ship interactive views with its tools, such as a map of the places a search found. AI clients that support MCP Apps, including Claude (web and desktop), ChatGPT, VS Code, and Goose, show the view next to the tool’s result. Other clients, such as terminal agents, show the tool’s text result, which every tool with a view still returns.

A view runs in a sandbox in the client that shows it, and it can reach only the domains the connect screen lists for it. It gets the tool result the agent already saw, and it can call the agent’s tools back over the same connection. Loading a view is free: it isn’t a tool call or a file download. Disconnecting the agent keeps its views, and uninstalling it removes them. For how to build one, see Interactive views (MCP Apps).

What the agent can see about the connection

Every agent you connect can see the container’s name, whether its connection is still active, and which version of the agent the container runs, from its own server, without holding your key. That is how an agent can show “connected to Places” on a later visit, with a link back to the container in Wire where you manage it. It never sees the container’s contents this way, or your email or account.

If the agent asks to be notified, the connect screen also says so: it hears when you connect, disconnect, or uninstall it, and when the container is claimed, expires, or is deleted.

An agent can uninstall itself from a container too, for example when you remove it from the agent’s own settings. That is the same as choosing Uninstall here, and your data stays.

An agent manages its container

Installing an agent’s manifest hands the container’s tool setup and analysis to that agent. Agents that add their own tools usually do it so every agent connected to the container sees tools shaped for one job instead of Wire’s general ones, and that only works if the installed agent decides the whole tool list.

While the agent is installed, including when it is disconnected:

• The agent decides which tools every connection sees. Its own tools, and Wire’s built-in tools, are on or off as the agent sets them. You can’t turn any tool on or off from the container’s Tools page.
• Custom tools are locked. You can’t create, edit, or delete custom tools. Custom tools you made before the install are kept, but no connection can see or call them until you uninstall the agent.
• The agent decides the analysis. The entity graph and the provenance graph are on or off as the agent sets them, and you can’t change them in the container’s Analysis settings.
• One installed agent per container. Installing a different agent’s manifest on the container is refused until you uninstall this one. The same agent can still update.

These stay yours the whole time: sharing and access, API keys, the container’s name and description, pausing, and deleting it. The Tools page and the Analysis settings say “Managed by” the agent, and link to its entry under installed agents.

Uninstalling the agent gives you control back. Wire’s built-in tools go back to their defaults, both analysis graphs go back on (the default for a container), your own custom tools come back, and you can change all of it again. Nothing in the container is changed or removed by any of this: entries, relationships, and files stay.

Hiding a built-in tool only hides it. An agent’s own tool still runs the built-in tool it is built on, so an agent can hide wire_write and still save records through its own tool.

Tools an agent turns on

An agent can say which of its tools are on when it is installed, and whether each is available over MCP, REST, or both. Installing applies exactly that, whatever state the built-in tool underneath is in. The connect screen says it for each tool, for example “On when installed, over MCP only.”

This matters most for a tool built on a built-in that is off by default. An agent’s tool that runs wire_query can be on even though wire_query itself stays off for everyone else. The screen then says plainly that the tool “runs read-only SQL over your container’s records”, because that is what approving it allows. The agent’s tool is on; your own wire_query switch does not move.

A tool the agent says nothing about is on, over both. Every install and update applies the agent’s settings in full, since the agent manages the container’s tools.

An agent’s tools are never reachable through a public container’s read-only access, whatever they run. People who reach a public container that way can use only Wire’s own read tools, and only those that are on.

Wire’s built-in tools

An agent can set whether each of Wire’s built-in tools is on, and over which connections, the same way it does for its own tools. An agent whose tools replace Wire’s usually hides the built-ins, so anything connected to the container sees only the agent’s tools. The connect screen says it plainly, for example “Hides Wire’s built-in tools from your agents: explore, navigate, search, write, and delete.”

An agent can also turn a built-in tool on. wire_query is off on every container by default, and an agent that turns it on is listed as “Turns on SQL queries (wire_query) over MCP and REST. It runs read-only SQL over your container’s records.”

A built-in tool the agent says nothing about gets its default: wire_explore, wire_navigate, wire_search, wire_write, and wire_delete on over both, wire_status on over REST only, and wire_query off. So installing an agent can also turn off a built-in you had turned on yourself; the screen says the others are set to their defaults.

Analysis an agent sets

Some agents need an analysis graph to work: the entity graph (the people, places and other things your entries are about) or the provenance graph (how each new entry relates to what the container already held). Because the agent manages the container, it sets both graphs: each one it asks for is turned on, and each one it doesn’t ask for is turned off. The connect screen lists what it turns on with its price, for example “Turns on the entity graph: 1 credit per entry written.”, and what it turns off. Turning a graph off stops it for new entries; what it already built stays.

Turning a graph on is an organization-level decision, like the switch in settings, so connecting an agent that turns one on needs an organization owner or admin. An agent that only turns graphs off, or leaves them off, needs admin access to the container, like any install.

Disconnecting the agent leaves the analysis as the agent set it. Uninstalling it turns both graphs back on, the default for a container, at 1 credit per entry written each. You can then turn either off in the container’s Analysis settings.

What the data flows mean

An action’s data flow is worked out by Wire from how the agent’s tools use it, not taken from the agent’s description. The description is what the agent says it does. The data flow is what the container will actually send and where the result goes. Read both.

Each flow is one sentence. For example:

geocode runs before save_place, receives the address you give, and its result is saved to your container.

The sentence names every value the agent’s server receives, and nothing else is sent. Each call also tells the agent which container and which connection it comes from. Some flows carry a label:

Label	What it means
Reads data from your container	The action runs after a tool and receives part of what that tool returned from your container. That data leaves the container and goes to the agent’s server.
Shapes what is saved to your container	The action’s result goes into a tool that writes, so the agent’s server decides part of what is stored.
Changes what the agent sees	The action’s result becomes part of what the calling agent gets back from the tool.

An action that no tool runs is still listed with its host. The container only calls hosts you approved, and only with the values its tools send.

When tool names clash

A tool’s name belongs to whoever installed it, so you and the agent can each have a search_places. Nothing is refused. The installing agent’s own connection always sees its tools under their plain names. A key that sees every tool in the container sees your own tool as search_places and the agent’s as someday_search_places, the agent’s id followed by the name. The connect screen tells you when this will happen, and the Custom tools list on the container’s Tools page shows “exposed as” beside any tool whose name differs.

Installed agents

The container’s Connected agents page lists each installed agent with its version, its connection status, the hosts its actions call, and any analysis it turned on, and says which agent manages the container. Open Details to see each of its tools as the container has it now (on or off, and over which connections) and the same breakdown the connect screen showed. After an update, the page lists what changed: tools added, changed, or removed, actions added, changed, or removed, built-in tools whose setting changed, whether the skill or the instructions changed, and interactive views added, changed, or removed.

A tool the agent is removing in an update is hidden first and removed at its next update, so a connection in the middle of using it is not cut off without warning.

The tools an agent installed also appear in the container’s Custom tools list, marked “installed by” the agent. You cannot edit them there. They change only when the agent is updated (see Updating an agent), and they leave when you uninstall the agent.

Updating an agent

A new version of an agent reaches your container in one of two ways, depending on whether the agent is verified. For an agent that isn’t verified, nothing changes until a person approves the update. For a verified agent, an update that needs no new permissions is applied the next time you use the agent, and an update that needs more waits for your approval.

A verified agent is one Wire has reviewed: its name and its developer are who they say they are. The connect screen shows Verified beside it. Every other agent is marked unverified, and each of its updates needs approval.

When the agent’s developer registers a new version, every container keeps the version it has until one of those two things happens. You can approve an update in two places: through the agent’s own connect flow, or in Wire.

Updates a verified agent applies on its own

A verified agent’s update is applied without a review when it asks for nothing you haven’t already agreed to. It happens the next time you use the agent: when a client you connected uses the container, usually within about ten minutes, or when you connect another client to it. It is applied as you, and the container’s activity feed records it every time, for example “Someday updated automatically to version 0.3.0 while you were using it”. A container nobody is using keeps the version it has.

An update is held for your approval when the new version does any of these:

The new version	Why it asks
Calls a host the installed version did not, or lets a view reach one	You approved specific hosts. A new address on a host you approved does not ask, and neither does a host under the domain the agent has proven is its developer’s
Starts sending records from your container out at all, or sends them to a host that received none before	A host you approved for what you type is not approved for what you have stored. Starting to send records always asks, even to the developer’s own domain
Sends more of a tool’s results to a host than it did before	What leaves your container is yours to decide, whoever receives it
Can do something the installed version could not	Reading, running SQL, writing, deleting, calling the agent’s server, and sending records to it each count
Keeps a Wire built-in tool it did not keep, or turns one on or off for the container	Which of Wire’s own tools are in play is part of what you approved, and it changes what your other clients can do
Lets an interactive view run a tool that changes your container or sends records out	A view runs the tool itself, without your AI client deciding to
Stops marking a tool as one that deletes or reaches outside Wire	Your AI client uses those marks to decide when to check with you
Has a view ask for your camera, microphone, location, or clipboard	Browser permissions are yours to grant
Turns on an analysis graph	It costs credits for every entry written
Changes the agent’s name	The name is what you saw when you approved it

Everything else is applied without asking: tools added, changed, or removed within what the agent could already do, the kinds of records it declares, new addresses on hosts you approved, its skill and instructions, and a view’s code. An update that only takes something away from the agent never asks.

If Wire can’t tell whether an update needs a new permission, it treats it as one that does and waits for you. If it can’t check for an update, nothing changes: you keep working at the version you have, and it checks again the next time.

An update held for approval waits in Wire, as described below. The agent keeps working in the meantime, at the version you approved.

You need admin access to the container for an update to be applied on your use of it. Without it, the container stays at the version already installed until someone with that access uses or approves it.

In Wire, the container’s Installed agents section says when a newer version is waiting, for example “Someday 0.3.0 available (you have 0.1.0)”, with Review and update beside it. An agent can also link you straight there, for example from an “Update to 0.3.0” link on its own settings page. Either way you sign in to Wire and approve in Wire, never on the agent’s site.

What the review shows

The review screen shows the same view as the connect screen, for the new version: the tools it installs, its actions and the hosts they call, the records it declares, Wire’s built-in tools it hides or turns on, the analysis it sets, its skill and instructions, and its interactive views. It also lists what the update changes from the version you have:

• Tools that are new, or newly on
• New things a tool can do
• Analysis graphs turned on or off
• Built-in tools shown or hidden
• A skill or instructions added, changed, or removed
• Interactive views added, changed, or removed, and each domain or permission a view newly asks for, marked New

Choose Approve to update the container, or Not now to keep the version you have. The update stays available, and you can review it again later.

You approve the exact version on the screen. If the agent registers yet another version while the review is open, approving is refused and the screen asks you to review again.

Who can approve an update

The same people who could approve it through the agent’s connect flow:

• Admin access to the container is needed for every update, and access limited to specific tools is not enough.
• An organization owner or admin is also needed when the new version turns an analysis graph on, because turning a graph on is an organization-level decision.

What happens when you approve

The container moves to the new version, and its activity feed records the update as yours. An update a verified agent applied on its own is recorded there too, marked as automatic. The agent keeps its connection: it doesn’t need to reconnect or get a new key, and what it can reach from then on follows the new version’s tools. If the agent asked to be notified, it hears about the update too.

A disconnected agent can’t be updated from Wire. Connect it again from the agent, and the connect screen shows the version it has registered for you to approve.

Disconnecting and uninstalling

Both need admin access to the container, and both ask you to confirm.

	Disconnect	Uninstall
The agent’s connections to this container	End now	End now
The container calls the agent’s server	Stops	Stops
Tools that run an action	Hidden until you connect again	Removed
The agent’s other tools	Keep working	Removed
Wire’s built-in tools	Stay as the agent set them	Back to their defaults
Analysis graphs	Stay as the agent set them	Both back on (the default)
Its skill and instructions	Still given to your agents	Removed
Its interactive views	Still served	Removed
Your own custom tools	Still hidden	Back, and editable
Your tool and analysis settings	Still locked	Yours again
Records the agent saved	Stay	Stay
Connecting again	Reconnects the same install	Installs it fresh

Records stay in both cases because they are your data, not the agent’s. Delete them the way you delete any entry.

For agent builders: the manifest fields

An agent declares all of this in its manifest. Four fields set what an install does to the container beyond the agent’s own tools; see the Wire SDK for the rest of the format. The manifest’s app section (app.id, app.name, app.version) is the format’s literal field name and names your agent.

{
  "builtin_tools": {
    "wire_explore": { "enabled": false },
    "wire_navigate": { "enabled": false },
    "wire_write": { "enabled": false },
    "wire_delete": { "enabled": false },
    "wire_search": { "transports": { "mcp": false } },
    "wire_query": {}
  },
  "analysis": { "entity": true },
  "instructions": "Save places with save_place. Read skill://someday/SKILL.md first.",
  "skill": "---\nname: someday\ndescription: Save places the user wants to go. Use when the user mentions a place.\n---\n\n# Someday\n\n..."
}

• builtin_tools sets each built-in tool’s visibility, in the same shape as one of the agent’s own tools: enabled (default true) and transports (default {"mcp": true, "rest": true}). The keys are wire_explore, wire_navigate, wire_search, wire_write, wire_delete, wire_status, and wire_query; any other name is refused, except wire_export, which is accepted and ignored. Export isn’t a tool: people export a container from the dashboard, and an agent asks through the agent API. A built-in you leave out gets its default, and {} turns one on over both. Hiding a built-in on every connection while base_tools keeps it for your agent is refused.

• analysis names the graphs the container should run: entity and provenance, each true or false. A key you leave out is false, so the install turns that graph off.

• instructions (up to 16,000 characters) is what every MCP client gets when it connects to the container. Keep it short: the rules an agent needs even if its client never loads a skill.

• skill (up to 64,000 characters) is a SKILL.md: YAML frontmatter, then Markdown. The frontmatter needs:

  • name: lowercase letters, digits and single hyphens, up to 64. It’s the skill’s directory, as in skill://<name>/SKILL.md.
  • description: what the skill does and when to use it, up to 1,024 characters.

  It can also have license, compatibility and metadata (a map of strings). Any other field is refused, and so is allowed-tools: a skill served by a container can’t pre-approve tools on the agent’s machine. Write each field on one line, plain or quoted. Quote a value that would otherwise read as a number, true/false or null, like version: "1.0". Folded (>) and literal (|) blocks are refused, so the frontmatter reads the same in every client.

Every install and update applies all four in full. A manifest without builtin_tools or analysis gets every built-in at its default and both graphs off. A manifest without a skill removes any skill an earlier version added.

A manifest can also ship interactive views with ui, each shown by the manifest tools that name it. A manifest with views can be up to 2 MiB, of which at most 1 MiB is outside the views’ HTML. See Interactive views (MCP Apps) for the fields, the domain rules, and the limits.

While your agent manages a container, a request that would change its tools (a tool toggle, a custom tool edit, a key with its own tool list) is refused with HTTP 409 and the error code container_agent_managed, with a managedBy object naming your agent (managedBy.agentId). Older responses used container_app_managed and managedBy.appId; treat both spellings the same.

For agent builders: installs and webhooks

Your agent does not need to keep anyone’s API key to know about its installs. Each connect returns an installId and a pairwise agentUserId; keep those, and read an install’s container name, status, and manage link from your server with a runtime key. Wire can also send your server a signed webhook when an install is created, upgraded, disconnected, uninstalled, claimed, about to expire, expired, or deleted. Delivery is at-least-once, with retries for about 24 hours. See Installs and webhooks for the endpoints, the event payload, and how to verify it.

Copied containers

A copy of a container never keeps its agent connections. In the copy, the agent shows as Disconnected: container copied, and its tools that run an action are hidden. The original container is not affected. To use the agent with the copy, connect it again and approve.