MCP servers, built for the systems a security review actually protects

What a server actually is, and why one per system is the right unit

An MCP server is a small service that exposes tools, resources and prompts over the Model Context Protocol. A CRM server exposes tools like lookup-contact and create-ticket; a database server exposes read-query against approved tables; an engineering system server exposes search-part with the PLM's own access rules. The AI assistant connects to the server as a client, and the server decides what the model may call, which is the entire point of the architecture: the capability boundary sits in a component you own, not inside the model.

One server per system is the right unit for two reasons. The first is failure isolation: a server that breaks takes down its own system's tools, not the whole assistant estate. The second is governance: each server carries its own tool list, permission model and audit trail, so the security review of the CRM integration is a review of one small, readable component rather than of a feature buried inside an application.

The transport matters less than the protocol's shape. Servers can run as local processes over stdio or as network services over Streamable HTTP, and the choice is an operations decision: local for a desktop assistant, HTTP for a service other teams reach. The tools, resources and prompts vocabulary is what makes the ecosystem interoperable, and that is where the standard's value sits rather than in the wire format.

Executable artefact

The server skeleton, and the two lines that define its boundary

Framework and language are placeholders; every MCP SDK ships the same shape. The tool registration and the permission check are the two lines that make this a controlled interface rather than an open door.

# MCP server skeleton (conceptual, any SDK)
from mcp.server import Server, Tool

server = Server("crm")

@server.tool
def lookup_contact(contact_id: str) -> dict:
    """Find a contact by ID in the CRM."""
    # THE BOUNDARY: the caller's identity decides what may be read.
    if not can_read("crm.contacts", caller=caller_id()):
        raise PermissionError("no read access to contacts")
    return crm.get(contact_id, fields=["id", "name", "account"])

@server.tool
def create_ticket(subject: str, body: str) -> dict:
    """Open a ticket in the support queue."""
    if not can_write("crm.tickets", caller=caller_id()):
        raise PermissionError("no write access to tickets")
    return crm.tickets.create(subject=subject, body=body)

# Register the tool catalogue; the assistant sees only what is listed here.
server.register([lookup_contact, create_ticket])
server.run(transport="streamable-http")

The permission check inside each tool is the pattern that survives a security review; tools without it read whatever the underlying API allows.

Build order

The five steps from first server to approved estate

1. Pick the first system by value, not by ease. The CRM or the engineering system the assistant will actually be asked about. The first server proves the pattern and the review; it should be the one that matters.
2. Define the tool list with the system owner, tool by tool. Each tool is a capability decision: what the model may call, what it may read, what it may change. The list is the contract the security review reads.
3. Implement the permission checks inside the tools. Caller identity, scoped reads, denied writes by default. The pattern in the skeleton above, applied to every tool before the first one ships.
4. Stand up the registry and the sandbox before the second server. The registry makes the estate reviewable; the sandbox makes it survivable. Both are infrastructure decisions, not per-server afterthoughts.
5. Run the review on the first server and fix the class, not the instance. The first security review will find gaps. Fix the pattern they reveal, not the one server, so the second and third pass faster.

Why this matters now: the assistant is only as good as the systems it can reach

The reason MCP is the integration pattern worth building around is that the number of assistants is about to exceed the number of systems. An engineering company with a CRM, an ERP, a PLM and a quality system will run a service desk assistant, a search assistant and a maintenance assistant, and the alternative to a protocol is a tangle of bespoke integrations that each carry their own security story. The protocol collapses that into servers, each reviewed once, each with its own boundary.

The enterprise case is not the demo case. A demo server that reads a public table is a weekend project; a server that reads contracts and writes tickets is an infrastructure component with an owner, a review and an audit trail. The difference is exactly the three controls above, and it is why we build MCP servers as a fixed-scope engagement rather than as an add-on to something else: the security layer is the deliverable, not the protocol call.

What we have not done is run a full multi-server MCP estate in production for a customer, so nothing here is drawn from one. The argument is structural: it rests on what the protocol defines, what the tool pattern requires, and what a security review will ask, all of which are knowable before the first deployment.

Sources: Model Context Protocol specification and documentation · Anthropic — Introducing the Model Context Protocol. Read 2026-09-14. Vendor documentation changes; verify against the current release.

Keep reading

• Claude MCP server development for internal systems
• Claude in your own cloud tenant: Bedrock or Azure under your own IAM
• LLM gateway for Claude: per-team budgets and audit-grade logging
• Claude Enterprise hub: rollout past the first team