MCP Toolsets

MCP is an open protocol for exposing tools to AI runtimes. AOS manages MCP servers through a toolset manager that connects to declared servers, discovers their tools, and makes them callable from skills and from an A2A serve worker.

• Servers are declared in the project's MCP registry under core/mcp/.
• A skill's mcp_binding names a server and tool; invocation becomes a direct tool call.
• HTTP/SSE server URLs pass through the same SSRF egress gate as A2A traffic.

Each MCP server entry declares a transport plus how to reach it. A stdio server is launched as a child process; an HTTP server is reached over Streamable HTTP:

# stdio server
id: files
transport: stdio
command: my-mcp-server
args: ["--root", "."]
env:
  API_TOKEN: ${MY_TOKEN}

# http server
id: search
transport: http
url: https://mcp.example.com
auth_ref: SEARCH_TOKEN        # resolves to a bearer header
tool_allowlist: ["web_search"]

A skill declares an mcp_binding to map its invocation onto an MCP tool. When the skill runs — in a workflow step or via A2A serve — AOS calls the tool directly with the skill input as the argument:

# core/skills/web-search/skill.yaml
id: web-search
name: web-search
mcp_binding:
  server: search
  tools: ["web_search"]

• stdio — the server is spawned as a child process with array-form command/args (no shell) and a templated env.
• Streamable HTTP — JSON-RPC over HTTP with optional SSE responses; the negotiated protocol version rides on every post-initialize request.

Credentials are never carried across an origin boundary: a redirect to a different origin drops the Authorization header.

A server can expose many tools; tool_allowlist narrows what AOS will surface and invoke. The allowlist is enforced both at discovery time and at call time, so a server cannot smuggle in a tool that was never sanctioned.

HTTP MCP servers are agent-initiated egress, so they go through the mesh egress policy:

• The server URL is checked against the SSRF policy (private/loopback/internal hosts blocked unless allowlisted).
• A resolve-time guard runs before the initial request and every redirect hop — a DNS-rebinding defense, intrinsic to the transport.
• Responses are read with a hard byte cap so a hostile server cannot exhaust memory.

See Agent Mesh Security for the full egress model.