What Is an MCP Server? The Production Boundary for AI Tools

The short definition

MCP means Model Context Protocol, an open protocol for integrating LLM applications with external data sources and tools. The current MCP specification is version 2025-11-25, and the core idea is stable enough to define plainly: a host application connects to one or more MCP servers, discovers what each server exposes, then routes approved context and actions through the protocol.

That makes an MCP server a boundary program. It is the thing your AI application talks to when it needs a database schema, a search result, a GitHub issue, a CRM record, a support macro, or a controlled write action. The model may decide it needs a tool. The host and client decide whether that tool is available. The MCP server implements the actual surface.

The most useful mental model is:

The practical line: do not call something "just an MCP server" if it can touch money, credentials, customer data, production infrastructure, or write paths. Treat it like an integration boundary with a model-facing control plane.

The production boundary

An MCP server should be designed around the weakest permission it needs, not the most impressive action it can expose. The official architecture says an MCP host creates one MCP client for each MCP server connection. The server can run locally or remotely: local servers commonly use stdio transport, while remote servers commonly use Streamable HTTP transport.

That deployment choice changes the risk model.

For example, a support engineering team may expose three capabilities:

• tickets.search, a read-only tool that queries current support tickets.
• customers.profile, a resource that returns the permitted subset of account context.
• tickets.draft_reply, a prompt that structures a proposed answer but does not send it.

That is a useful MCP server. tickets.refund_customer is a different class of tool. It needs a human approval gate, policy checks, idempotency, and an audit event that survives outside the chat transcript.

If you are already at the implementation stage, the build path is different from the definition path. Start with production internal APIs, then come back to this boundary model for what should be exposed first.

How the protocol actually works

MCP uses JSON-RPC 2.0 messages, stateful connections, and capability negotiation. All MCP implementations must support the base protocol and lifecycle management components. The lifecycle matters because the host should not discover and call tools blind. It initializes a session, negotiates protocol version and capabilities, then discovers the server features it is allowed to use.

A simplified production flow looks like this:

{
  "jsonrpc": "2.0",
  "id": "init-001",
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": {},
      "elicitation": {}
    },
    "clientInfo": {
      "name": "agent-host",
      "version": "1.0.0"
    }
  }
}

The exact SDK code will differ, but the production sequence should not:

The data layer defines JSON-RPC communication, lifecycle management, server features, client features, and utility features. The transport layer defines communication mechanisms, message framing, connection establishment, and authorization. Streamable HTTP uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming and supports standard HTTP authentication methods including bearer tokens, API keys, and custom headers. MCP recommends OAuth to obtain authentication tokens for Streamable HTTP.

That last point is where many demo setups fail. A local tool can be useful with a developer-scoped environment variable. A remote server that fronts customer data needs real authorization design.

Tools, resources, and prompts are separate controls

Do not expose everything as a tool. MCP servers can expose resources, prompts, and tools to clients, and each primitive deserves a different control.

Servers that support tools must declare the tools capability. Clients discover tools with tools/list and invoke tools with tools/call. Tool input schemas default to JSON Schema 2020-12 if no schema field is present, and they must be valid JSON Schema objects. That is the place to make the contract sharp.

{
  "name": "tickets_search",
  "title": "Search support tickets",
  "description": "Find recent support tickets by account ID and status.",
  "inputSchema": {
    "type": "object",
    "required": ["account_id"],
    "properties": {
      "account_id": { "type": "string", "pattern": "^acct_[a-z0-9]+$" },
      "status": { "type": "string", "enum": ["open", "pending", "closed"] },
      "limit": { "type": "integer", "minimum": 1, "maximum": 25 }
    },
    "additionalProperties": false
  }
}

Resources are different. Servers that support resources must declare the resources capability. Clients discover resources with resources/list and retrieve resource contents with resources/read. Resources can contain text or binary data. A resource is a good fit for context the model can read but should not mutate, such as a database schema or a runbook page.

Prompts are different again. Prompts are designed to be user-controlled and intended for explicit user selection. Clients discover prompts with prompts/list and retrieve specific prompts with prompts/get. Prompt implementations must carefully validate all prompt inputs and outputs to prevent injection attacks or unauthorized resource access.

The strong rule is simple: tools are actions, resources are context, prompts are workflows. Mixing them together makes approvals and audits harder than they need to be.

The minimum production shape

A production MCP server starts with one narrow business capability and earns expansion. The protocol can expose powerful surfaces, but the MCP specification is explicit that it cannot enforce its security principles at the protocol level. Implementors have to build robust consent and authorization flows, access controls, and data protections around it.

For a first internal server, ship this shape:

MCP authorization is optional in the protocol, but HTTP-based transport implementations should conform to the MCP authorization specification, while stdio implementations should retrieve credentials from the environment. For protected HTTP servers, the spec frames a protected MCP server as an OAuth 2.1 resource server, an MCP client as an OAuth 2.1 client, and an authorization server as the component that issues access tokens. MCP servers must implement OAuth 2.0 Protected Resource Metadata, and MCP clients must use it for authorization server discovery.

That is more than ceremony. It is what lets a host know which authorization server to use, which scopes to request, and how to recover from a 401 Unauthorized without hard-coding one-off credential behavior.

If this server will cross trust boundaries, pair this article with the deeper MCP security boundary before adding write tools.

What to log before the first real user

Log the attempted action, not just the successful result. Hosts must obtain explicit user consent before exposing user data to servers, hosts must obtain explicit user consent before invoking any tool, and users must explicitly approve any LLM sampling requests. If the log only captures successful tool calls, it misses the policy decisions that matter most during review.

A useful audit event is boring and structured:

{
  "event_type": "mcp.tool_call_attempt",
  "request_id": "req_01jz...",
  "session_id": "sess_01jz...",
  "tenant_id": "tenant_123",
  "user_id": "user_456",
  "host": "support-agent-console",
  "server": {
    "name": "support_ops_mcp",
    "version": "2026.07.04",
    "transport": "streamable_http"
  },
  "tool": {
    "name": "tickets_search",
    "risk_class": "read_only",
    "schema_version": "1"
  },
  "authorization": {
    "scope": "tickets:read",
    "decision": "allowed"
  },
  "approval": {
    "required": false,
    "state": "not_required"
  },
  "input": {
    "classification": "customer_support_metadata",
    "redacted": true
  },
  "result": {
    "status": "success",
    "duration_ms": 184,
    "records_returned": 12
  }
}

For write tools, add approval.required: true, the approver identity, the displayed diff, and the idempotency key. For denied calls, keep the requested tool name, risk class, denial reason, and policy version. Do not store raw secrets, access tokens, private prompts, or full customer payloads unless your retention policy explicitly allows it.

Where approval belongs

Approval belongs at the host workflow boundary and the server policy boundary. The host is where the user understands the proposed action. The server is where the system enforces whether the action is allowed even if the host or model is wrong.

Use two gates:

1. Host gate: show the user the tool name, target object, material arguments, expected side effect, and result of not approving.
2. Server gate: verify token scope, tenant, object-level permission, risk class, rate limit, and idempotency before execution.

This catches the common failure where a model phrases a proposed action correctly but the arguments point at the wrong tenant, stale object, or over-broad target set.

The approval policy should be simple enough to test:

Clients must consider tool annotations untrusted unless they come from trusted servers. That means "this tool is read-only" cannot be accepted because a random server says so in a description. Your registry needs a trusted source of risk metadata.

What breaks first

The first production failure is usually not the JSON-RPC envelope. It is a boundary mistake: too many tools, unclear scopes, missing audit events, vague schemas, or a host that treats every discovered tool as equally safe.

The fix is to make the MCP server smaller:

• Split read tools from write tools.
• Keep resources separate from actions.
• Give every tool a narrow input schema.
• Add server-side tenant and object checks even if the host already checked.
• Store policy decisions as events.
• Version the tool contract before changing behavior.
• Run evals against allowed, denied, malformed, and prompt-injection cases before publishing new tools.

A good MCP server feels unimpressive at first. It exposes fewer actions than the internal API can technically support, and it says no often. That restraint is the point: the model gets a reliable, typed, observable surface, while the business keeps control over data and side effects.

FAQ