MCP standardized tools. Now we need the infrastructure around them.

extract

MCP adoption happened extremely fast. Developers can now connect models to repositories, databases, browsers, observability systems, internal APIs, and dozens of other tools through a shared protocol. Claude Code, Cursor, Codex, VS Code, and a growing list of other clients all speak it. Vendor-hosted endpoints exist for GitHub, Linear, Notion, and many others. The Tier 1 SDKs are approaching half a billion downloads a month. That is a real achievement. For years every AI application built its own tool-calling layer. MCP gave the ecosystem a common interface. Once a server exists, multiple agents can use it without custom glue. That alone is worth the effort. But after building around MCP for coding agents, I started noticing something else. The protocol was becoming standardized faster than the infrastructure around it. Connecting a tool was becoming easy. Running that system reliably across real users, real credentials, and real work was not. The protocol solved a specific problem: how can an AI model talk to tools through a common interface? The next set of problems is different. How do we make thousands of those interactions reliable, secure, efficient, observable, and straightforward to deploy? The demo-to-production gap The happy path looks simple. An agent talks to an MCP client, which talks to an MCP server, which calls a tool that talks to an API or database. In a demo, that is often all you need. In production, the picture changes. You have multiple agents, multiple users, many MCP servers, credentials that must not leak, rate limits, permissions that differ by person or by task, failures, retries, logs, tool schemas that change, context constraints, and machines that are not identical. The mental model becomes something closer to agents and clients sitting in front of authentication, routing or gateways, then a set of MCP servers, then the actual systems those servers touch. Every one of those layers can fail independently. A concrete example: an agent that reads documentation and fails once is annoying. An agent that creates cloud resources, writes database records, or opens pull requests and fails halfway through is a different problem. Partial work, inconsistent state, and the need for idempotency or compensation become real requirements. The protocol does not magically supply them. Everyone is rebuilding the same plumbing One pattern I kept seeing is infrastructure duplication. Developers and teams repeatedly build authentication, deployment, connection management, retries, logging, secret handling, health checks, access control, simple registries, caching, and rate limiting. The same pieces appear in different codebases because the protocol standardizes the message format, not the operational concerns around it. This is not unique to MCP. Earlier infrastructure transitions followed a similar shape. Once physical servers became painful enough, cloud abstractions matured. Once every application reinvented authentication, identity platforms matured. MCP may be entering a stage where managing dozens of individual local servers, each with its own configuration and credentials, starts to feel like the old way of doing things. Whether the eventual abstractions live in agent runtimes, cloud platforms, gateways, or somewhere else is still open. The duplication is already visible. Local MCP was the right starting point Local servers over stdio are easy to understand, close to the user, and naturally connected to local files and processes. They were the perfect way to experiment. Local execution also avoids many of the authentication and multi-tenant problems that appear once the server moves onto the network. Team-scale usage exposes the limits. Everyone needs installation and configuration. Versions drift. Credentials live on different machines. One developer’s server can break differently from another’s. Onboarding becomes repetitive. Observability is fragmented because each machine is its own island. Remote or hosted servers address some of those problems, but they introduce others: authentication that actually works across clients, latency, multi-tenancy, data handling, uptime, permissions, and questions of vendor dependence. Neither model is automatically superior. They solve different sets of constraints. The July 2026 specification changes helped the remote case. Removing protocol-level sessions and the initialize handshake means a remote server can scale more like an ordinary HTTP service. That is useful progress. It does not remove the need for authentication, authorization, or operational discipline. Context is becoming an infrastructure problem Coding agents need repository context. Naively giving an agent the whole tree creates token cost, irrelevant information, distraction, higher latency, and sometimes worse reasoning. Bigger context windows do not eliminate the problem. The question shifts from “how much can the model hold?” to “which context deserves to be there?” This is where a lot of my early work sat. Hexum.dev began in part around making repository context more efficient, so the agent saw the relevant structure instead of a raw dump of files. On a published 24-task benchmark using MBPP and HumanEval, the measured context sent to the model dropped from 220,393 tokens to 27,352 (an 87.6% reduction) while still passing all official tests. The methodology is public. The number is less important than the observation: once you start treating context selection as a deliberate step rather than a dump, other constraints appear. Developers talk about this constantly now under the banner of context engineering. Progressive or dynamic tool discovery is one response to a related problem: loading every tool schema from every server into the context on every turn. Client best practices now recommend deferring full definitions and providing a search-style meta-tool. The same guidance explains why: progressive discovery can dramatically reduce tool-definition tokens and can improve selection accuracy by keeping the model focused on a smaller set of relevant tools. The pattern is not universal yet, but the pressure is clear. Tool explosion and selection There is a point where giving an agent 50, 100, or several hundred tools becomes harmful rather than helpful. Selection accuracy can drop. Context fills with schemas the model may never need. Name collisions and vague descriptions make the problem worse. Should every tool definition always sit inside the active context? Or should tools themselves be retrieved dynamically? Both approaches exist in the wild today. Static registration is simple when the surface is small. Progressive discovery, semantic search over tool descriptions, and gateway-style routing that exposes a smaller set are all being tried. The protocol itself is moving in this direction through progressive discovery guidance and related work. What remains open is how much of the selection logic lives in the client, in a gateway, in the server, or in the model’s own tool-use training. Least privilege also matters here: an agent that can see every tool is an agent that can be tricked into calling ones it should not have access to. Security becomes more serious as agents become autonomous MCP security is not the same as ordinary API security. An agent can read untrusted text, interpret it as instructions, call tools, and mutate external state. That creates surfaces that look like prompt injection, confused-deputy problems, over-broad permissions, malicious or poisoned tool descriptions, secret leakage through arguments or results, and supply-chain risk from the servers themselves. None of this means the protocol is inherently insecure. It means that once natural language can cause software to invoke real capabilities, the trust boundaries and permission model become critical. Least privilege, explicit approval for destructive actions, careful handling of tool results as untrusted input, and authentication that survives the full path from client to server to backend system all matter more than they do for a conventional API. A 2026 measurement study of 7,973 live remote MCP servers found that 40.55% exposed tools without authentication. That is a deployment problem, not a protocol problem, but it is the problem teams actually hit. Reliability when agents start doing real work A human using software notices an error and stops. An autonomous agent may continue. That changes the requirements around retries, idempotency, timeout behavior, partial failure, and validation of tool results. Observability becomes more important because you may need to reconstruct what the model believed, which context it saw, which tools it knew about, which one it selected, what arguments it generated, what the tool returned, and what it did next. Standardized telemetry is starting to appear. OpenTelemetry’s GenAI semantic conventions include MCP-related spans and attributes. Work such as SEP-414 reserves space in _meta for W3C trace context so traces can cross the MCP boundary. The official Python SDK now emits OpenTelemetry spans by default. Whether this becomes the default way teams debug agent-tool systems is still early, but the demand is obvious once agents move past demos. What building Hexum.dev taught me At first I thought one of the main problems was context efficiency. Hexum.dev’s early work on shrinking repository context for coding agents reflected that. Once you optimize context, you run into tool selection. Once you expose tools, you run into deployment and configuration. Once tools are remote, you run into authentication and permissions. Once agents become more autonomous, reliability, security, and observability move to the front. The realization was that MCP is not merely a protocol problem. It is becoming an infrastructure category. Hexum.dev today is a hosted remote MCP endpoint for coding agents. Its scope grew as we ran into adjacent problems around context handling, architecture checks, and controlling agent behavior. The agent still lives in the editor the developer already uses; Hexum.dev sits around specific parts of that workflow. Building it did not eliminate the surrounding problems. It made them concrete. There is one lesson from building Hexum.dev that has nothing to do with protocols. Most of building is uncertainty. Things fail, direction changes, and you spend a lot of time on ideas before anyone validates them. Having friends who listen, encourage you, and challenge you when needed matters more than founders often admit. Yuchen and Pranav have been two of those people for me. They are not building Hexum with me, but they have listened to countless ideas and made the uncertain stretches easier to keep moving through. MCP infrastructure might become its own layer A possible future stack looks something like this: models and agents at the top, agent runtimes and MCP clients beneath them, then an infrastructure layer that handles routing, authentication, permissions, context management, tool discovery, caching, observability, policy, and reliability, then the MCP servers themselves, then the databases, APIs, code, and SaaS systems those servers touch. This is a hypothesis, not a certainty. Some of those capabilities may end up inside model providers, inside agent runtimes, inside cloud platforms, inside gateways, or inside individual MCP servers. The boundary is not fixed. The interesting part is that the protocol’s success is forcing the question. Once tool interoperability is taken for granted, the remaining work is everything required to make that interoperability production-grade. The protocol was the start MCP’s biggest achievement may be that developers are beginning to take tool interoperability for granted. That is what successful standards eventually do. They make a previously hard problem feel ordinary. Standards rarely eliminate infrastructure. They move the infrastructure problem somewhere else. HTTP standardized how systems communicate, but we still built CDNs, load balancers, API gateways, observability platforms, identity systems, and cloud infrastructure around it. MCP may follow a similar path. The protocol gave agents a common language for tools. Now we have to build everything required to make that language reliable at scale. The interface is no longer the hardest part. The systems around it are.