Connect your agent

MCP is the reason a context layer is buildable at all this year. Before it, serving context to agents meant an integration per agent; now it is one server that every serious client already knows how to talk to.

Your instance is one of those servers.

What connecting gives an agent

• Search the shared context, permission-filtered before ranking, with hybrid full-text and vector retrieval behind it.
• Read any resource, at head or at an older revision.
• Compare two revisions to see what changed between them.
• Follow what has changed since it last looked, through a subscription.
• Propose a change — which an owner then approves or rejects. An agent never writes to the record directly.

Every result carries its provenance: the revision it was read at, the resource it came from, and the origin URL at the source.

The token is bound to a person

An agent connects with a token that belongs to a member of your team, and it sees exactly what that person sees. There is no service token, so there is no configuration in which an agent has broader access than the human it works for.

The practical consequence: two people’s agents asking the same question can correctly get different answers, and neither result reveals what the other could see.

Connecting

Your instance mints an instance token beside its MCP URL on the “connect your agent” page in your account. What you do with the two of them depends on the client — most take a server URL and a header, and the shape below is what that generally looks like:

{
  "mcpServers": {
    "xerum": {
      "url": "https://<your-team>.docco.app/mcp",
      "headers": { "Authorization": "Bearer <your instance token>" }
    }
  }
}

Check your client’s own documentation for the exact spelling — Claude, Cursor and the rest each have their own configuration file, and this is not a format we get to define.

What the model reads

Which operations become tools, and every word of description the model sees for each one, is written into the API contract itself rather than assembled at runtime. So the tool descriptions an agent reads are reviewed the same way the API is, and cannot drift from what the operations actually do.

REST, underneath

Everything MCP exposes has a REST equivalent, and both are generated from one OpenAPI contract — a drift check fails the build if they ever diverge. If you are building something rather than pointing an agent at it, the contract is the place to start.

What an agent can do with all this, industry by industry, is on the who it is for pages.