Most teams start by asking: “What can we expose from this application?” That’s the wrong question.
The wrong unit of design
There’s an assumption baked into that starting point:
One application = one MCP Server.
It makes sense on the surface. Applications already define boundaries. APIs are organized that way. Permissions often align. So the path feels obvious: take an application, expose its capabilities, define tools.
But MCP Servers aren’t built for applications. They’re built for LLMs making decisions. That changes what “good design” looks like.
What goes wrong when you map application → server
The LLM isn’t confused. The design is.
When you define a server around an application, you usually end up with multiple personas — sales, support, admin — sharing the same space, competing workflows with no clear priority, and a growing list of tools that “might be useful.” On paper, it looks comprehensive. In practice, it creates one predictable problem.
The same user request can map to multiple valid actions. So the LLM has to decide: which tool applies? Which path is correct? Which interpretation is intended?
Every extra path is another opportunity to choose wrong.
MCP Servers aren’t organized around systems
Here’s the shift.
LLMs don’t think in system boundaries. They operate on intent → action → outcome. If your server mixes multiple intents and workflows, you introduce multiple possible paths. That’s the design problem — not the model.
MCP Servers should be defined by who is using them, what they’re trying to do, and how that work completes. Not by applications, APIs, or objects.
What to do instead
- Define the persona Who is this server for? Support agent? Sales rep? Marketing ops? If the answer is “multiple unrelated roles,” that’s your first warning sign. One server, one primary user.
- Define the core use cases Not “manage customers” or “work with tickets” — but “investigate a billing issue”, “update deal stages after a call”, or “respond to support tickets.” Specific, completable actions that mean something.
- Define the workflow boundary What does “done” look like? A good MCP Server lets the LLM complete a meaningful unit of work end-to-end without bouncing across unrelated concepts.
- Now design your tools Once persona, use cases, and workflows are clear, the right tools become obvious. Overlap disappears. Naming gets easier. Boundaries sharpen.
Tools aren’t the starting point. They’re the outcome of good scoping.
Why this works
This approach does one critical thing: it reduces the number of valid interpretations.
Fewer competing tools. Clearer intent → action mapping. More predictable behavior.
Good MCP design removes choices. Bad MCP design creates them.
Three questions before you write a single tool
Before you write a single tool, ask:
- Can I describe this server in one sentence?
- Is it clearly for one persona (or closely related ones)?
- Can a core use case complete end-to-end within this server?
If not, you don’t have a tool problem. You have a scope problem.
The bottom line
Don’t start with the application. Start with the person using it, the thing they’re trying to do, and what “finished” looks like. The right tools will follow.