Skip to main content

What is MCP?

The Model Context Protocol (MCP) is an open standard for exposing tools to LLM agents over HTTP. Orca uses MCP as the universal tool interface: every session gets its own MCP endpoint, and agents discover and invoke tools through it.

Session-Scoped MCP Endpoint

When a session is created, Orca provisions a session-scoped MCP server for the agent. This endpoint uses MCP’s streamable HTTP transport and serves:
  1. Platform tools: the session’s scoped toolkit (tools allowed by the profile)
  2. External MCP servers: inline servers defined in the profile’s mcpServers list
  3. Connected apps: provider-managed grants invoked through platform facade tools and the tenant-isolated MCP bridge
The runner passes sessionMcpUrl in the run envelope to the sidecar, which uses it to connect its MCP client.

How Tools Flow

The LLM sees platform tools and inline external MCP tools through one tool interface. Connected-app catalogs stay deferred: the model sees the search_connected_app_tools and call_connected_app_tool facade tools, then loads only the provider tool schemas it needs.

Provider Support

All five runtimes have native MCP client support. Codex is the one exception on headers: it supports only a URL and bearer_token_env_var, so custom headers on a profile’s mcpServers entry are ignored (surfaced as a warning) rather than sent.

External MCP Servers in Profiles

Add external MCP servers to a profile’s mcpServers array:
transport may be http or sse. An entry can also set optional: true to mark a dependency the agent can work without: if that server’s headers cannot be resolved, the server is skipped and the run continues without it rather than failing outright (see Secret Resolution below).

Secret Resolution

Header values containing ${VAR} are resolved from the runner’s environment. See Secrets for how these are provisioned:
If ${VAR} cannot be resolved (the env var is not set), resolution fails with an error. For a required server, the run is rejected outright. If the server entry sets optional: true, that server is skipped instead and the run continues without it. Always verify that runner environment variables are set for every placeholder used in profiles.

MCP Catalog

The MCP Catalog is a conductor-local registry of reusable MCP server definitions. It lets you pre-configure servers once and reference them when building profiles in the dashboard.
User-authored catalog entries are a convenience layer copied into profiles. Provider-managed entries also authorize connected-app calls: profiles store them as credential-free catalog://<name> references, and the runtime resolves them through the bridge rather than as native sidecar MCP transports.

Dashboard MCP Page

The dashboard groups MCP management into three tabs: In v1, Connected Apps uses Composio as its provider. App category labels come from the provider payload when available, with dashboard fallbacks for common app slugs so the gallery remains filterable while provider metadata rolls out. When a managed app is attached to a profile, its mcpServers entry has only a name and matching reference, for example {"name":"composio-gmail","ref":"catalog://composio-gmail"}. The runtime does not send the managed URL or provider credentials to the worker. Agents discover matching tools on demand with search_connected_app_tools and execute an exact result with call_connected_app_tool; both are part of @introspection.

Managing the Catalog

Reserved Names

The name runner is reserved and cannot be used in the MCP catalog. It refers to the session-scoped platform MCP endpoint.

Writing an MCP-Compatible Tool Server

Any HTTP server implementing the MCP streamable HTTP transport can be attached to Orca profiles. Minimal requirements:
  1. Accept POST / requests with MCP protocol messages (JSON-RPC 2.0)
  2. Return Server-Sent Events for streaming responses
  3. Handle tools/list and tools/call method calls
See the MCP specification for the full protocol reference.

Platform MCP vs External MCP

Last modified on September 6, 2026