I started using MCP with GitHub Copilot in early 2025, before most organizations had heard of the protocol. By May of that year I was presenting about it at Global Azure Madrid, and a few weeks later at AWS Community Day Colombia. In both talks I walked through the architecture, demonstrated server compositions, and warned the audience that credential management was an unresolved problem in the ecosystem. I wrote a non functional aspects focused blog post about it that September.
That was over a year ago. I have been building with MCP continuously since then, and I now run multiple custom servers that power workflows across consulting delivery, content evaluation, compliance management, and architecture review. This is what I learned, what failed, and what the enterprise is living through right now.
What MCP servers actually become
The conversation about MCP treats it as a way to connect AI agents to APIs. After sustained daily use, I can tell you that framing undersells it. The interesting MCP servers carry domain logic that would not make sense as a REST endpoint.
This matters because there was a real debate about whether MCP is necessary at all. In early 2026, developers argued on X that giving agents direct shell access through CLI was simpler, cheaper, and more reliable than the structured MCP approach. Perplexity’s CTO publicly moved away from MCP internally. Benchmarks showed CLI was 10 to 32 times cheaper for some tasks. The narrative became “MCP is dying.”
Then Scale AI ran a controlled comparison in July 2026: fifty long-horizon tasks, same backend tools exposed through both interfaces. Their finding was that the interface gap shrinks dramatically with frontier models. Opus 4.8 and GPT-5.5 performed similarly across MCP, CLI, and hybrid setups, and where a gap did appear it ran in both directions, with CLI ahead on data-heavy retrieval and MCP ahead on targeted reads and writes. The performance case for declaring MCP obsolete is weaker than the early benchmarks suggested.
What no benchmark measures is governance, and that is what changes when MCP servers stop being API wrappers and start carrying domain logic. A CLI command executes and returns. An MCP server can hold state across calls, enforce rules the agent cannot override, compose with other servers into multi-step workflows, and be inventoried and governed through a registry. No enterprise registry can answer “which CLI commands may this agent execute” the way Kiro’s MCP Registry can answer “which servers may this developer use.” The governance architecture that enterprises need depends on the structured surface MCP provides.
I built multiple custom servers over this period. One parses a custom DSL describing an intended image, then routes between deterministic code generation and AI image generation, sometimes compositing both in a single output. Same input produces the same branded image every time: a visual identity system with an MCP interface. A signal scanner monitors public discussions for practitioner conversations, runs tiered scoring to detect posts gaining unusual traction, and summarizes what matters. A compliance manager wraps a forms API into a full assessment lifecycle. A Workspace integration layer ties documents, spreadsheets, file storage, and dashboards into a single server.
Every one of these servers started simpler. The domain logic grew because daily use kept revealing what the agent could not carry in its context window.
The value is in how servers compose
An individual server is useful. A composition of servers is where the work changes qualitatively.
An architecture review workflow reads a consulting deliverable from a shared spreadsheet, downloads and analyzes the architecture diagram, validates that proposed services are available in the customer’s target region, scores the design against Well-Architected principles with strict penalties for missing details, cross-checks the executive summary against source data for consistency, then writes structured results back to the spreadsheet and notifies the responsible consultant. Six servers working together: document access, documentation verification, regional availability checks, threat modeling, results tracking, and team notification.
A pre-sales preparation workflow reads an engagement task from the project management system, downloads and converts annexed customer documents, researches the customer’s public presence, maps their situation to the firm’s solution portfolio, checks service availability and pricing in the customer’s region, and produces a structured brief with solution mapping, per-role talking points, and presentation slide content in the customer’s language. Seven servers again, different composition entirely.
In both cases, the output is a starting point that accelerates the expert’s work. It is input for human judgment, never a replacement for it. The architecture review produces a scored assessment the consultant adapts based on their knowledge of the customer, the constraints they discussed in the room, and the trade-offs that only human judgment can weigh. The pre-sales brief gives the team a structured foundation they extend with what they know about the relationship, the politics, and the real urgency behind the request. The human review is where the value compounds. The automation gets the expert to that review faster and with better-organized inputs than they would have assembled manually.
That is the insight most MCP commentary misses: the protocol is transport, the value is the domain logic inside the servers, and the real leverage comes from how specific combinations produce distinct workflows where each output feeds a human decision.
What broke
Credential boundaries force agent duplication. Two of my agent configurations load identical instructions and exist solely because one authenticates as a service account for team content and the other as a personal account for private content. Agent sprawl, because of scope segregation.
Server naming abstractions leak. The same server name in a configuration file can resolve to entirely different code depending on which agent loads it. I have two instances of one server name running different authentication paths against different data stores. The config tells you what the server is called. It tells you nothing about what is actually running.
Governance servers cannot be optimized away. I designed a lightweight agent with three servers for startup speed. Within weeks I had to add the quality-assurance server back, because without it the agent produced output that violated rules it could not self-detect. The lesson is structural: servers that enforce governance rules cannot be stripped for performance without losing the enforcement.
IAM interactions across services produce errors you cannot fix from where you stand. Enabling a feature on a knowledge base server failed with a permission error naming a principal I do not control, the knowledge base’s own execution role rather than the calling user. The IAM policy I can write is irrelevant to the error. Hours of diagnostics for a gap between two authorization models in different services.
I wrote the governance standard and cannot fully enforce it. The internal standard says: no credentials in version-controlled repositories, personal rather than shared, rotated at least semiannually, no public exposure without a security review. Enforcing even that required building a custom workstation posture scanner, because the AI tooling platforms provide zero visibility into what servers are running, what credentials they hold, or what data flows through them. The person who wrote the standard had to build the compliance tool by hand.
What the enterprise is living through right now
A server carrying domain logic, credentials, and access to business systems is infrastructure, and infrastructure needs an owner, an identity, and a lifecycle. That is where the deployment problem starts.
Many organizations I work with adopted MCP servers over the past year and cannot answer three basic questions: how many servers are running across their developer workstations, what credentials those servers hold, and what data flows through them.
In customer work, it is common to see teams move from local stdio directly toward hosted registries or gateways, while the controls between those two ends remain largely undefined.
Local stdio is the default. MCP servers running locally commonly inherit the full credential scope of the developer’s session, unless the organization adds isolation and identity controls. Major AI coding tools document this explicitly, as stdio servers execute arbitrary commands with the same privileges as the agent itself. Workable for one builder. Ungovernable at two hundred developers.
Docker containers improve isolation with restricted privileges, network controls, and built-in logging, though containers share the host kernel, which matters for processes that dynamically generate and execute code.
Hosted MCP registries concentrate risk at the platform layer. In June 2025, a path traversal vulnerability in Smithery, a shared MCP server registry, could exfiltrate a platform-wide authentication token that granted control over every server the platform hosted, more than three thousand of them. Separately, an unofficial Postmark MCP server with 1,500 weekly npm downloads was modified in September 2025 to silently copy every outgoing message to an attacker-controlled address for over a week. Astrix’s October 2025 analysis of 5,205 open-source MCP server implementations found that only 8.5% documented OAuth, while 53% relied on static API keys or personal access tokens.
AI gateways that bolted on MCP features created a different attack surface. LiteLLM and Bifrost are LLM routing gateways that added MCP utility endpoints inheriting process-execution semantics. LiteLLM’s MCP test routes accepted command parameters and spawned processes on the gateway host; chained with a framework bypass, this became unauthenticated remote code execution on a service holding every model API key (CVE-2026-42271, CISA Known Exploited Vulnerabilities catalog, June 2026). Bifrost’s MCP client registration allowed unauthenticated command execution with a single HTTP request against a gateway routing to more than twenty LLM providers (CVE-2026-90898, disclosed September 2026). These are LLM gateways with MCP bolted on, and the common failure is placing process execution beside a credential concentration point.
Platform-native registries govern what is permitted but not what happened at runtime. Kiro’s MCP Registry lets administrators create an allowlist of approved servers and enforces it within the client: developers can only use servers on the list, and unlisted servers are hidden and terminated. It syncs every 24 hours, version-pins servers, and supports both remote and local servers. It is built on the MCP Registry open standard and requires IAM Identity Center. The honest limitation: enforcement is client-side and can be circumvented by a user with local administrative access. AWS Agent Registry, generally available since August 2026, provides a centralized catalog with approval workflows and organization-wide discovery. On the Microsoft side, Azure API Center is a private MCP registry for review-before-use, Foundry Agent Service governs agent-to-MCP connections, and the API Management AI Gateway tier adds proxy-level observability and authentication. These controls answer what may be approved, and several expose telemetry for the servers they front. None of them yet answers the enterprise-wide question: which servers are running across every workstation right now, and what each one did.
Managed runtimes come closest to governed, at the cost of rebuilding the server. AWS Bedrock AgentCore runs each session in a dedicated microVM with platform-managed IAM. Microsoft Foundry Agent Service and Azure Container Apps host MCP servers as managed containers with identity integration. Cloudflare Workers deploy them at the edge with OAuth flows. These options give a server stronger identity and session isolation than a developer workstation, with telemetry and audit capabilities that vary by platform and configuration. But a custom server with file-system context parsing, multi-provider AI integration, and domain-specific scoring logic does not drop into a managed runtime without rearchitecting. The domain logic that makes an MCP server valuable is what makes it expensive to move to a governed environment.
There is a practical middle ground that I see working in customer delivery. When we build agentic solutions on managed platforms like AgentCore, the tools are scoped to the agent’s specific objectives and access boundaries from the start. A managed tool that can read a customer’s cost data and generate optimization recommendations does not need access to their entire Workspace or the ability to write back to production systems. The narrower scope is what makes the tool governable by design. Building managed tools for a specific agent is architecturally different from porting a local MCP server into a runtime. The migration to hosted environments usually reveals that the local server was doing three jobs that should have been three separate tools with three different permission sets.
What I would recommend
If I were advising a CTO adopting MCP today, I would start with three things.
Inventory before you build the second server. Before the second developer adds an MCP server, know what the first one installed. A registry, whether Kiro’s, AWS Agent Registry, Azure API Center, or a spreadsheet with server name, owner, credential scope, and data classification, is the cheapest governance control and the one most organizations skip.
Classify servers by what they touch. A server that reads public documentation is fundamentally different from one that writes to a customer spreadsheet or accesses production credentials. The classification determines whether local stdio is acceptable, whether container isolation is needed, or whether the server belongs in a managed runtime. Not everything needs to move to AgentCore. Some things must.
Test the managed-runtime migration for one server before you need it. The rebuild cost is real, and discovering it under a compliance deadline is the wrong time. Pick the server with the highest credential exposure, port it to a managed runtime, and measure what breaks. That measurement is your planning input for everything else.
The protocol itself is heading in the same direction. The MCP roadmap published in August 2026 names five priority areas, and three of them directly address the governance gap this post describes. The most consequential for enterprises is transport unification: extending Streamable HTTP to cover local servers that currently run over stdio. That brings them under the same controls organizations already apply to remote services: authentication, logging, proxy-level observability, and gateway enforcement. That is a structural change in how local servers can be governed. The roadmap also prioritizes agent identity through Workload Identity Federation and DPoP, so agents authenticate with their own credentials rather than inheriting whatever the developer’s session holds. Enterprise-Managed Authorization became a stable extension in June 2026. The roadmap turns these concerns into current engineering work, with Working Groups, SEPs, and SDK changes already underway. The investments a CTO makes now in inventory, classification, and managed-runtime testing align with where the protocol is moving.
Where this leaves us
I warned audiences about credential management in May 2025. Over a year later, the protocol is part of how I work every day, the domain systems I built on top of it are some of the most productive tools I own, and the credential problem is now documented, actively exploited in adjacent infrastructure, and still structurally unresolved at the deployment layer.
MCP gives me a sound interface for composing domain systems, but the protocol does not yet supply the deployment controls enterprise use requires. The roadmap shows the protocol’s maintainers know this: transport unification, agent identity, and enterprise-managed authorization are all active engineering work, and each one closes a piece of the governance gap I have been living with. What you can build inside MCP, when you treat servers as domain systems and compose them into workflows that accelerate human experts, is genuinely powerful. The deployment architecture is catching up, and the direction is right.
What a CTO can do today is straightforward: inventory what is running, classify it by what it touches, and test the migration path for the servers that carry the most risk. The protocol is moving toward governed deployment. Whether your organization will be ready when it arrives, or still discovering how many unmanaged servers are running on developer laptops, is the question you have to ask.
Ricardo
