The configuration you built during your first sprint with MCP probably worked. The tool count was manageable, the transport matched the environment you were deploying into, and the agents behaved well enough that nobody scheduled a follow-up review. That was the right call at the time, because the right call at the time is usually to ship and learn. The problem is that MCP has kept moving while your server has not, and the gap between what the protocol now expects and what your server currently provides is quietly growing into the kind of debt that only surfaces when something breaks in production.

This is part two of the AI Design Series. Part one covered what MCP is, how configurations typically look, and the basic trade-offs between self-built and vendor-provided servers. This part takes the next step: given what you have running today, what should you check, what signals tell you something needs adjustment, and what does governance actually require now that the protocol has matured enough to offer an answer?

Tool Inventory: Count Is the Wrong Score

The most common shape of an early MCP server is a one-to-one mapping between API endpoints and exposed tools. It is the obvious first move, because it gives the agent access to the full surface area of your system without any design decisions. As the Neon engineering account describes it, that approach works, but it creates two problems that compound as the API grows: the tool list loads into the context window before the session starts, bloating it before the agent has done anything useful, and when several tools do similar things, the agent picks the wrong one with enough regularity to matter.

The layered approach that emerged as a response, where the server exposes a search tool, an inspect tool, and an execute tool rather than hundreds of individual operations, has itself been partially absorbed by the client side. Progressive tool discovery and programmatic tool calling are now recommended client-side practices for agents like Codex and Claude Code, which means the server-side layering pattern your team implemented may be doing work the client is already handling, redundantly and with added complexity you now maintain for diminishing return.

What this does not mean is that you should revert to one-to-one endpoint mapping. The relevant question is whether your server exposes ergonomic composite operations, the equivalent of SDK helper methods, for the workflows your agents run most often. If creating a record in your system requires three sequential API calls to be useful, and your agents are reconstructing that chain from scratch on every session, you are spending tokens teaching the agent something it could have been handed. The composite tool is not a workaround; it is the same logic that makes SDKs worth using at all.

Run the inventory: list every tool your server exposes, identify which ones are being called in practice and which are sitting unused, and ask whether the ones that get called in combination could be expressed as a single composite operation that saves the reconstruction cost every time.

The Primitives You Are Probably Ignoring

Tool count gets the attention. Prompts and resources get almost none, and API Evangelist Kin Lane's assessment is that this has things backwards: the genuinely underrated parts of the protocol are the two primitives almost nobody is using well.

MCP prompts are curated, parameterized queries written by whoever knows the system best and handed to the consumer ready to run. The practical way to think about them is as the fifteen questions worth asking, phrased correctly, rather than the two hundred operations that technically allow you to ask them. For a team onboarding to a new MCP server, that difference is the gap between productive first sessions and a week of trial and error. For an agent working against your project data, it is the difference between a tool that routes reliably and one that approximates the right call most of the time.

Resources solve a different problem in a similar way. The reference material, schema documentation, and context an agent needs to use a capability well has historically lived somewhere else: a separate docs portal, a wiki page that drifted out of sync two quarters ago, a PDF in a shared drive that nobody updates. MCP's move is to make that context a first-class part of the interface itself, sitting alongside the capability rather than requiring a separate trip to find it. When an agent reaches for a tool and the relevant reference material comes along automatically, it is working with a more complete picture of what it is doing.

If your server exposes tools and nothing else, you are leaving the clearest governance and usability levers in the protocol unused. Prompts give you a way to shape how the server gets queried without controlling the agent's behavior directly, and resources give you a place to put the context that would otherwise drift into stale documentation. Both are worth adding to whatever review cycle you run on the server.

Transport and State: The Largest Shift You May Have Missed

If your server is still running on stdio or SSE, it is worth understanding exactly what that costs and what the move to stateless HTTP now requires you to own explicitly. A Microsoft VS Code team member's account of MCP's evolution describes the shift to stateless HTTP as the largest architectural change the protocol has made, because it fundamentally changes how the server is deployed and how it handles anything that used to depend on a persistent connection.

SSE-based servers required long-running connections that stayed open with each client, which made deployment complicated and scaling across multiple instances practically difficult. Stateless HTTP removes that constraint and allows servers to be deployed and routed the way any other service is deployed, which is a meaningful gain in operational flexibility. The cost is explicit: session management and shared storage now belong to you, because the protocol no longer assumes a persistent connection that carries that state automatically. Authentication, which was partly handled by the connection model, also needs to be managed deliberately in the stateless version.

This is not a reason to avoid the migration, but it is a reason to go into it with a clear list of what your current server is relying on the transport layer to handle. If agents are using your server across multiple sessions and any state persists between calls, you need to know where that state lives now and where it will live after the move. If authentication is currently handled by the connection context, you need a plan for what replaces it. These are solvable problems, but they do not solve themselves during a transport migration.

Governance: The Elicitation Gap

The governance question for most self-built MCP servers has been handled informally, meaning someone decided which tools to expose and trusted the agent not to call the wrong one at the wrong moment. That worked as a practical matter when the tools were read-only or the stakes were low. It becomes a different conversation when the server can write project data, trigger change order workflows, delete records, or modify configuration that affects anything downstream.

Elicitations are the protocol-level answer to this, and they are relevant enough to operational contexts to be worth examining closely. As the VS Code team demo shows, elicitations allow an MCP server to pause execution before completing a tool call and present a confirmation prompt directly to the user, so that a destructive or configuration-changing operation requires explicit human acknowledgment before it proceeds. The agent does not decide on its own that the action is authorized; the server asks, and the user confirms. Critically, elicitations are designed to work with the stateless HTTP transport: the confirmation comes back asynchronously through whatever instance handles the response, so you are not held to a persistent connection to make the interaction work.

If your server has any tool that writes, deletes, or reconfigures something consequential, and it does not have an elicitation in place, you have a governance gap that the protocol now has a direct answer for. The implementation is more involved than adding a tool description, but the alternative is trusting that agents will call destructive tools only when appropriate, which is a trust that most practitioners who have run agents in production for more than a few months no longer fully extend.

Self-Built Versus Vendor-Provided: Different Drift, Different Fix

The review process looks different depending on who owns the server. Self-built MCPs drift because nobody put a recurring review on the calendar, tool descriptions go stale as the underlying system changes, and the composite operations that made sense for early use cases are no longer matched to how agents are actually calling the server. The optimization surface, as the VS Code account describes it, is almost always the tool descriptions and call constraints rather than the underlying code. When agent behavior goes wrong on a self-built server, the first thing to examine is whether the description of the relevant tool still accurately reflects what the tool does and when to call it, before touching anything in the implementation.

Vendor-provided MCPs have a different failure mode. They version on the vendor's schedule, and tool descriptions can change between releases without the change appearing anywhere prominent in the release notes. A tool that routed correctly six months ago may have been renamed, split into two operations, or quietly given a more restrictive scope in a recent update, and the agent behavior that breaks as a result looks like a model problem rather than a configuration problem. The remediation here is not a code change at all; it is understanding what changed in the vendor's release and whether the agent's current tool-calling behavior still matches the updated descriptions.

Both scenarios require a recurring check, but the check looks different. For self-built servers, the question is whether the tool descriptions and composite operations still match how the system is being used. For vendor-provided servers, the question is what changed in the last release and whether agent behavior has shifted in ways that correlate with those changes.

What to Ask Before the Next Review Cycle

Wherever your server sits today, a diagnostic pass against a short set of concrete questions will surface most of what needs attention. Ask these directly against whatever you have running.

How many tools does your server expose, and when did you last verify that each one is actually being called? Tools that sit unused are context-window overhead with no return, and the composite operations that would save tokens are often missing precisely because nobody audited the call patterns.

Does your server expose any prompts or resources, and if not, what context are agents missing that is currently living in a separate document somewhere? If the answer is a shared drive folder or a wiki page, that context belongs in a resource.

Is your server still on stdio or SSE, and if so, do you have a clear account of what session state and authentication are relying on the current transport to handle? That account needs to exist before the migration, not during it.

Which tools in your server write, delete, or modify anything consequential, and do any of them have elicitations in place? If the answer is none and the tools are not purely read-only, that is the governance gap to close first.

If your server is vendor-provided, what changed in the last two releases, and has agent behavior shifted in ways that correlate with those changes rather than with anything in your prompts or system configuration? That question is worth putting to the vendor directly, because the honest answer about which tool descriptions changed is usually available even when it is not in the release notes.