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, enabling flexible architectures where 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 many production concerns still need to be handled outside the protocol: authentication, authorization, downstream governance, reliability, observability, and operations.
| Challenge | Impact |
|---|---|
| Authentication needs to be handled by the deployment environment | Teams often need additional infrastructure to validate caller identity and reject unauthenticated requests before they reach MCP servers. |
| Authorization is not universally enforced across environments | MCP does not provide a universal model for enforcing fine-grained authorization across agents, servers, and tools. Additional controls are often needed to determine which clients can access which capabilities. |
| Downstream access governance is outside MCP | When an MCP server calls another service, such as a database, an API, or another MCP server, access control for that hop is typically handled outside the protocol. Without additional controls, outbound access can be harder to manage consistently. |
| Reliability for downstream calls is not built into MCP | Retries, timeout policies, circuit breaking, and other resiliency features for downstream service calls generally need to come from the application or platform layer. Without them, transient failures can be harder to contain. |
| End-to-end observability is not standardized | Teams often need additional tracing, logging, and monitoring to understand request flows across agents, MCP servers, and downstream services. Troubleshooting multi-step tool interactions can otherwise be difficult. |
| Operational concerns are left to the platform | Capabilities such as transport security, secret management, rate limiting, and service discovery are typically handled outside MCP. As the number of MCP servers grows, managing these concerns consistently can add operational overhead. |
How MCP runs on Catalyst
Both the agent (MCP client) and the MCP server run as Catalyst apps, each registered with its own App ID. Calls between them flow through Catalyst's service-invocation layer — the same layer that governs every other call between Catalyst apps. The agent's existing MCP client points at the Catalyst sidecar's service-invocation endpoint (/v1.0/invoke/<mcp-server-app-id>/method/mcp), and Catalyst resolves the target by App ID and forwards the request. The same App ID identity, access policies, middleware, observability, and resiliency that apply to any other service-to-service call apply here.
Because service invocation speaks plain HTTP and Catalyst's controls do not touch the MCP protocol body, off-the-shelf MCP clients and agent frameworks work unchanged. Agents keep using the MCP SDK or framework they already use; Catalyst applies its standard service-to-service controls to the call.
| Challenge | How Catalyst addresses it |
|---|---|
| Authentication | A bearer middleware validates inbound JWT tokens in the HTTP pipeline before requests reach the MCP server. Tokens are checked against the issuer's JWKS, the iss claim, and the aud claim. Any standard OAuth 2.0 provider works (Auth0, Okta, Azure AD, etc.). |
| Authorization | A Configuration resource with accessControl rules attached to the MCP server's App ID determines which caller App IDs can invoke the server. Default-deny is supported; combine with bearer middleware for defense in depth. |
| Downstream access governance | The same Configuration model applies at every service boundary — an MCP server can be allowed to call one backend while being restricted from reaching another. |
| Reliability | Catalyst applies its standard resiliency policies — configurable timeouts, retries with exponential backoff, and circuit breakers — to every service-invocation hop, MCP calls included. |
| Observability | Service-invocation logs, metrics, and distributed traces cover MCP requests automatically. The Catalyst console shows identities, invocation flows, and policy enforcement. |
| Operational concerns | Catalyst handles mTLS, certificate rotation, service discovery, secret storage, and middleware configuration centrally. MCP server and client code do not need to import Catalyst or Dapr. |
Core primitives
MCP servers as Catalyst apps
In Catalyst, an MCP server is any application that exposes an MCP-compliant HTTP endpoint and is registered as a Catalyst App ID. Catalyst applies authentication (bearer middleware), authorization (per-App-ID access policies), resiliency (retries, timeouts, circuit breakers), and mTLS to every request — without requiring any change to MCP server code.
The MCP client targets Catalyst's service-invocation endpoint (/v1.0/invoke/<server-app-id>/method/mcp); Catalyst handles the rest.
MCP Catalog
The MCP Catalog is your organization's library of MCP servers — both pre-defined entries for popular third-party servers (GitHub, Linear, Atlassian, Stripe, and others) and any internal MCP servers your platform team publishes for shared use. Each catalog entry comes with its URL, transport, and authentication method already filled in.
Developers enable a catalog entry for a project or app to make the server available to MCP clients in that project. Enabling typically only requires supplying a project-specific credential — an API key, an OAuth client, or a header value — and the entry is ready to use. Platform teams use the catalog as the single place to vet, document, and version the MCP servers their organization supports; developers use it to add capabilities to an agent without having to wire up the connection from scratch.
Underneath, each enabled catalog entry corresponds to an MCPServer resource in your project that references the connection metadata and the credentials the entry needs. Enabling does not, on its own, govern runtime calls — those flow through the MCP server's App ID and the policies attached to it, as described above. Pair the two: enable the entry for visibility and re-use, and run any MCP server you operate as a Catalyst app with access policies for governance.
Defense in depth
Authentication and authorization layer cleanly. Bearer middleware establishes who the caller is by validating their JWT; access policies decide what they may do by allow-listing caller App IDs at the target. Apply both for defense in depth: an attacker would need a valid token and an allow-listed App ID to reach the MCP server.
See also
- Security and trust posture — identity, authorization, and audit model for MCP calls
- Develop with MCP — tutorials and how-tos for building MCP clients and servers on Catalyst
- MCP access policies tutorial — declarative authorization per App ID
- MCP authentication tutorial — end-to-end bearer middleware + OAuth 2.0 setup
- MCP servers reference — MCP Catalog entries
- Policies concept — the broader policy primitives Catalyst exposes
- Application Identities — App IDs are the unit of MCP authentication and authorization