How to Curate a Lean MCP Stack That Agents Can Actually Use

For teams building agentic workflows, the hard part is not getting MCP to connect. It is deciding which servers deserve a place in the stack at all.

Every extra server, permission, and schema adds context load, increases the chance of tool misselection, and widens the blast radius if something goes wrong. The best MCP stacks are not the biggest ones; they are the ones that expose only the live systems the agent actually needs, and do it in a way the host can manage cleanly. ^{1, 2, 3}

Start with one workflow, not a tool catalog

The first curation mistake is to begin with connectors instead of a concrete outcome. If the workflow is weekly client reporting, support triage, calendar updates, or repository changes, start there. Then add only the systems needed to complete that task.

That matters because MCP servers are bridges to data and tools, not the product itself. The protocol’s own architecture is modular: hosts sit between the model and the servers, and servers expose resources, prompts, and tools in a standardized way. ^{4, 5}

A useful way to think about this is to ask: what state must change for the workflow to be done? Reading a dashboard is not the same thing as opening a ticket, writing to a database, or pushing code. The strongest servers are the ones that let the agent take a real next step, not just inspect more context. ⁴

Keep tool discovery lazy

The official MCP client guidance is blunt: loading every tool definition into context up front wastes tokens, increases latency, and degrades model performance. The preferred pattern is progressive discovery. Let the model search a catalog first, inspect the relevant tool definitions second, and only then execute. ¹

"Loading every tool definition into the model's context window upfront wastes tokens, increases latency, and degrades model performance."

— Model Context Protocol ¹

That is the right default for any stack that might grow beyond a handful of tools. A small stack can still become inefficient if every server is injected into context whether or not the agent needs it. Conversely, a larger estate can remain workable if the host filters well and only surfaces schemas on demand. ^{1, 2}

The practical tradeoff is simple: smaller static stacks reduce ambiguity, while smarter hosts reduce context waste. Most teams need both.

Prefer transport and deployment patterns that fit the job

If a server is local and spawned by the client, the MCP TypeScript SDK recommends stdio. If the server is remote, the SDK recommends Streamable HTTP, which is the modern transport and supports both stateless and stateful sessions. HTTP+SSE is deprecated and should not be the default for new work. ⁶

That transport choice is part of curation, not an afterthought. A local integration that only needs to live inside a developer workstation should not be designed like an internet-facing service. A remote integration that needs resumability, notifications, or shared access should not be forced into a brittle local-only pattern. ⁶

The same distinction applies to server design. Naive hosts that preload everything into context are expensive; hosts that support progressive discovery and programmatic tool calling are easier to scale. In the latter pattern, the host brokers the call, enforces policy, and keeps intermediate tool output from ballooning the conversation. ¹

Choose servers that change state, not just visibility

The highest-value MCP servers are usually the ones that let an agent do something consequential: create a calendar event, open a ticket, query a database, write to source control, or inspect observability data.

A concrete example is Aciflow, which uses MCP so Claude can view schedules and create events across connected calendars from one connection. That is useful because it changes the workflow’s state, not just its awareness. ⁷

"A standout integration lets Claude — an AI assistant developed by Anthropic — connect to the platform through the Model Context Protocol to view schedules and create events across all connected calendars from one single connection."

— 1 Minute Signal coverage of Marina Wyss - AI & Machine Learning ⁷

Enterprise architecture guidance points in the same direction. Cisco’s MCP-based setup decouples backend tools from the front end, so the tool layer can change without forcing UI rewrites. That is the kind of modularity that makes a stack easier to maintain over time. ⁸

But write access should still be earned, not assumed. If a server only needs to read data, keep it read-only. If it needs to draft actions, keep it draft-only until the workflow proves reliable. Only then move to write access. That staged approach is consistent with least privilege and with enterprise guidance to separate read and write authorization. ^{2, 3, 9}

Treat security as part of stack design

For MCP, security is not a policy appendix. It is part of the curation decision.

The official specification says users must explicitly consent to data access and operations, and that implementors are responsible for the real trust controls because the protocol itself does not enforce them. ¹⁰ AWS’s guidance reinforces the operational side: use scoped-down credentials, separate read/write authorization, per-user and per-tool rate limiting, and regression tests with golden datasets. ²

The strongest production rule set is therefore pretty plain:

• use scoped credentials instead of broad all-access tokens
• separate read and write tools
• validate authorization on every invocation
• rate-limit by agent identity and by tool type
• keep secrets short-lived and runtime-injected
• test the stack against known workflows before promotion ^{2, 9, 10, 11}

Two other details matter in practice. First, treat tool descriptions as untrusted unless they come from a trusted server. Second, do not co-load risky exfiltration tools, such as email or outbound HTTP, with untrusted-content readers in the same session unless you are deliberately accepting that risk. ^{3, 9}

That is less dramatic than a zero-trust slogan, but more useful. A lean stack is not just smaller; it is easier to reason about when something fails.

Pick the simplest transport that meets the deployment need

There is no prize for using the most elaborate transport.

For local integrations, stdio is often enough. For remote servers, Streamable HTTP is the preferred modern option. If your server is only being spawned by the host, choose the pattern that minimizes moving parts. If it needs to be shared, resumed, or monitored across environments, choose the one that supports that without custom plumbing. ⁶

This is where teams often overbuild. They start with a local proof of concept, then layer on network access, persistence, and auth later, even when the workflow never needed those features. That creates maintenance work without adding meaningful capability. ^{1, 6}

A good heuristic is: pick the transport that matches the actual operational shape of the workflow, not the shape of the demo.

Keep persistence, but put it in the right layer

Agent workflows that survive disconnects, sleep cycles, or long gaps need durable infrastructure. That does not mean every MCP server itself must be “persistent” in a philosophical sense. It means the surrounding execution environment should survive long enough for the work to finish.

In practice, that usually means remote infrastructure, stable sessions, and explicit logging. A 24/7 Codex setup running in a tmux session on a VPS is one example of how teams keep long-running work alive after SSH disconnects. ¹²

"Users can keep coding agents running indefinitely by running them inside a tmux session on a VPS, which allows the terminal to remain active after disconnecting via SSH."

— 1 Minute Signal coverage of Tech With Tim ¹²

The point is not that every agent should live on a VPS. The point is that if the workflow must keep going, persistence belongs in the execution layer, not in ad hoc prompt state. Durable execution, retries, logs, and recovery paths matter more than whether the stack feels “lightweight.” ¹³

Do not make the model carry what the host should own

Some stacks become inefficient because they ask the model to remember state that should live elsewhere.

MCP’s programmatic tool calling pattern is useful here: the host can broker calls, enforce policy, and keep intermediate results from bloating the conversation. That is a better fit than repeatedly re-sending the same tool outputs through chat. ¹

If you also need reusable procedures, keep them in a procedural layer rather than forcing MCP to do everything. MCP is for live, permissioned access to systems. Skills or runbooks are better for repeatable behavior that does not require full system integration. ^{14, 15}

That separation keeps the stack legible. The model should not be both the operator and the memory system for every repeated task.

Retire servers aggressively

Curation is not just selection. It is deletion.

If two servers overlap, consolidate them. If a server is only used once in a while, move it out of the core stack. If a server needs awkward permission exceptions, it is probably costing more in coordination than it is returning in capability.

That is especially true when a server becomes hard to secure or hard to test. In production guidance, the recurring themes are authorization granularity, logging, rate limiting, and regression testing. A server that forces you to abandon those controls is too expensive to keep by default. ^{3, 9, 11}

A simple test helps: if removing the server would not break a defined workflow, it probably does not belong in the core stack. If removing it would only make the agent slightly more convenient, it is probably bloat.

A lean stack usually beats a clever one

There is a temptation to treat more capability as a proxy for maturity. The evidence here points the other way.

Curated stacks tend to work better because they reduce tool-selection ambiguity, preserve context, and lower security risk. That is true whether the agent is doing coding, scheduling, support, or analytics. The strongest default is not “add more MCP servers,” but “add only the servers that expose live systems the workflow actually needs, and let the host discover them intelligently.” ^{1, 2}

That also helps explain why transport, permissions, and host behavior matter so much. A stack can be small and still clumsy if every tool is loaded eagerly. A stack can be modestly larger and still efficient if discovery is lazy and permissions are tightly staged. ^{1, 3, 6}

A practical curation checklist

If you are building or cleaning up an MCP stack, use this sequence:

1. Define one recurring artifact or workflow.
2. Add only the live systems required to complete it.
3. Keep read access separate from write access.
4. Use progressive discovery so tool schemas load lazily.
5. Choose stdio for local process-spawned servers and Streamable HTTP for remote ones.
6. Keep secrets scoped, short-lived, and runtime-injected.
7. Re-test permissions, logging, and rate limits before promotion.
8. Retire redundant servers instead of letting them linger. ^{1, 2, 6, 9, 11}

If that sounds less exciting than building a giant agent platform, that is the point. Efficient MCP stacks are boring by design. They are selective, permissioned, and discoverable. They make the agent’s job easier by making the system easier to reason about.

And that is usually the difference between an agent that demos well and one that can actually finish the job.