High-level overview
Every tool call targets a Gateway. Bare/mcp fails closed with a "select a gateway" 400.
A tool call through the Tools gateway looks like this:
- An operator adds an MCP server connection, puts it (or its tools) on a Gateway, and grants an agent access.
- The agent points an MCP client at
https://<host>/gateways/<id>/mcpwith a Dome agent token. - Discovery (
tools/list) returns membership- and Cedar-filtered tools. - Each
tools/callruns admission, Rules, request Guards, egress with injected credentials, response Guards, and audit.
Endpoints
Point MCP clients at the Gateway’s returned
mcp_url. Do not omit the /gateways/<id> segment.
Pipeline
Tool calls share these stages:- Ingress: Resolve the Gateway from the path, validate the bearer credential, extract agent identity, check Gateway admission (discovery exempt), verify act-as when present, apply kill switches and rate limits.
- Evaluate: Load the workspace Cedar policy and authorize the tool action. Stale policy fails closed.
- Egress: Resolve the backend from the tool catalog, inject stored credentials, forward over MCP Streamable HTTP, stdio, or REST catalog.
- Filter: Apply response Guards and field-level redaction before the agent sees the result.
- Audit: Emit
mcp.tool_call.*, filtering, discovery, and denial events stamped with the Gateway id.
Discovery vs invoke
tools/list stays membership- and Cedar-filtered and does not require a Gateway access grant at the edge. tools/call requires addressability, admission, and Cedar. A tool that is not a member of the addressed Gateway does not appear for that caller.
Egress protocols
Next steps
With the Tools gateway model in mind, continue with:- Gateways concept for membership, grants, and URL shape
- Data plane concept for the shared pipeline, credentials, and readiness
- LLM gateway concept for the sibling model ingress
- Tools concept for credentials, catalogs, and reachability
- Tools to register MCP and tool connections
- Gateways to attach tools to a Gateway