In Part #1, I argued that the UI is increasingly becoming the shell while MCP servers become the capability layer.
In Part #2, we looked at what production-ready MCP servers actually require: explicit tool contracts, structured inputs and outputs, error semantics, authentication, observability, and deployment discipline.
In Part #3, we separated model-controlled arguments from trusted runtime context such as user_id, tenant_id, roles, scopes, and project permissions.
In Part #4, we built the security boundary around the capability layer: dynamic tool filtering, policy registries, execution-time authorization, argument-level checks, audit trails, and governed discovery.
In Part #5, we answered the deployment question — where MCP servers actually run, how stateless MCP changes scaling, and how long-running work can move into durable Tasks and dedicated workers.
And in Part #6, we went one level further and looked at Code Mode, progressive tool discovery, sandboxed execution, and programmatic orchestration.
This part is about the next shift — and it’s not a new transport, another agent framework, or a reason to rewrite your stack. It’s that an MCP server is starting to look less like a thin endpoint exposing a few tools, and more like a real application platform for capabilities.
That distinction matters. Once you have dozens of tools, multiple MCP servers, several teams, different users, different permission levels, different clients, long-running workflows, reusable skills, versions, and a growing amount of context, the problem stops being “how do I expose a Python function as an MCP tool?” and becomes something much bigger:
How do I shape, discover, compose, govern, execute, observe, test, and evolve an entire capability surface without dumping the whole thing into the model?
That is where MCP is heading.
If this piece gives you something practical you can take into your own system:
👏 Leave 50 claps (yes, you can!) — Medium’s algorithm favors this, increasing visibility to others who then discover the article.
🔔 Follow me on Medium and LinkedIn for more deep dives into agentic systems, LLM architecture, and production-grade AI engineering.
The first generation of MCP examples was intentionally simple. You had a server:
MCP server ├── search_documents ├── create_ticket └── get_customer
The client listed the tools, the model saw the schemas, the model chose one, and the server executed it. That mental model is still correct for a small server — if you have five clear tools, one backend, one team, and one use case, you may not need anything more complicated.
But now imagine the same architecture inside a real enterprise environment:
Salesforce MCP 60 capabilitiesGitHub MCP 40 capabilitiesJira MCP 35 capabilitiesGoogle Drive MCP 25 capabilitiesKnowledge Base MCP 20 capabilitiesInternal Platform MCP 70 capabilitiesReporting MCP 15 capabilitiesAdmin MCP 30 capabilities
Suddenly you don’t have a “tool server” — you have a capability ecosystem. If you simply concatenate every schema and send all of it to the model, you create three problems at once: you waste context before the task even begins, you make tool selection harder, and you expose capabilities that may be irrelevant, unsafe, or confusing for the current user and workflow.
This is the same scaling pressure I discussed in Parts #4 and #6, but there’s a broader architectural consequence that’s easy to miss: the tool catalog itself becomes something you need to engineer. It can be searched, transformed, filtered, and namespaced. It can be assembled from other servers. It can contain reusable skills and resources. Its operations can for user input, its long-running work can move into Tasks, its contracts can be versioned — and the whole surface can be tested like any other production API.
That is the evolution I want to focus on in this article.
I’m going to reference FastMCP throughout this article because its current architecture makes many of these patterns unusually easy to see. Providers source components. Transforms change the component surface before it reaches a client. Search can replace a giant catalog with a tiny discovery interface. Proxies can combine other MCP servers. Skills can become resources. Long operations can become background Tasks. Versions can coexist. And you can test the resulting MCP surface through a real client rather than by calling implementation functions directly.
That’s genuinely useful, but I don’t think the lesson is “everyone should use FastMCP.” The lesson is that these are becoming reusable architectural patterns for MCP systems. You can implement the same ideas in Python, TypeScript, Go, C#, Java, Rust, or your own internal platform. You can use another MCP framework, build some of the pieces yourself, or use a managed gateway. What matters is noticing where the abstraction is moving: the MCP protocol standardizes communication between clients and capabilities, but your server architecture decides what the capability surface actually looks like — and that surface can now be much smarter than a static list of decorated functions.
One of the most useful ideas in this entire direction is also one of the simplest: a tool exposed by an upstream service may be technically correct and still be terrible for an LLM.
Imagine an internal Salesforce integration exposes this operation:
salesforce_account_query_v2_internal( q_string, include_deleted_flag, tenant_uuid, raw_fields,)
That may be perfectly acceptable inside the service that owns it, but should the model see that exact contract? Probably not. The model-facing capability might be better represented as:
find_customer_account( company_name, include_archived=False,)
The underlying operation didn’t change — the interface presented to the model did. That’s Tool Transformation.
FastMCP exposes this explicitly through its Tool Transformation layer. A tool can be renamed, its description rewritten, its arguments renamed, its defaults changed, unnecessary arguments hidden, tags and annotations adjusted, and custom logic added around execution. Conceptually, the flow looks like this:
Backend capability ↓Raw MCP tool ↓Transformation layer ↓Agent-facing contract
This matters for a few reasons.
The model doesn’t need infrastructure details. Parameters such as tenant_uuid, internal_region, api_version, or include_deleted_internal_records may belong to the backend but not to the model. If the model shouldn't control a value, there's usually no reason to put that value into its schema. That connects directly to Part #3: trusted runtime context belongs behind the capability boundary, not inside model-generated arguments.
The upstream naming scheme doesn’t have to leak into the agent. A third-party or legacy system may expose operations that were designed for developers, not for an LLM choosing between 80 tools. The gateway can create a cleaner vocabulary without forcing the upstream team to rename its API.
You can stabilize the agent contract while the backend changes. This is a bigger point than it first appears. Suppose the backend moves from Salesforce API v1 to v2, changes an internal parameter, or splits one operation into two — your model-facing tool doesn’t necessarily need to change with it. The transformation layer can become an anti-corruption layer between the capability consumer and the implementation underneath it. That’s normal software architecture; we’re simply starting to apply it to agent-facing interfaces.
The backend contract is optimized for the system that owns the capability. The MCP contract should be optimized for the agent that needs to use it.
This one is especially important once your MCP ecosystem grows. A common first implementation looks like this:
connect to server ↓list all tools ↓put every schema into the model context ↓ask model to choose
That works when the list is small, but it becomes increasingly wasteful as it grows. The more mature pattern looks like this instead:
small discovery interface ↓search relevant capabilities ↓load only matching schemas ↓execute
FastMCP’s Tool Search implementation makes the idea very concrete. Instead of returning the whole tool catalog, the server can expose synthetic discovery tools such as search_tools and call_tool. Its built-in search strategies currently include regex matching and BM25 ranking. BM25 isn't semantic vector search — it's lexical ranking — but the larger architecture isn't tied to BM25 at all. Your own platform could use keyword search, embeddings, hybrid retrieval, reranking, metadata filters, usage statistics, policy-aware ranking, or a domain-specific capability index.
The important idea is that tools become retrievable objects. Instead of putting 300 tool definitions into the context, the model might receive a call like search_tools("find customer opportunities and open deals") and get back exactly three or four matches — salesforce_find_account, salesforce_list_opportunities, salesforce_get_pipeline_summary. Only those schemas need to enter the next step.
This isn’t only a token optimization — it improves the shape of the decision the model has to make. Compare “choose one capability from 300 schemas” with “search for capabilities related to this task, then choose between the 4 relevant results.” Those are very different reasoning problems.
I already covered progressive discovery in Part #6 because it’s one of the foundations of Code Mode, but Tool Search is useful even if you never execute model-generated code — you can use it with completely normal tool calling. And there’s one security rule that should carry over from Part #4: search the catalog the user is allowed to discover, not the platform’s complete catalog. A search layer that reveals the names and schemas of forbidden admin tools is still leaking capability information even if execution is blocked later. So the real pipeline should look more like:
This is context engineering at the capability level.
Once you start combining MCP servers, a very boring problem appears immediately: everyone has a tool called search, or get_user, or list_files, or create_note. Suppose you combine Salesforce MCP, Google Drive MCP, Knowledge Base MCP, and GitHub MCP, and three of them expose search. Which search is the model calling? Which one shows up in logs? Which one is covered by a policy rule? Which one changed when a schema fingerprint moved?
This is why namespaces become important as soon as MCP stops being one isolated server. FastMCP provides a Namespace transform that prefixes components when servers are composed — so search becomes salesforce_search, gdrive_search, knowledge_base_search, github_search. Resources can be namespaced in their URI path as well.
The simple benefit is avoiding collisions. The more interesting benefit is provenance — a namespace tells you where the capability came from, which is useful for policy rules, audit logs, tracing, rate limits, ownership, version migrations, debugging, and model-facing descriptions.
I wouldn’t overdo it, though. A name like enterprise_internal_platform_team_alpha_salesforce_v2_search_customer isn't better simply because it's globally unique. Namespace establishes identity; Tool Transformation can still make the final interface pleasant for the model. Those are related problems, but not the same problem:
Source identity → NamespaceAgent usability → Transformation
When people hear “context engineering,” they usually think about system prompts, retrieved documents, memory, conversation history, and maybe tool descriptions. But the set of capabilities visible to the model is also context.
If the current workflow is customer research, why should the model see rotate_api_key, terminate_employee, rebuild_search_index, publish_release, or admin_delete_tenant — even if the current user technically has access to some of them? Those capabilities are irrelevant to the task. A cleaner surface might be:
Customer Research ├── salesforce_find_account ├── salesforce_list_opportunities ├── knowledge_search ├── web_research └── generate_customer_report
That’s where runtime visibility becomes useful. FastMCP’s Component Visibility can dynamically enable or disable components by name, key, or tag. Disabled components disappear from listings and can’t be resolved through the normal server surface. You can use the same general pattern for workflow-specific capability sets, feature flags, environment differences, beta tools, temporary maintenance, tenant-specific products, different agent profiles, or simply reducing the model’s action space:
workflow = customer_researchinclude: salesforce.* knowledge_base.* reports.*exclude: admin.* deployment.* hr.*
The important distinction from Part #4 still stands: visibility is not a replacement for authorization. Visibility answers “should this capability be part of the current surface?” Authorization answers “is this authenticated principal actually allowed to use it?” A good enterprise MCP platform normally wants both — first reduce the surface, then enforce authority.
This is where the architecture starts to become genuinely interesting. An MCP server doesn’t have to own every capability it exposes — it can sit in front of other MCP servers. FastMCP’s MCP Proxy Provider can source Tools, Resources, and Prompts from another MCP server and expose them through the current server.
That means a simple chain like this:
AI client ↓Salesforce MCP
can become something like this:
The gateway doesn’t need to copy the business logic from those servers — it can proxy the capabilities and add a platform layer around them:
This is a big architectural shift. MCP servers stop being isolated islands and can form a network instead. One team can own Salesforce integration, another can own project knowledge, another can own infrastructure operations — and the enterprise gateway can compose those capabilities into a single product surface without forcing every team into one repository or one release cycle.
The proxy is also useful for less glamorous reasons: bridging transports, putting a stable endpoint in front of changing upstream servers, centralizing authentication, adding observability, applying consistent policies, normalizing naming, and hiding internal topology from clients.
None of this means every company needs one giant central MCP gateway — you can have multiple gateways for different domains (an engineering capability gateway, a sales capability gateway, a research capability gateway, a platform operations gateway). The point is that MCP gives you the protocol boundary required to compose them cleanly.
Once MCP servers can consume and reshape other MCP servers, the natural unit of architecture stops being “one server.” It becomes a graph of governed capabilities.
Tools answer “what can the system do?” Resources answer “what information can the client retrieve?” Skills introduce another useful idea: “how should an agent perform a particular kind of task?”
An agent skill is typically a directory containing instructions plus supporting files — examples, schemas, scripts, checklists, reference material, or domain-specific guidance. Historically those skills often lived inside one specific client environment (~/.claude/skills/, ~/.cursor/skills/, ~/.gemini/skills/, and so on). FastMCP's Skills Provider exposes skill directories as MCP Resources instead, so a skill becomes addressable through resources such as skill://customer-research/SKILL.md, skill://customer-research/_manifest, skill://customer-research/examples.md, or skill://customer-research/schema.json.
This is more important than it looks — it means the MCP server can distribute procedural knowledge alongside executable capabilities. Imagine an internal customer-research platform where the MCP surface provides tools like search_salesforce, search_knowledge_base, and generate_report, alongside resources/skills that capture how the team defines a qualified opportunity, the customer research methodology, the expected report structure, evidence requirements, and examples of strong reports.
The tool tells the agent what it can execute. The skill tells it how your organization expects the work to be done. That separation is useful: you don’t need to bake every operating procedure into one enormous system prompt, and you don’t have to copy the same skill manually into every AI client. If the client understands MCP Resources, it can discover and retrieve the skill through the same protocol surface; if a client only understands Tools, an adaptation layer can expose Resources through tool calls instead.
An MCP server can package capability, context, and operational knowledge as one reusable product boundary.
The simplest tool interaction is one-directional: the model calls a tool, the tool returns a result. Real workflows are often messier. Suppose the user says “create a new cloud environment for the analytics project,” and the tool discovers there are three valid regions and two deployment profiles. Or it calculates the requested environment will cost roughly $420 per month. Or it finds two Salesforce accounts with almost identical names. The correct next step isn’t always to guess — sometimes the capability should ask.
That’s the idea behind MCP Elicitation. FastMCP exposes a convenient Elicitation API for requesting structured input from the user, but the pattern itself belongs to MCP rather than to one Python framework. Conceptually:
In the 2026-07-28 MCP specification, this interaction was redesigned around Multi Round-Trip Requests (MRTR) so it works with the new stateless protocol model instead of depending on a permanently open bidirectional session. The wire-level mechanism changed; the product capability didn't — a server operation can still require user input in the middle of a workflow. That's valuable for choosing between ambiguous entities, collecting missing parameters, confirming expensive operations, reviewing generated content before publishing, selecting a target environment, or gathering structured information progressively.
But there’s an important security boundary here: an elicitation prompt is not authorization. If deleting data requires approval, the backend should record and enforce the approval state — don’t rely on a natural-language “are you sure?” prompt and assume the security problem is solved. Human-in-the-loop must become a real state transition when the operation is sensitive.
Logging is another area where it’s worth separating two ideas. There’s client-facing execution information — “Searching Salesforce… Found 18 matching opportunities… Generating report… Report created.” And there’s production observability — trace IDs, request IDs, principal and tenant IDs, tool name, provider, latency, retry count, policy decision, task ID, error code. Those are not the same thing.
FastMCP still documents client logging, where a server can send debug, info, warning, or error messages back to a supporting MCP client. That can be helpful for development and for giving a client visibility into what a capability is doing. But there’s an important 2026 protocol update here: **protocol Logging was deprecated in MCP **2026-07-28 for new implementations. So I wouldn't design a new production observability architecture around MCP logging messages — use normal application observability instead (structured application logs, OpenTelemetry traces, metrics, Datadog, Grafana/Tempo, CloudWatch, ELK, or whatever your organization already operates).
The useful mental model: client-facing status helps the user or host understand execution, while server-side telemetry helps engineering, security, and operations understand the system. For enterprise MCP, the second category is non-negotiable. When one user request flows through an AI host, an MCP gateway, a proxied MCP server, an external SaaS API, and a background worker, you want one trace that explains the entire path. The fact that MCP is becoming easier to proxy and compose makes distributed observability more important, not less.
I already touched Tasks in Parts #5 and #6, so I won’t repeat the whole protocol lifecycle here — but it’s worth focusing on what Tasks mean for the evolution of MCP servers.
A traditional tool call looks like: request → execute → result. That assumes the operation fits naturally inside one request. But many useful enterprise capabilities don’t — generating a 60-page customer report, indexing 20,000 documents, analyzing a large repository, exporting all Salesforce opportunities, building a presentation with supporting artifacts, running a compliance scan, processing a large batch of records. Those operations may take minutes, need retries, survive a client disconnect, need to report progress, or run on a different worker from the MCP endpoint itself.
The MCP Tasks extension gives long-running execution a protocol-native lifecycle. FastMCP’s Background Tasks implementation makes this easy to see: a component can be marked as task-capable, the client receives a task handle, and execution moves into a background worker backed by a task system rather than holding the original tool call open:
This is different from just writing asyncio.create_task(...) — Python concurrency keeps work in your process, while a protocol-level Task creates a contract between the server and the client for long-running execution. That means the capability has a lifecycle the client can understand. It's another sign that MCP servers are becoming full application surfaces rather than RPC wrappers: the server is no longer responsible only for "call function, return JSON" — it may also be responsible for starting work, persisting state, exposing progress, handling cancellation, recovering, and returning the result later.
There’s a stage every successful internal platform eventually reaches: someone changes a schema and breaks a consumer they didn’t know existed. MCP isn’t magically immune to this.
Suppose version 1 of a capability looks like calculate_risk(project_id), and version 2 becomes calculate_risk(project_id, methodology="v2", include_history=True). If every agent and every client immediately receives the new contract, you've effectively shipped a breaking API change.
FastMCP’s Component Versioning allows multiple implementations of the same Tool, Resource, or Prompt to coexist under one logical identifier. The highest version can be exposed by default, while version filters can create different surfaces for different clients or migration windows.
The larger architecture matters more than the specific API. Once MCP becomes shared infrastructure, you need to think about capability evolution the same way you think about any public service contract: which change is breaking, which clients still depend on v1, can v1 and v2 coexist, how long is the migration window, which version is approved for production, which version is visible to which agent, and when can the old implementation be removed. A useful enterprise registry may eventually track something like tool name, provider, version, schema fingerprint, owner, risk class, approved-at/by, and deprecated-at.
That may sound like overkill for a five-tool server. It isn’t overkill for a capability platform used by 20 teams.
Once another system depends on your MCP schema, that schema is an API whether you call it one or not.
This is the least glamorous item on the list and probably one of the most important. Suppose this function works perfectly:
async def find_customer(company_name: str): ...
That doesn’t prove your MCP server works correctly. The problem could be anywhere around it — a wrong generated schema, a misleading description, a transform that hid the wrong argument, a namespace that changed the name unexpectedly, visibility that exposed an admin capability, authorization filtering the wrong user, a proxy that fails to forward credentials, Tool Search that can’t discover the tool, version filtering that exposes v1 instead of v2, malformed structured output, or a background task that never reaches a terminal state.
That’s why I like testing the actual MCP surface. FastMCP’s testing guidance uses a real FastMCP Client against the server in-process, which lets you test protocol behavior without deploying a separate service. Instead of testing only the implementation:
result = await find_customer("Acme")assert result
also test what the MCP consumer actually sees:
async with Client(mcp) as client: tools = await client.list_tools() assert "salesforce_find_customer" in { tool.name for tool in tools } result = await client.call_tool( "salesforce_find_customer", {"company_name": "Acme"}, )
For a production capability platform, I’d test at least four layers:
Contract tests — does the tool expose the expected name, description, input schema, output schema, annotations, and version?
Discovery tests — for a given user and workflow, which tools are visible and which are hidden? Can Tool Search find the correct capability, and can it accidentally discover forbidden ones?
Execution tests — does the tool call succeed? Are errors structured correctly, are retries safe, do proxies propagate the right identity, does authorization run again at execution time?
Lifecycle tests — can background Tasks complete or fail cleanly, can they be cancelled, does version migration preserve old clients, and what happens when an upstream MCP server is unavailable?
This isn’t “testing the framework” — it’s testing your product contract. Once MCP becomes the capability layer used by multiple clients and agents, that contract deserves the same discipline as your REST, gRPC, or event-driven interfaces.
If we put all of these ideas into one architecture, the flow can look like this:
Look at that architecture for a second — that’s no longer “a server with some tools.” It’s a product surface. It has discovery, routing, interface adaptation, context control, policy, interactive workflows, asynchronous execution, reusable operational knowledge, compatibility management, and an engineering lifecycle. And none of that requires the model provider to own the business logic — the same capability platform can sit behind any MCP-compatible host that your organization decides to use. That’s the part I find strategically important.
A lot of AI performance discussions focus on the model: which model, how many parameters, how large the context window, how good the reasoning. Those things matter, but in production systems, architecture around the model can remove an enormous amount of unnecessary work.
Suppose the platform has 300 tools. A naive architecture puts all 300 schemas into the LLM context and lets the model try to select one. A more deliberate architecture narrows things down first: 300 capabilities, filtered by policy to 85 allowed, filtered by workflow visibility to 24 relevant, narrowed by search to 4 candidates, and only then are those 4 schemas loaded for the model to choose from.
The model didn’t get smarter — the system did. That’s one of the reasons these patterns matter so much to me in production. You can reduce context, improve selection accuracy, reduce irrelevant actions, make authorization clearer, keep backend contracts out of the model, and compose independent teams without merging all their code — all before asking the LLM to reason about the next action.
A good agent architecture does not only optimize the model’s reasoning. It optimizes what the model is asked to reason about.
This is where I think the evolution gets especially interesting for enterprise systems. The original unit looked like:
AI client ↓MCP server ↓API
The next unit looks more like:
Each MCP server can remain focused, each team can own its domain, and each service can have its own release cycle. The gateway assembles the right surface for the right user, a model can discover only what it needs, a long workflow can move into a Task, and a skill can teach the agent how the company expects the workflow to be performed — while the entire thing remains consumable through the MCP boundary.
This starts to look much closer to a distributed application platform than to a collection of function wrappers, which is why I think calling MCP servers “just tools for LLMs” increasingly understates what they’re becoming.
There’s an obvious danger in everything I just described. You can read an article like this and decide your five-tool internal server now needs three gateways, a capability registry, vector search over tool schemas, five namespaces, dynamic version negotiation, a distributed task queue, a skills marketplace, and twelve layers of transforms.
Please don’t do that.
If your server exposes six stable tools and every user should see all six, send all six tools. If your backend schema is already clean, don’t add transformation simply because a framework supports it. If you have one server, you don’t need a proxy topology. If an operation finishes in two seconds, you probably don’t need a Task. If nobody consumes v1 anymore, you may not need two versions running forever.
Architecture should appear in response to a problem, not the other way around. The point of these capabilities isn’t to maximize the number of framework features in your repository — it’s that when the problem does appear, MCP no longer forces you back into building a completely custom AI platform around it. The ecosystem is giving us reusable building blocks for the same problems that show up in any mature application platform. That’s progress.
FastMCP deserves credit here because it’s made a lot of these ideas extremely visible in one place. Its documentation lets you look at concepts like providers, transforms, tool search, namespaces, visibility, proxies, skills, elicitation, tasks, versioning, and testing, and immediately see how they fit into an MCP server. That’s genuinely useful, and I use several of these patterns in production because they solve real problems — reducing tool context, separating model-facing contracts from backend contracts, controlling capability exposure, composing integrations, and making the resulting surface easier to operate.
But I’d still encourage teams to copy the idea, not the library API. Ask yourself: do we need on-demand tool discovery? Do we need a model-facing transformation layer? Do we need a capability gateway? Do we need workflow-specific visibility? Do we want to distribute skills through MCP resources? Do long operations need a durable lifecycle? Do our capability contracts need versions? Are we testing what the client actually sees? Then implement the answer in the stack that makes sense for your organization.
The protocol gives us interoperability. The framework gives us convenience. The architecture is still ours.
The biggest change in MCP isn’t that servers have accumulated more features — it’s what we’re starting to expect an MCP server to be responsible for. At the beginning, the mental model was simple: expose a tool, let the model call it, return the result. The emerging model is closer to sourcing capabilities from multiple systems, normalizing their contracts, namespacing their identities, filtering what’s relevant, authorizing what’s allowed, searching large catalogs on demand, distributing reusable skills and context, asking the user when a decision is required, moving long-running work into durable execution, observing the full path, versioning the contracts, and testing the surface as a real product.
That’s a very different thing. MCP is still intentionally a protocol, not an application framework, but the ecosystem around it is turning MCP servers into a serious application boundary where we can build the same kinds of routing, governance, lifecycle, compatibility, and composition layers that we already expect from mature backend systems.
That’s exactly why I remain so interested in the architecture. A good MCP server is no longer only a way to give an LLM another function — it can become a reusable capability product that works across agents, models, teams, and client applications. One server can stay small. A network of servers can become an enterprise platform. The model remains flexible, the capability layer remains governed, and the client on top can change without forcing you to rebuild the business capability underneath it.
That is the shift worth paying attention to.
And that’s a wrap! If you’ve read this far, it probably means you found this article useful or insightful. If that’s the case, consider leaving a few claps or sharing it with your team, please. Thanks for reading! 🚀
Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7 was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.