MCP gives us a consistent interface layer between models (clients) and tools and data systems (servers). That alone is valuable. It makes tool discovery and interaction more structured and portable across AI clients.

But the protocol itself does not guarantee a good outcome.

If you treat MCP server design as an API wrapper exercise, you get:

• hundreds of granular “tools”
• ambiguous selection behavior
• bloated context windows
• higher failure rates
• more operational risk

If you treat MCP server design as a product problem you get something different, like the Itential MCP Server:

• curated, intention-level capabilities
• predictable tool selection
• bounded context
• deterministic execution around probabilistic reasoning
• a path toward governance

So let’s talk about how to build MCP servers that scale.

The easiest way to build an MCP server is to map endpoints to tools. That is also the fastest way to make MCP feel like “just another abstraction layer.”

Because now your model has to behave like an integration engineer: call tool A, then tool B, then tool C, interpret tool D’s output, then decide which tool to use next.

That’s not what you want a model doing in production operations.

Instead, start with the outcomes you want the model to achieve safely:

• “check compliance for a device group against a policy”
• “summarize drift and risk against golden intent”
• “stage a change and generate a rollout plan”
• “propose remediation within constraints”

When you expose outcomes, you shift complexity out of the model and back into deterministic automation logic, where it belongs.

MCP is built for discovery. That is one of its strengths. It’s also one of its sharpest edges.

If your MCP server exposes “everything,” you are creating a choice architecture that models struggle to navigate consistently. High tool count tends to create:

• tool confusion
• increased token consumption
• higher failure rates
• inconsistent paths to the same outcome

Instead, curate for:

• clarity: tools should be distinct, not overlapping
• minimalism: fewer tools, better descriptions
• predictability: small action space yields better selection behavior
• safety: separate read tools from write tools, and make writes explicit

MCP supports resources so that models can retrieve context without invoking actions. This is powerful, but it’s easy to misuse.

A bad pattern is exposing giant resources: full inventories, full configs, broad logs, entire databases. That doesn’t “help the model.” It overwhelms it.

A better pattern is treating resources as bounded context contracts that align to decision-making:

• scoped inventory for a target group
• relevant config fragments
• the minimum policy text needed for compliance reasoning
• just enough context to make a safe decision

In MCP, prompts are not just convenience templates. They are one of the most practical mechanisms you have to standardize operational behavior across clients and use cases.

Think of prompts as SOPs for models. This is where you encode:

• how to interpret results
• what validation steps to run
• how to handle uncertainty
• when to stop and escalate
• what “done” actually means

Here’s the tension that defines AI operations:

Models reason probabilistically. Infrastructure must execute deterministically.

MCP does not eliminate this. But it gives you a structured interface where controls can be consistently applied.

At minimum, production MCP servers need:

• least privilege access
• scoped credentials and token discipline
• separation of read and write tools
• auditability of tool execution
• explicit side-effect disclosure for any state-changing action

OWASP’s MCP security guidance highlights risks like over-privileged tool exposure, secret leakage, and unsafe tool invocation – and it reinforces why strong access control and context isolation are foundational.

A practical pattern that works well: make reads easy, make writes expensive, require validation gates before execution, and use orchestration for deterministic workflows rather than agent improvisation.

The difference between a demo and production is always the same: what happens when it fails?

In operational environments, MCP tools need:

• structured error reporting
• clear failure modes
• progress updates for long-running operations
• consistent logging and observability
• predictable responses that clients can recover from

A well-designed MCP server usually has:

• a small set of intent-level tools
• resources that provide scoped context
• prompts that encode operational discipline
• explicit side effects and constraints
• least privilege tool exposure and auditability
• production-grade failure behavior

Most importantly: the model is not integrating your systems. Your automation and orchestration platform is. 

MCP is rapidly becoming a default way for models to discover and use tools. The protocol’s value is portability and consistency across the AI ecosystem.

But the teams who win with MCP will not be the ones who expose the most tools. They will be the ones who design the best capabilities – purposeful, curated, safe, observable, and aligned to operational outcomes.

Because infrastructure doesn’t care that the operator is a model. It still demands control, predictability, and accountability.

If you want the full talk that sparked this post, you can watch the on-demand session here or below.

And if you’re exploring how MCP fits into real orchestration workflows, the AutoCon 4 workshop repo is a great starting point for understanding the practical patterns teams are already using.