The MCP Gateway uses the 2025-11-25 MCP spec (Streamable HTTP transport, Tasks primitive, and Elicitation support). The MCP Gateway is a P0 module, currently planned.
Agents you can connect
Claude Code
The Claude Code CLI and VS Code extension connect directly via the MCP server URL. All CyberOS tools appear natively in the tool panel.
Cursor
Add CyberOS to Cursor’s MCP config and access memory, tasks, and KB from inside your IDE without switching context.
Codex CLI
OpenAI’s Codex CLI supports MCP 2025-11-25. Connect it to CyberOS to drive tasks and write memory from your terminal.
Goose
Block Labs’ Goose agent framework supports MCP servers natively. Point it at the CyberOS gateway for autonomous task workflows.
Amp
Sourcegraph’s Amp coding agent connects via MCP to search KB and read task state without leaving your editor.
Any MCP client
Any agent implementing the MCP 2025-11-25 spec connects using standard OAuth 2.1 + PKCE discovery at
/.well-known/oauth-protected-resource.Available MCP tools
Your connected agent discovers these tools automatically viatools/list. The tools your agent can see are filtered by your OAuth token’s scope grants — you only see tools you are authorised to call.
Task management tools
Task management tools
Memory (BRAIN) tools
Memory (BRAIN) tools
Knowledge Base tools
Knowledge Base tools
Audit tools
Audit tools
Connecting your agent
Quick-start: Claude Code or Claude Desktop
Add the following to your Claude MCP configuration file (~/.claude/mcp.json or the equivalent path for your platform):
This configuration uses the local CyberOS MCP bridge installed in your repository by
task_install. The bridge handles OAuth token exchange automatically using your existing CyberOS session.Cursor
Add the same block to your project’s.cursor/mcp.json file:
Other MCP clients (remote URL mode)
For agents that support remote MCP server URLs directly:Verifying the connection
Once connected, ask your agent to run:cyberos.memory.search, cyberos.skill.task_status, and cyberos.kb.search.
Tool annotations and safety gates
Every tool in the registry carries annotations that drive how the gateway handles it:Tool registry (admin feature)
Tenant admins and module owners register new tools by submitting a tool manifest to the gateway. Registration requires CTO + CSO approval because every new tool expands the surface area available to connected agents.1
Author the tool manifest
Create a JSON manifest that defines the tool name (following the
cyberos.{module}.{verb}_{noun} convention), input/output schema, required scope, and annotations.2
Submit for review
Submit the manifest via the admin CLI or the tenant admin panel. The gateway validates the naming convention and annotation completeness automatically.
3
Approval and registration
After CTO and CSO approval, the tool is registered and immediately available to agents that hold the required scope. Subscribed agents receive a
tools/list_changed notification and re-fetch the catalogue automatically.Long-running tasks
For operations that take more than a few seconds — such as ingesting a large KB corpus or running a bulk skill — the gateway uses the MCP Tasks primitive. Your agent starts the operation and receives atask_id immediately. You can disconnect and reconnect; the task persists until completion.
Audit trail
Every tool call — whether it succeeds, fails, is confirmed, or is denied — produces anmcp.invocation audit row in the memory chain. The row records:
- Which tool was called and with what arguments hash
- Which agent persona made the call (e.g.
claude-code@user-stephen) - The OAuth scope that was checked
- Whether a destructive confirmation was obtained
- The outcome and latency
- The chain anchor linking to the previous audit row