Model Context Protocol
The Model Context Protocol (MCP) is an open standard that defines how AI agents connect to external tools and data sources. Instead of building custom integrations for every service an agent needs, developers expose capabilities through MCP servers and connect to them through MCP clients, using a single, model-agnostic protocol.
With open-source libraries available in Python, TypeScript, Java, C#, Go, and more, alongside a rapidly growing ecosystem of thousands of MCP servers, MCP is becoming the de facto standard for how agents and tools integrate.
Benefits of MCP
- Standardized integration. MCP replaces fragmented, per-service integrations with a single protocol. An agent built against MCP can connect to any compliant server without custom adapter code.
- Dynamic tool discovery. Agents discover available tools at runtime rather than compile time, so servers can be added, updated, or removed without redeploying clients.
- Model-agnostic. MCP works across LLM providers and agent frameworks.
- Separation of concerns. Tool logic lives in MCP servers, while agent logic lives in clients. Teams can develop, deploy, and scale each side independently.
Production challenges with MCP
MCP standardizes how agents connect to tools, but running MCP servers in production raises concerns the protocol doesn't fully address on its own. Catalyst handles each of them at the platform layer.
| Challenge | Impact in production | How Catalyst addresses it |
|---|---|---|
| Authentication | Teams need extra infrastructure to validate caller identity and to hold the credentials each upstream server requires. | The caller authenticates to Catalyst and Catalyst authenticates to the upstream server using the credential configured on the connection, so credentials stay out of agent code. |
| Authorization | MCP has no universal model for deciding which clients can use which tools. Without added controls, any client that can reach a server can call every tool it exposes. | A deny-by-default MCP access policy allow-lists which caller App IDs may use which tools. Discovery is filtered and unauthorized calls are rejected with 403. |
| Credential management | API keys for each MCP server tend to end up in agent code, environment variables, or prompts, where they are hard to rotate and easy to leak. | Upstream credentials are stored in the project secret store and injected at request time. The agent receives tool results, never the credential. |
| Reliability | Retries, timeouts, and circuit breaking for tool calls generally come from the application or platform layer. | Catalyst applies its standard resiliency policies — timeouts, retries, and circuit breakers — to MCP calls. |
| Observability | Tracing, logging, and monitoring across agents, servers, and tools usually need to be added on top. | Logs, metrics, and distributed traces cover MCP requests automatically, viewable in the Catalyst console. |
| Operations | Transport security, secret storage, and service discovery scale poorly as the number of MCP servers grows. | Catalyst handles transport security, secret storage, and service discovery centrally. |
How MCP runs on Catalyst
Catalyst fronts every upstream MCP server with a proxy endpoint on your project's HTTP API: <project-http-endpoint>/v1.0/diagrid/mcp/<server-name>. Rather than connecting to the upstream server directly, the agent's MCP client points at this endpoint and authenticates with its App ID API token (dapr-api-token).
Two App IDs sit behind the endpoint. The request first reaches the MCP client App ID, which serves the proxy endpoint and can apply filters or middleware, then forwards to the MCP server App ID, which enforces the access policy, injects the upstream credential, and forwards the call to the upstream server.
Because the proxy endpoint speaks plain MCP over Streamable HTTP, off-the-shelf MCP clients and agent frameworks work unchanged — there is no Catalyst-specific MCP SDK. The agent points its existing client at <project-http-endpoint>/v1.0/diagrid/mcp/<server-name> and authenticates with its App ID token; Catalyst handles policy, credential injection, and forwarding.
Core primitives
MCP server connection
An MCP server connection (the MCPServer resource) is an instance you create in a project to connect to one upstream MCP server — distinct from a catalog entry, which is only a reusable definition. It records the upstream URL, the transport (streamable-http or sse), the upstream credential, and optional catalog metadata. Catalyst fronts the connection at <project-http-endpoint>/v1.0/diagrid/mcp/<server-name> and never exposes the upstream URL or credential to callers. See Manage MCP Servers.
MCP Catalog
The MCP Catalog is your organization's library of pre-defined MCP server definitions — built-in entries for popular third-party servers (GitHub, Linear, Stripe, Atlassian, and others), plus any custom entries your platform team publishes. A definition fixes the provider, URL, transport, and auth shape; creating a connection from it in a project takes only a name and a credential. See the MCP servers reference.
MCP access policy
An MCPServerAccessPolicy is the per-tool, per-caller allow-list attached to an MCP server. Catalyst creates one automatically — and empty — when you create the MCP server connection, and locks its lifecycle to that server. Because an empty policy has no allow-list entries, the server is deny-by-default until you grant access. You add rules with the diagrid mcpserver access commands rather than authoring the policy by hand, or open the server to every caller and tool with diagrid mcpserver access grant <server-name> --caller "*" --allow-tools "*". See Control tool access.
See also
- Security and trust posture — identity, authorization, and audit model for MCP calls.
- Develop with MCP — connect clients, add servers, and control access.
- Manage MCP Servers — register and curate MCP server connections.
- Policies — the broader policy primitives Catalyst exposes.
- Application Identities — App IDs are the unit of MCP authentication and authorization.