Designing High-Quality MCP Servers

An MCP server is not just an API wrapper.

The easy version is to expose every backend endpoint as a separate tool. The useful version starts from the workflow the user wants to complete, then gives the model a small set of clear, safe, high-leverage tools.

MCP Origin Story

MCP started from a practical problem: people kept copying context from external systems into the model by hand.

flowchart LR
    A["David and Justin notice repeated context copying"]
    B["Small internal team builds MCP"]
    C["MCP goes viral at Anthropic hack week"]
    D["Anthropic open sources MCP"]
    E["Coding tools adopt MCP"]
    F["Major AI companies and tools adopt MCP"]

    A --> B --> C --> D --> E --> F

The design goal was bigger than reducing copy-paste. It was about model agency: letting models fetch context and take actions through a standardized open interface.

Why Open Protocol Matters

Without a standard, every integration becomes a custom negotiation:

Find the right client or platform team.
Align on a private interface.
Build the connector.
Repeat the same work for the next client.

That does not scale when agents need access to many systems.

MCP improves the shape of the ecosystem because servers can expose capabilities once, and compatible clients can consume them without bespoke partnership work.

The Three Users Of An MCP Server

A good MCP server has three users:

User	What they need
End user	The task should complete correctly and safely
Client developer	The server should be easy to connect, test, and debug
Model	Tools should be understandable, scoped, and hard to misuse

Most weak MCP servers optimize only for the API owner. They mirror backend endpoints but do not help the model decide what to call.

Design From Prompts, Not Endpoints

Start with the prompts users will actually ask:

“Find the contract renewal risks for this account.”
“Summarize open finance exceptions this week.”
“Create a draft follow-up email for this sales opportunity.”
“Book the best flight to Atlanta.”

Then design tools around the model’s decision path.

flowchart TD
    A["User workflow"] --> B["Likely user prompts"]
    B --> C["Model decisions needed"]
    C --> D["Tool set"]
    D --> E["Tool input schemas"]
    E --> F["Safe execution and review points"]
    F --> G["Result format for the model"]

The tool surface should make the right model behavior obvious.

Bad Pattern: One Endpoint, One Tool

Avoid blindly exposing backend endpoints:

Backend endpoint	Weak MCP tool
`GET /customers/{id}`	`get_customer`
`GET /invoices?customer_id=...`	`list_invoices`
`GET /tickets?customer_id=...`	`list_tickets`
`POST /notes`	`create_note`

This may be technically correct, but it forces the model to reconstruct product intent from low-level primitives.

Better Pattern: Workflow-Level Tools

Prefer tools that match user intent:

Workflow	Better tool
Account review	`analyze_account_risk`
Renewal prep	`prepare_renewal_brief`
Finance exception triage	`summarize_open_exceptions`
Sales follow-up	`draft_follow_up_email`

These tools can still call the same backend endpoints internally. The difference is that the MCP boundary exposes a useful task, not database plumbing.

What Makes A Tool Model-Friendly

Good tools have:

clear names with verbs and domain nouns
short descriptions that say when to use the tool
narrow input schemas
explicit required fields
safe defaults
bounded result sizes
predictable output formats
clear error messages

Poor tools have:

vague names like execute, fetch, or run_query
huge optional parameter bags
backend-specific jargon
unbounded results
side effects without confirmation
unclear permission requirements

Use Elicitation For Missing Details

Some user requests are underspecified.

If the user says “book the best flight,” the server may need to ask whether “best” means cheapest, fastest, fewest stops, or preferred airline. MCP elicitation exists for this class of interaction: the server can ask the user for missing information instead of guessing.

Use elicitation when:

the missing detail materially changes the action
a default would be risky
the server needs user preference or consent
the model should not invent the missing field

Server Quality Checklist

Before calling an MCP server production-ready, check:

Does each tool map to a real user workflow?
Can the model infer when to use each tool from the description?
Are destructive actions separated from read-only actions?
Are result sizes bounded?
Are errors written for a model to recover from?
Is authentication clear to the client developer?
Can the server be tested in MCP Inspector?
Are high-risk calls logged for audit?
Are prompts, resources, and tools documented together?

Vertical Opportunities

Much of the early MCP ecosystem is developer-tool heavy. There is room for high-quality vertical servers in:

sales
finance
legal
education
healthcare operations
customer support
procurement
internal knowledge management

The winning servers in these areas will probably not be the broadest API wrappers. They will be the ones that understand the domain workflow well enough to expose the right model-facing actions.

Where Tooling Startups Can Help

There is also room for infrastructure around MCP server development:

server hosting
testing harnesses
eval suites
deployment tooling
registry and discovery workflows
security scanning
observability and audit logs
automated server generation

Automated MCP server generation is still a forward-looking bet, but the direction is clear: as models get better at coding and tool use, they will need ways to create or adapt integrations faster.

Key Takeaways

Design MCP servers around workflows, not backend endpoints.
Treat the model as a first-class user of your tool interface.
Keep tools narrow, named clearly, and easy to recover from.
Use elicitation when user intent is incomplete.
Vertical servers are a major opportunity because most current MCP examples are still developer-centric.