Delegate as an MCP server
The rest of this section is about pointing Delegate agents at your tools. This page is the other direction: connecting an MCP client — Claude, or anything else that speaks the protocol — to your Delegate agents, so you can drive them from wherever you already work.
Who can do what
| Task | User | Agent owner | Admin |
|---|---|---|---|
| Connect an MCP client to their own agents | ✅ | ✅ | ✅ |
The connection acts as you, with your access. It reaches the agents you can reach and nothing else.
Endpoint
POST https://<your-delegate-host>/mcp
JSON-RPC 2.0 over MCP's Streamable HTTP transport. Protocol version
2025-06-18, with 2025-03-26 and 2024-11-05 also accepted.
Supported methods: initialize, notifications/initialized, ping,
tools/list, tools/call.
Authorizing
The server implements OAuth 2.1 with dynamic client registration, so a compliant client discovers and completes the flow on its own — you'll be asked to sign in and approve the scopes.
Discovery documents are at the standard locations:
/.well-known/oauth-authorization-server
/.well-known/oauth-protected-resource
Scopes
| Scope | Grants |
|---|---|
mcp:agents.read | View your agents and their activity |
mcp:agents.write | Create, configure, and run agents on your behalf |
mcp:kb.read | Read your knowledge base |
mcp:kb.write | Add to and edit your knowledge base |
A client that doesn't narrow its request receives all four. Narrow deliberately:
a client that only needs to ask questions wants mcp:agents.read and
mcp:agents.write, not the knowledge-base scopes.
The Origin header is validated against an allow-list, which defeats
DNS-rebinding from local browsers. A local client that fails to connect with an
origin error is hitting this, not an auth problem.
What the client gets
Nine tools, each requiring one scope:
| Tool | Scope | Does |
|---|---|---|
list_agents | agents.read | List the agents you can invoke, with ids and descriptions |
ask_agent | agents.write | Start an agent working and return the session_id immediately |
send_message | agents.write | Send a message and wait for the final reply |
list_sessions | agents.read | Recent conversations with an agent, newest first |
get_transcript | agents.read | The full message transcript for a session |
get_attachment | agents.read | Download a file the agent attached, base64-encoded |
list_projects | kb.read | DocWorker knowledge-base projects |
search_knowledge_base | kb.read | Search a knowledge base and return matching passages |
upload_document | kb.write | Add a document to a project so it can be searched |
ask_agent vs send_message
The distinction that matters in practice:
send_messagewaits for the reply. Simple, and right for short work — but it can time out on a long task.ask_agentreturns asession_idstraight away and lets the agent keep working. Poll withget_transcriptwhen you're ready.
Reach for ask_agent for anything substantial: research, document production,
multi-step work. send_message is for quick questions.
What still applies
Everything. Driving an agent over MCP is driving the same agent:
- Budgets apply, so a capped agent stops or throttles here too.
- Sharing applies — you see the agents you'd see in the app.
- Usage is recorded against the agent as normal.
- Memory and history are shared with the app. A conversation you start from an MCP client appears in the agent's sessions, and what it learns there is remembered everywhere.
Which integration path is yours
| You want to… | Use |
|---|---|
| Drive your own agents from an MCP client | This page |
| Give Delegate agents access to your API | Exposing your tools over MCP |
| Give each of your customers their own agent | Building an integration |
| Put an agent on a public web page | Embedding an agent |