Build your own MCP server in 30 minutes with FastMCP (full tutorial)

The MCP Ecosystem Is Splitting Into Two Distinct Layers

Model Context Protocol is no longer an experimental curiosity. In a single week, the tooling landscape produced a fast-iteration framework, a cost-optimization gateway, and a Java implementation targeting enterprise teams. That is not coincidence. That is an ecosystem maturing along predictable fault lines.

The split is architectural. On one side: frameworks that let you ship tool-bearing servers fast. On the other: infrastructure that controls how those tools get exposed to models at runtime. Both layers matter. Neither is optional if you are running agents at scale.

FastMCP 3.2 Ships Real Tools, Not Demos

FastMCP 3.2 is a Python framework that handles stdio and HTTP transport, tool registration, and Pydantic-validated schema generation with minimal boilerplate. The practical proof point is credible: one team shipped FinanceKit (17 tools) and SiteAudit (11 tools) in two weeks. That is a real productivity signal, not a benchmark constructed to impress.

The framework uses uv for package management, which matters more than it sounds. uv resolves dependencies significantly faster than pip and is becoming the default for Python tooling that takes reproducibility seriously. If you are building MCP servers and still using bare pip, you are accumulating technical debt on your local-remote parity.

Schema Drift Kills More Projects Than Complexity

The genuine value of FastMCP is not the speed of initial setup. It is that automatic tool registration and schema generation eliminate the category of bugs that come from schema drift: where your Python function signature and your JSON schema description silently diverge. Pydantic catches that at definition time, not at 2am when the model passes a malformed argument to a live API.

The limitation nobody is saying: FastMCP is a developer-experience layer. It does not solve the runtime problem of what happens when your 17-tool FinanceKit server gets connected to an agent that also has a 23-tool analytics server and a 9-tool notification server. That is where the second layer becomes critical.

The Token Cost Problem Is Structural, Not Incidental

Classic MCP has a design behavior that becomes an economic liability at scale: every request injects all tool definitions from all connected servers into the model's context. If you have three servers with a combined 49 tools, every single call pays the token cost of describing all 49 tools, regardless of which one will actually be used.

Bifrost's MCP Gateway targets this specific failure mode. The claim is a 92% reduction in token costs through selective tool injection: only the definitions required for a given request enter the context. Bifrost is written in Go, open-source under Apache 2.0, and they claim 11 microseconds of overhead at 5,000 requests per second.

Token Bloat Kills Performance Before Requests Begin

That 11 microsecond number needs scrutiny. Faster than what? LiteLLM is the explicit comparison, and Bifrost claims Python-based alternatives add hundreds of milliseconds of overhead. That directional claim is plausible: Go's goroutine model handles high-concurrency routing at lower latency than a Python async event loop under real load. But "hundreds of milliseconds" is imprecise, and the 5,000 RPS benchmark needs a hardware spec and a concurrency profile before it means anything defensible.

The 92% token cost reduction is the number worth pressure-testing. If your agent system has intelligent tool routing (meaning the gateway actually knows which tools are relevant to which query types before calling the model), 92% is achievable. If the routing itself requires an LLM call to decide which tools to inject, you are trading token cost for latency and potentially adding a new failure mode. The architecture of Bifrost's routing logic is the thing to audit before adopting it.

What Bifrost does establish clearly: access control, cost governance, and audit trails as first-class features of an LLM gateway. That is the right place for those features. Putting auth and audit logic inside your MCP server implementations creates fragmentation. Centralizing it in the gateway layer is operationally correct.

The token cost of MCP is not a model problem. It is a protocol design problem, and fixing it in the gateway layer is the only solution that scales across heterogeneous tool servers.

Java, Water Systems, and the Breadth of Agentic Deployment

MCP Is Not a Python-Only Story Anymore

The LangChain4j plus Micronaut implementation of MCP-connected agents is worth flagging for what it signals, not for its technical novelty. Building a task-management agent in Java with structured JSON tool calls and the explicit constraint that the model never directly modifies business data: this is the pattern enterprise teams need. The model decides what should happen. The system controls how it happens. That separation is not just good design; it is the minimum bar for any agent touching production data.

Java teams that have been watching the MCP ecosystem wait for Python-first tooling to stabilize now have a working reference architecture. LangChain4j is not LangChain. It is a separate project targeting JVM environments, and it is mature enough to build on.

LLMs as Context Parsers in Physical Infrastructure

WaterAdmin, a paper from ArXiv, describes a bi-level framework for community water distribution optimization. The upper level uses LLMs to parse community context (human activity patterns, weather variations, demand signals that are hard to formalize). The lower level applies deterministic optimization to produce real-time control actions.

This architecture is the correct way to use LLMs in high-stakes physical systems. The model is not making control decisions. It is abstracting messy, heterogeneous context into a structured representation that feeds a reliable optimization layer. The LLM is the context parser, not the controller. Implemented on EPANET, the hydraulic simulation standard, the results show improved pressure reliability and reduced energy consumption versus traditional optimization that lacks adaptive context.

LLMs Belong Above the Loop, Not In It

This bi-level pattern (LLM for context, optimizer for action) should be the default template for any agentic system where the output affects physical or financial state.

Identity, Memory, and the Long-Horizon Agent Problem

The soul.py architecture paper addresses something most production agent work ignores: what happens to agent behavior when memory is partial, corrupted, or reset. The multi-anchor identity approach distributes agent identity across episodic memory, procedural memory, emotional continuity, and embodied knowledge. A hybrid RAG plus reinforcement learning retrieval system routes queries to the appropriate memory layer.

The concept of identity anchors (components of agent state that can survive partial memory failure) is the right framing for a real production problem. Agents that lose context mid-task do not fail cleanly. They produce subtly wrong outputs that are harder to detect than hard failures.

Memory Architecture Makes Or Breaks Long-Running Agents

The practical implication: if you are building agents that operate across sessions or handle multi-day tasks, you need explicit memory architecture, not just conversation history appended to a context window. soul.py is research-stage and the claims about catastrophic forgetting reduction are not independently benchmarked. But the architectural vocabulary it introduces is worth absorbing now.

Sources: Dev.to: AI tag (April 14, 2026), DEV.to (April 14, 2026), ArXiv CS.LG (April 14, 2026), ArXiv CS.AI (April 14, 2026), Hacker News: AI Agent (April 13, 2026)