Connecting LLMs to Enterprise Systems with Model Context Protocol MCP servers
Large language models are most useful when they can act on real systems rather than reason in isolation. The bridge between a model and your databases, ticketing systems, and internal APIs increasingly takes one shape: Model Context Protocol MCP servers. MCP is an open standard, introduced by Anthropic and now adopted across the industry, that defines how an application exposes tools, data, and reusable prompts to any compatible model client.
Before MCP, every integration was bespoke. Each assistant needed custom glue code for each data source, and that glue rarely transferred between projects. The protocol replaces that N-by-M problem with a single, documented interface. Consequently, a server you write once can be consumed by Claude Desktop, an IDE assistant, a custom agent, or any other host that speaks the protocol. This guide covers the architecture, the core primitives, transports, authentication, and the hardening you need before exposing internal systems to a model.
The host, client, and server architecture
The protocol defines three roles. The host is the application the user interacts with, such as a desktop assistant or an agent runtime. Inside the host, an MCP client maintains a one-to-one connection with each MCP server. The server is the process you build; it advertises capabilities and executes requests against the actual backend.
This separation matters because the host owns the model and the conversation, while your server owns the integration. As a result, you never embed model credentials in the server, and you never embed backend credentials in the host. Each side guards its own secrets. The official specification at modelcontextprotocol.io documents the message envelope, which is built on JSON-RPC 2.0 over a chosen transport.
Tools, resources, and prompts as primitives
An MCP server exposes three kinds of capability, and understanding the distinction prevents a great deal of design confusion. Tools are model-controlled actions: the model decides when to call them, and they typically have side effects, such as creating a ticket or running a query. Resources are application-controlled data the host can read into context, such as a file, a record, or a document. Prompts are user-controlled templates that surface as reusable workflows, often triggered by an explicit user choice.
In practice, teams expose far more tools than resources or prompts, because action-taking is where the value concentrates. Nevertheless, modeling read-only data as a resource rather than a tool is a meaningful choice. Resources let the host manage what enters the context window, whereas a tool call always consumes a model turn. When the model only needs to read a known record, a resource is cheaper and more predictable.
Choosing a transport: stdio versus streamable HTTP
The protocol supports two primary transports. The stdio transport runs the server as a local subprocess that communicates over standard input and output. This is the simplest option for desktop tools and local development, since there is no network surface and the operating system handles process isolation.
For anything remote or multi-user, the streamable HTTP transport is the production choice. It exposes a single HTTP endpoint, supports server-sent events for streaming, and can sit behind a standard load balancer and reverse proxy. Because it is ordinary HTTP, teams typically secure it with the same tooling they already use: TLS termination, a web application firewall, and an identity provider. The specification documents both transports in detail, and the official SDKs implement them so you rarely handle framing by hand.
Building a server with the official SDKs
Official SDKs exist for TypeScript and Python, among others. They handle the JSON-RPC plumbing, capability negotiation, and transport so your code focuses on the integration itself. The pattern is consistent: instantiate a server, register tools with a name, a description, and an input schema, then implement the handler. The example below sketches a server exposing a single read tool against an internal order system. Keep code at the SDK-pattern level and validate every input.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { z } from "zod";
const server = new McpServer({
name: "order-service",
version: "1.0.0",
});
// A model-controlled tool. The description tells the model WHEN to call it.
server.registerTool(
"get_order_status",
{
description:
"Look up the current status of a customer order. " +
"Call this when the user asks about a specific order by its ID.",
inputSchema: {
orderId: z.string().regex(/^ORD-[0-9]{6}$/, "Must be an ORD-###### id"),
},
},
async ({ orderId }) => {
// Enforce least privilege at the boundary: this connection's scope
// is checked before any backend call is made.
const order = await orderRepository.findById(orderId);
if (!order) {
return {
content: [{ type: "text", text: `No order found for ${orderId}.` }],
isError: true,
};
}
return {
content: [
{ type: "text", text: `Order ${orderId}: ${order.status} (updated ${order.updatedAt}).` },
],
};
},
);
const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: () => crypto.randomUUID(),
});
await server.connect(transport);
Notice that the input schema is enforced before the handler runs, and the handler returns a structured error rather than throwing. A clean error message lets the model recover gracefully, often by asking the user for a corrected order ID. For deeper context on how models consume structured tool results, the Claude API tool use and structured output guide walks through the client side of the same contract.
Authentication, scoping, and the confused-deputy risk
Security is where naive MCP deployments fail. Remote servers should sit behind OAuth 2.1, and the specification aligns with that framework for authorization. The model client presents a token; your server validates it and derives the caller’s identity and scopes from it. Critically, the server must apply the principle of least privilege: a connection scoped to read orders must never be able to issue refunds, regardless of what the model requests.
The subtle danger is the confused deputy problem. Your server holds powerful backend credentials and acts on behalf of many users. If it forwards a model’s request without re-checking that this user is authorized for this action, an attacker can trick the model into abusing the server’s privileges. Therefore, authorization decisions must be made on the server using the authenticated caller’s identity, never inferred from the conversation. Anthropic’s documentation at docs.anthropic.com and the protocol’s own security guidance both stress this boundary. Prompt injection compounds the risk, because untrusted text pulled into context can attempt to steer tool calls, which is one more reason every call is re-authorized server-side.
Production hardening for Model Context Protocol MCP servers
Beyond authentication, a server exposed to a model needs the same operational rigor as any public API, and arguably more, because the caller reasons unpredictably. Apply per-caller rate limits so a runaway agent loop cannot exhaust a backend. Validate and sanitize every tool input against a strict schema; treat the model as an untrusted client. Add structured audit logging that records who called which tool with which arguments, since you will need that trail for incident review and compliance.
Set timeouts on backend calls so a slow dependency does not pin server resources. Where a tool performs a destructive or irreversible action, consider a confirmation step surfaced through the host rather than silent execution. Observability deserves the same attention you would give a model pipeline; the patterns in this LLM observability tools guide apply directly to traffic flowing through your servers. Under load, you can expect agent traffic to be bursty and parallel, so size connection pools accordingly.
When to expose a system via MCP, and when not to
MCP shines when multiple model clients need the same capability, or when you want a clean, reusable integration that outlives any single application. A shared internal MCP server for your ticketing system, consumed by several assistants, pays for itself quickly. It also fits retrieval-heavy work; if you are wiring a model to a knowledge base, the chunking and indexing decisions in this retrieval-augmented generation guide matter as much as the protocol wrapper around them.
Conversely, do not reach for MCP when a single deterministic service call would do. If your application already knows exactly which API to invoke and the model is not choosing among options, a plain function call or a custom API is simpler and easier to secure. MCP adds a discovery and negotiation layer whose value depends on a model actually exercising that flexibility. When the flexibility is unused, the layer is overhead.
In conclusion, Model Context Protocol MCP servers give enterprise teams a standardized, reusable way to connect large language models to real tools and data. Master the three primitives, pick the transport that matches your deployment, enforce authorization on the server with least privilege, and harden the endpoint as you would any model-facing API. Build the integration once, secure it deliberately, and any compatible host can use it safely.