MCP Server Patterns I Actually Use in Production

Model Context Protocol servers are the cleanest way to give an agent tools. After building six of them for my own workflow, I have settled on three patterns that survive daily use. Everything else is speculation. These are the ones that earned their place.

Pattern One: The Read-Only Reporter

The most valuable MCP server I wrote reads from my content database and reports counts, category distribution, and recent activity. It does not write anything. It does not need auth beyond the local machine. It gives the agent a precise answer to questions like 'how many articles in the Python category' without the agent running a curl command or scraping a dashboard.

Read-only servers are safe to add, easy to test, and immediately useful. Start here.

Pattern Two: The Scoped Writer

A writer server exposes exactly one operation. Not a generic database client. One operation: 'publish a post', 'create a draft', 'archive an old version'. The narrower the surface, the easier to reason about what the agent might do. A writer with twenty endpoints is a liability. A writer with two is a tool.

Pattern Three: The Dry-Run Default

Every writer I build has a dry-run mode that is the default. The agent sees what would happen, reports it, and waits for a confirmation token before the real write. This turns the agent into a proposer, not an actor. I make the final call.

@server.tool('publish_post')
def publish_post(slug: str, confirm: str = None):
    if confirm != 'yes-actually':
        return {'dry_run': True,
                'would_publish': slug,
                'next_step': 'repeat with confirm=yes-actually'}
    # real write path
    return do_publish(slug)

What I Stopped Building

I tried writing generic 'SQL runner' and 'filesystem' servers. Both got dangerous fast. The agent will do what you let it do, which is why scoped servers beat generic ones. The MCP specification is deliberately simple for this reason.

The Payoff

These three patterns composed give me agents that can report, propose, and act, in that order, without ever surprising me. Eight months in, I have not had a single incident from an MCP server. That is the bar.

When to Build One

A new MCP server earns its place when the agent would otherwise run a complex sequence of commands that it gets wrong half the time. A single tool call replaces ten lines of brittle shell. If the agent already handles the task reliably with existing tools, a server is overengineering. I keep a short list of 'commands the agent struggles with' and promote them to servers once they show up three times. Three strikes is the build threshold.