Skip to content

Agents tokens

Companion isn’t only something you talk to. It’s something your other agents can talk to.

Companion exposes itself as an MCP server — a “brain” endpoint. An external coding agent that supports MCP (Cline, Continue.dev, Claude Desktop, Cowork) can connect to it and call back into Companion’s memory, projects and tools while it works in your IDE.

Once connected, the agent can use Companion’s companion_* MCP tools:

  • Read and write memory — recall what you’ve told Companion, append new facts (companion_remember).
  • Reach your projects — pull a project’s wiki/context into the agent’s run.
  • Use Companion’s integrations — the MCP servers you’ve configured (Notion, Linear, GitHub, Tavily, Filesystem, your own) become available to the agent too, through one connection.

The agent keeps coding in your IDE; Companion is the shared brain behind it — same memory whether you’re in the chat window or in Cline.

Settings → Agents tokens → Create. Give it a name (per agent or per machine), copy the token once — it’s shown only at creation. The token scopes the agent’s access to Companion’s MCP surface.

Point the agent’s MCP config at Companion’s MCP endpoint with the token. The exact config shape depends on the agent (Cline, Claude Desktop, etc.), but it’s always the same three things: the MCP URL, the token, and a name. The agent then sees Companion’s tools in its own tools/list.

Tokens are revocable from the same screen. Revoke one and that agent’s connection stops immediately — useful when a machine changes hands or a token leaks.

This is the mirror of engine pairing: pairing points Companion out to an inference engine; an agents token lets an external agent point in to Companion. Together they make Companion the hub — the model below it, the agents around it, the memory in the middle.

  • Memory — what the agent reads and writes.
  • Engine pairing — the outward direction.
  • CoeOS — the per-skill router those same agents can call as their model.