Before You Build an MCP Server: Start With the Capability, Not the Technology - Part 2

In Part 1, I started with a question that keeps surfacing in AI architecture work:

What capability is the system missing?

The answer is usually less glamorous than the toolbox. We don’t need to decide between prompt, skill, retrieval, tool, MCP, and agent in the abstract. We need to decide which missing capability is actually blocking the outcome.

That is the practical question behind this playbook.

Start without the technology

Before choosing an architecture, rewrite the requirement without saying agent, MCP, RAG, or even LLM.

Instead of:

Build an MCP server that allows an agent to assess vulnerabilities.

Start with:

Determine whether a vulnerability affecting an application is relevant, gather supporting evidence, and recommend a treatment.

That keeps the design open. It also makes the missing capability visible. If the system cannot do the work today, what is it missing?

The key is not “move up the stack.” The key is “match the gap to the control.” A useful system may combine retrieval, a skill, and two tightly scoped tools and stop there.

“The right architecture is the smallest one that closes the gap.”

When does MCP earn its place?

A need for an external system does not automatically create a need for MCP.

If an application simply needs to query an internal dependency service, a direct tool integration may be entirely reasonable. If that capability has to work across coding assistants, IDEs, security agents, or services owned by different teams, a common interface becomes more valuable.

MCP also makes sense when portability, discovery, or independent ownership matters, even before the consumer count is huge.

Before adding MCP, ask a few questions:

• Will a standard interface remove a meaningful amount of client-specific integration?
• Does this capability need to evolve independently of the applications that consume it?
• Will discovery or portability across AI hosts create real value?
• Will MCP make governance and authorization easier, instead of just moving the problem?
• If I used a direct tool integration instead, what would I actually lose?

If the last question is hard to answer, the MCP requirement is probably weak.

This keeps the decision tied to what MCP actually provides. The July 2026 specification moved the protocol toward a stateless core, added self-describing requests and discovery, improved routing, and continued authorization hardening (Soria Parra & Delimarsky, 2026). Those are useful protocol capabilities. They still need a problem that benefits from them.

When the system can act, ask five more questions

Karanjai et al. (2026) study agents in environments where signing authority, continuous autonomy, irreversible transactions, and sequences of actions can turn a model error into a real loss. Enterprise systems are different, but the same questions transfer well.

1. Can we undo the action?

Creating a draft ticket is not the same as deleting production data.

2. What authority sits behind it?

The relevant authority is the identity and runtime around the model. A narrowly scoped read credential is different from a production service account.

3. What can influence the decision?

External documents, tickets, emails, web content, and prior tool results may all affect what the model does next.

4. What happens when actions are combined?

Three individually acceptable calls can still produce an unacceptable outcome when performed in sequence.

5. Who can invoke the capability?

A tool available to one controlled workflow has a different exposure than the same capability available broadly across agents or users.

These questions are not a replacement for threat modeling. They are a way to catch the architecture decisions that look small but deserve more scrutiny.

MCP itself offers useful metadata here. Tools can declare hints such as whether they are read-only, destructive, idempotent, or interact with an open external environment (Model Context Protocol, 2026). Those hints are useful, but they are not authorization controls. The specification explicitly treats them as hints and warns clients not to trust annotations from an untrusted server.

The enforcement still belongs in code, identity, authorization, and policy.

Match the control to the action

Not every tool call needs a human approval screen.

A read-only lookup over non-sensitive information may need little beyond normal access controls, validation, and observability. Access to sensitive information should use appropriately scoped identity and auditability. A write operation may need validation, idempotency, limits, or a preview. Privileged or destructive actions may justify explicit approval, narrowly scoped credentials, transaction limits, and recovery paths.

Agents that combine tools need one additional consideration: the allowed sequence.

Checking each API call independently is not always enough. The risk may appear only after several calls are combined. For higher-authority workflows, boundaries may need to cover which tools can be used together, how often they can run, what limits apply, and when the workflow must stop.

Put the playbook against a real problem

Consider the vulnerability-assessment requirement again.

The simple architecture might use deterministic code for policy thresholds, retrieval for advisories and internal standards, and a skill for the organization’s assessment procedure. Bounded tools could query the dependency graph or run a proof-of-vulnerability check.

MCP enters the design only if those capabilities benefit from a common interface across AI clients or teams.

An agent enters only if model judgment is valuable in deciding which evidence to gather, which test to run, or what to investigate next. There is no payoff in making the entire workflow agentic.

A stateless architecture review prompt

I also wanted a version of this playbook that could be applied without relying on previous conversation history. The prompt below carries the decision criteria with it:

You are reviewing an AI architecture.

Recommend the simplest combination of capabilities that can
reliably solve the problem.

Do not assume that MCP, an agent, RAG, a skill, or even an LLM
is required.

PROBLEM
Describe the problem without prescribing the technology:

[INSERT]

USERS
Who will use the system?

[INSERT]

INFORMATION
What information must it access?

[INSERT]

ACTIONS
What external systems must it read or change?

[INSERT]

CONSUMERS
Will the capability be used by one application, multiple
applications, multiple teams, or external clients?

[INSERT]

CONSTRAINTS
Security, regulatory, reliability, latency, cost, or other
important constraints:

[INSERT]

Evaluate the need for:

CODE
Reliable deterministic rules or workflows.

PROMPT
Instructions or reasoning using information already available.

SKILL
A reusable specialized procedure.

RETRIEVAL
Access to changing, proprietary, or external information.

TOOL
A defined interaction with an external system.

MCP
A common interface when standardization, discovery, portability,
reuse, or independent capability ownership provides clear value.

AGENT
Model judgment is required to select, sequence, or adapt actions
based on what is discovered.

If external actions are required, also evaluate:

- Can the action be reversed?
- What authority or credentials are involved?
- What untrusted information can influence the decision?
- Can individually acceptable actions become unsafe in sequence?
- Who can invoke the capability?

Return:

1. Capability gaps
2. Smallest sufficient architecture
3. Why each component is needed
4. Components that are not needed
5. MCP: justified or not justified, and why
6. Main action and authority risks
7. Required controls
8. Next-simpler architecture and why it is insufficient
9. Confidence: High / Medium / Low

One thing stands out to me: architecture reviews naturally focus on what should be added. Asking what can be removed creates useful resistance to adding another service, agent, protocol, or integration simply because it is available.

The decision is usually smaller than the toolbox

AI tooling will keep changing. MCP changed significantly in 2026, and the boundaries between models, tools, agents, and protocols will continue to move.

But the underlying decision is more stable.

Start with what the system cannot do. Add only what closes that gap. When it can act, understand what authority sits behind the action and what happens if it gets the decision wrong.

Use MCP when a common AI interface provides value. Use an agent when model judgment over the path provides value. Keep deterministic decisions deterministic.

The technology should earn its place in the architecture.

References

Karanjai, R., Lu, Y., Diallo, N., Xiong, W., Xu, L., & Shi, W. (2026). When agents act on Web3: An attack-surface survey of MCP, skills, and tool calling [Preprint]. arXiv. https://arxiv.org/abs/2608.17275

Model Context Protocol. (2026, March 16). Tool annotations as risk vocabulary: What hints can and can’t do. https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/

Soria Parra, D., & Delimarsky, D. (2026, July 28). The 2026-07-28 specification. Model Context Protocol Blog. https://blog.modelcontextprotocol.io/posts/2026-07-28/