Lesson 3.3
MCP in the Enterprise
How the Model Context Protocol fits enterprise integration, the hosting and authentication choices that matter at scale, and the governance controls an architect must put around MCP servers.
The Model Context Protocol (MCP) standardises how a model-driven application discovers and calls tools, reads resources and uses prompts exposed by external servers. For the enterprise it promises one integration per system rather than one per application. The professional architect's job is to get that promise without the attack surface that comes with it.
Primitives and topology
An MCP host (Claude Code, the Agent SDK, Claude.ai, Managed Agents, or your own application) runs one or more MCP clients, each connected to an MCP server. Servers expose tools (callable actions), resources (readable data) and prompts (reusable templates). Two transports matter:
| Transport | Where the server runs | Fits |
|---|---|---|
| stdio | A local process spawned by the host | Developer tooling, Claude Code on a workstation, CI runners |
| Streamable HTTP | A remote service | Shared enterprise servers, multi-tenant access, central governance |
Remote servers authenticate with OAuth 2.1 flows defined by the MCP authorization specification, so a user's own identity can be carried through to the backing system. Local servers inherit the credentials of the process that spawned them, which is convenient on a laptop and unacceptable on a shared server.
Ways to reach MCP from Claude
- Claude Code and the Agent SDK act as hosts and connect to local or remote servers through configuration; project-scoped configuration can be checked into the repository and governed by managed settings.
- The MCP connector in the Messages API lets a request name remote MCP servers directly; you supply the server entries and a corresponding toolset entry in
tools, under a beta header, and the platform performs the calls. It supports remote servers only and is not available on every cloud platform; check the docs. - Managed Agents attach MCP servers to an agent's toolset with credentials held in a vault.
- Claude.ai exposes MCP servers to business users as connectors, with organisation-level controls.
Build or adopt
Adopt a vendor's official server when one exists and its scope matches your needs. Build your own when the system is internal, when you need narrower tools than the vendor exposes, or when you need to enforce business rules the vendor server does not. A thin internal server that wraps a legacy API with three well-described tools is usually better than a generic server that exposes forty.
Governance controls
MCP moves the integration boundary into the model's hands, so controls must be structural:
| Risk | Control |
|---|---|
| Unknown or malicious servers | Internal registry or allowlist; managed settings that restrict which servers users may add |
| Tool poisoning (malicious instructions in tool descriptions) | Review server definitions before approval; pin server versions; monitor description changes |
| Rug pull (a trusted server changes behaviour later) | Version pinning, checksums, periodic re-review |
| Prompt injection through tool results | Treat results as untrusted data; size caps; no automatic chaining into write tools |
| Over-privileged credentials | Per-user OAuth where the backing system supports it; least-privilege service accounts otherwise |
| Data egress | Network placement inside the perimeter; egress allowlists; logging of payloads at the server |
| Destructive actions | Separate read and write tools; write tools require confirmation or run through deterministic code |
Treat an MCP server the way you treat a microservice with production credentials: owned by a team, reviewed, versioned, monitored and documented.
Designing an enterprise MCP server
- Few, well-named tools. The description is a prompt; say when to use the tool and when not to.
- Typed, validated inputs. Reject anything outside the schema at the server, not only in the model.
- Bounded outputs. Paginate and truncate; a tool that returns ten thousand rows poisons the context.
- Idempotency keys on any write, so a retried call does not double-create.
- Structured errors the model can act on ("record not found", "permission denied") rather than stack traces.
- Audit log of caller identity, tool, inputs, outputs and latency.
- Health, versioning and change management, as for any API.
Identity propagation
The hardest enterprise question is "who is the model acting as?" Three patterns:
- User-delegated OAuth. The server receives a token for the end user; the backing system enforces that user's permissions. Best for user-facing assistants.
- Service identity with policy. The server uses a service account and applies its own authorisation based on a user ID passed in context. Acceptable when the backing system cannot do per-user auth, but the policy layer becomes critical.
- Service identity, read-only. For retrieval servers over public-within-the-company data. Never for write tools.
Avoid any pattern where the model is handed raw credentials as text.
Observability and testing
Test servers with the MCP inspector and with automated tests that call each tool through a client. In production, trace every tool call with the conversation's trace ID so that a wrong answer can be traced to a tool result. Alert on error rates and latency per tool; a slow tool silently degrades every agent that uses it.
Exam focus
- Know hosts, clients, servers, and the three primitives: tools, resources, prompts.
- stdio is for local processes; streamable HTTP is for shared remote servers; remote servers use OAuth 2.1 for authorization.
- The Messages API MCP connector names remote servers plus a toolset entry under a beta header; availability varies by platform.
- Governance means registries or allowlists, version pinning, least-privilege credentials, read/write separation and audit logging.
- Tool results are untrusted input; tool descriptions can carry injected instructions and must be reviewed.
- Prefer user-delegated identity for user-facing assistants; never pass raw credentials to the model.
Check yourself
5 questions
1.A financial institution's security team wants to allow developers to use MCP servers in Claude Code, but only an approved set of internal servers and a few vetted vendors, and they must prevent individual developers from adding arbitrary servers. Which approach is MOST appropriate?
2.A team wants their server-side application, which calls the Messages API directly, to use tools from a remote MCP server without writing its own MCP client. They add the MCP server definition to the request and receive a validation error. What is the MOST likely omission?
3.An enterprise built an MCP server that exposes its CRM to Claude. The server authenticates callers with OAuth, but internally it uses a single high-privilege service account to call the CRM for every user. A review flags that users can retrieve records they are not entitled to see. Which change is MOST important?
4.A platform team allows developers to install community MCP servers from a public registry. One server's tool descriptions were updated in a new version to include text instructing the model to read local credential files and include them in tool arguments. Which governance controls would have been MOST effective against this attack?
5.A team wants a project's MCP servers to be shared with every engineer who clones the repository, while each engineer's personal servers stay private. In Claude Code, which configuration scopes achieve this?