MCP Patterns for Production Agents

Our Claude Code for .NET configuration guide covers how to set up MCP. This guide is about the patterns: the reusable shapes of MCP server that work in production, and how to run them safely. It pairs with our guide on governing the AI agent supply chain, which covers the security model these patterns sit inside.

What is MCP, and why does it need patterns?

The Model Context Protocol (MCP) is an open standard for connecting an AI agent to external systems through a common interface. An MCP server exposes a system as a set of tools the agent can call, and because both Cursor and Claude Code support it, the same server works across tools.

Configuration tells you how to connect a server. Patterns tell you what kind of server to build and how to scope it. That distinction matters, because the difference between a useful MCP layer and a dangerous one is not in the wiring. It is in the design: what each server can reach, whether it can change state, and how its access is bounded. The patterns below are the shapes we reach for repeatedly.

Pattern 1: the read-only data server

A read-only data server exposes information the agent can read but never change. It is the safest pattern and should be your default, because an agent cannot misuse access it does not have.

Typical read-only servers expose:

• Logs and observability data, so the agent can diagnose a failure.
• Work items and tickets, so it understands the task in context.
• Build and test results, so it grounds its next step in real signals.

Because there is no write path, a read-only server is low risk even when the agent reads untrusted content through it. Reach for this pattern first, and only escalate to an action server when the task genuinely needs to change something.

Pattern 2: the gated action server

An action server can change state, so it must be gated behind explicit approval. This is the pattern that needs the most care, because a state-changing tool is exactly what a bad instruction would try to misuse.

The rules we apply to action servers:

• One purpose per server. A deployment server deploys; it does not also read unrelated data.
• Explicit approval for state changes. Writes, deletes, and deploys require a confirmation step, not silent execution.
• Scoped, rotatable credentials, so a server holds only the access its single purpose needs.
• Full call logging, so every action the agent took is recorded.

Keeping action servers narrow and gated is what lets you give agents real capability without widening the blast radius of a mistake.

Pattern 3: the work-tracker server

A work-tracker server connects the agent to your backlog so it grounds changes in real tasks rather than its own guess at the work. It is usually read-mostly, with tightly gated writes for status updates.

In our case this exposes Azure DevOps work items, so the agent can read the task it is implementing, link a change to it, and update status through an approved path. Grounding the agent in the actual work item reduces drift: the agent builds what was asked, against the acceptance criteria that already exist, instead of inferring intent from the code alone.

How do you authorise and scope an MCP server?

Apply least privilege to every server, the same way you would to any production credential. The protocol gives the agent reach; scoping is what keeps that reach proportionate.

The controls, in order of importance:

• Prefer read-only. Most value comes from reading; grant write access only where a task needs it.
• Separate read from action, so no single server both reads broadly and changes state.
• Issue per-server credentials that are scoped and rotatable, never one broad shared token.
• Log every tool call, so the audit trail shows what the agent did, not just what it could do.

These controls are also the governance evidence regulated work needs. We cover the full supply-chain view, including inventory and change review, in governing the AI agent supply chain.

How do you make MCP output agent-readable?

Design each tool’s output so the agent can act on it, not just receive it. An MCP tool that returns a raw error is far less useful than one that returns a structured result with guidance on what to do next.

In practice:

• Return structured data the agent can parse, not opaque blobs.
• Include the next action where you can, for example “test failed: assertion X; the expected value is Y”.
• Keep responses focused, so they do not crowd the context window.

This is the same principle as agent-readable sensor output: the most useful signal tells the agent how to fix the problem, which raises the chance it self-corrects before a human is involved.

Why invest in MCP over tool-specific rules?

Because MCP servers are portable, and portability is where integration effort pays back. Tool-specific rules and skills are tied to one IDE. An MCP server works in any tool that speaks the protocol, so it survives a switch between Cursor and Claude Code, or running both at once.

As the harness engineering guide puts it, the most durable outer-harness investments are MCP servers, AGENTS.md, and CI checks; the least durable are tool-specific rules. If you are deciding where to spend integration effort, the MCP layer is the part you will not have to rebuild when your tooling changes.

How does MCP governance map to regulated work?

Scoped, versioned, logged MCP servers produce exactly the evidence UK regulated work expects, so governing them is an assurance activity, not overhead.

• ISO 27001 asks for access control and change management; per-server scoping and review supply both.
• The EU AI Act expects documented, controlled systems; a versioned set of connectors is that documentation. See our EU AI Act and custom software guide.
• Procurement and Cyber Essentials ask who can access what; per-call logging answers it precisely.

How does Talk Think Do run MCP in production?

We run a small, governed set of servers, recorded in the Q1 2026 AI Velocity Report:

• Six live custom MCP servers cover work items, test execution, logging, Azure, CI/CD, and GitHub.
• Read access is separated from action access, and state-changing operations are gated.
• Servers are versioned in the repository and changed through review, inside our ISO 27001-certified framework.
• The servers feed the agent real signals, so it self-corrects against the actual system rather than its own model of it, which is part of how we sustain 84% AI-authored code.

The pattern that holds across all six is the same: narrow purpose, least privilege, and a clear separation between reading and acting. To design or review an MCP layer for your own systems, see our AI integration service or book a free consultation.