So you’re building AI agents and you need to pick a platform. Google ADK, Microsoft Foundry, or JetBrains Koog — all three claim first-class MCP support. The question is which one actually fits your stack. With 97 million MCP SDK downloads per month and over 10,000 active servers, Model Context Protocol isn’t a “promising protocol” anymore — it’s infrastructure. The decision isn’t whether to adopt MCP. It’s which platform’s implementation makes the most sense for your team.
This article is a structured side-by-side look at MCP capability depth, hosting models, and protocol trade-offs across the three platforms — closing with a practical decision framework. If you’re new to MCP, what MCP is is covered in our pillar overview. This article assumes you’ve already decided MCP belongs in your architecture and you’re now choosing where to build.
What does it mean for MCP to be “de facto infrastructure” in 2026?
MCP (Model Context Protocol) is an open protocol from Anthropic that standardises how AI agents connect to external tools, APIs, and data sources. It solves the N×M integration problem — without a standard, connecting 20 AI models to 20 enterprise systems requires up to 400 custom connectors; with MCP, each system publishes one server accessible to every MCP-compatible client. MCP’s client-server architecture covers this in detail.
The adoption numbers are infrastructure-scale: 97 million monthly SDK downloads, 900% year-over-year growth, 10,000+ active servers, and 28% Fortune 500 deployment.
Here’s the analogy that makes the inflection point clear. Every major DBMS vendor eventually shipped standard interfaces — JDBC, ODBC, SQL — because the ecosystem reached a threshold where non-compliance meant irrelevance. By 2025, every major DBMS vendor had also shipped an MCP server. Same pattern.
MCP is now backed by Anthropic, OpenAI, Google, Microsoft, and AWS. Governance has transferred to the Linux Foundation under the Agentic AI Foundation (AAIF) — the same vendor-to-neutral-foundation transition that marked HTTP, TLS, and container standards.
The implication: choosing between ADK, Foundry, and Koog is a question of which implementation of required infrastructure best fits your team. Not whether to implement it at all.
How does Google ADK’s four-tool taxonomy frame the MCP decision?
Google ADK (Agent Development Kit) gives enterprise teams the most structured published guidance on where MCP fits within an agent architecture. It does this through an explicit four-tool taxonomy that classifies all tool access into distinct categories.
The four categories, as documented by Janakiram MSV in The New Stack, are:
- Function Tools: Developer-defined Python functions. Most flexible; no external dependency.
- Built-in Tools: Google-managed capabilities enabled through configuration — Google Search, Code Execution, and Vertex AI Search.
- Third-party Tools: Integration with LangChain and CrewAI via an adapter layer, so external tools participate in the agent runtime without native reimplementation.
- MCP Tools: The fourth and most interoperable category. Uses
McpToolset— the concrete Python class that handles discovery and invocation of remote MCP tools. Supports both SSE (for remote and cloud-hosted servers) and stdio (for local subprocess servers) transports.
Positioning MCP as the fourth category is architecturally deliberate. McpToolset queries the MCP server via list_tools, converts schemas into ADK-compatible tool instances, and proxies calls using call_tool. You provide the endpoint and transport type; the framework handles the rest.
ADK’s Cloud Architecture Guide is direct on when to use which: MCP for modular or multi-agent systems requiring interoperable, reusable tools; Function Tools when you’re integrating a specific API that won’t be reused across agents.
The Third-party Tools category matters if you’ve got LangChain investments. ADK’s LangChain adapter lets you keep that ecosystem while adopting ADK as the orchestration layer — migration-lite, lower adoption risk. ADK’s default LLM is Gemini, but the taxonomy is model-agnostic and supports Python, Java, and Go.
How does Microsoft Foundry integrate MCP and A2A in its agent framework?
Microsoft Foundry — rebranded from Azure AI Foundry, so you’ll still see both names in documentation — is Microsoft’s unified Azure platform-as-a-service for enterprise AI operations, with built-in tracing, monitoring, evaluations, and access control through Entra ID and Microsoft Defender.
The developer-facing SDK is the Microsoft Agent Framework — the direct successor to both Semantic Kernel and AutoGen. Not a parallel product; the next generation of both. It combines AutoGen’s clean abstractions for single- and multi-agent patterns with Semantic Kernel’s enterprise-grade features: dependency injection, IChatClient, ASP.NET hosting, and built-in OpenTelemetry.
The defining characteristic is its dual-protocol architecture. MCP handles agent-to-tool connectivity; A2A (Agent-to-Agent protocol) handles agent-to-agent peer communication. Where ADK requires third-party integrations for A2A, Agent Framework ships both natively — a richer multi-agent setup out of the box, at the cost of more complex initial configuration.
Microsoft’s specific MCP infrastructure components are the Azure MCP Server (used in reference implementations with GitHub Copilot for Azure) and the Windows MCP Registry (a Microsoft-managed catalogue of approved MCP servers). The Registry matters for the self-hosted vs. managed trade-off below.
The reference implementation uses .NET Aspire — a clear signal that Foundry’s primary audience is .NET and Azure enterprise teams. At Microsoft AI Dev Days, Maria Naggaga described MCP as “the backbone of the agent tool layer.” Microsoft Agent Framework is currently in public preview.
One important constraint: Foundry is Azure-native. For non-Azure organisations, ADK or Koog are the better options. For MCP governance stability context relevant to long-term platform risk, see the Linux Foundation stewardship overview.
What does JetBrains Koog bring to the enterprise MCP platform decision?
JetBrains Koog is the least recognised of the three platforms but arguably the most MCP-native. Built by JetBrains — the team behind IntelliJ IDEA, PyCharm, and Kotlin — Koog is a Kotlin-first, multiplatform AI agent framework with MCP as a core capability from day one. Not a retrofitted integration. Built that way from the start.
Koog’s agents-mcp module is a dedicated MCP integration component. Like ADK’s McpToolset, it supports both SSE and stdio transports. But unlike ADK and Foundry, MCP support wasn’t bolted onto an existing framework — the architecture was designed around it.
Koog’s Kotlin Multiplatform gives it the widest deployment footprint of the three: JVM, Android, iOS, and WebAssembly. It also supports multiple LLM providers — OpenAI, Anthropic, Google, OpenRouter, and Ollama — contrasting with ADK’s Gemini-default and Foundry’s Azure OpenAI-primary orientations.
ACP disambiguation — two separate protocols share this abbreviation in Koog, and conflating them will cause confusion.
JetBrains Agent Client Protocol (JB ACP) is JetBrains-specific agent-to-IDE connectivity — enables agents to interact directly with IntelliJ-based IDEs via standard I/O transport. Any ACP-compatible agent can work with any ACP-compatible editor, meaning Codex, Cursor, GitHub Copilot, and Koog agents work inside IntelliJ natively. This is unavailable in ADK or Foundry.
AAIF ACP (from IBM/BeeAI, March 2025) was a REST-based agent-to-agent messaging protocol. It merged into the A2A protocol under the Linux Foundation in August 2025. Koog supports A2A for multi-agent workflows.
So to be clear: JB ACP = agent-to-IDE. A2A (which absorbed AAIF ACP) = agent-to-agent. Different things.
For teams already in the JetBrains ecosystem, the adoption barrier is low and the IDE-native agent capabilities are a genuine differentiator.
MCP vs. direct API calls: when is the extra layer worth it?
Every agent builder hits this question at some point. For a given tool integration, is an MCP server layer actually warranted, or is a direct API call simpler?
Use MCP when: the same tool will be used across multiple agents or frameworks — standardisation pays off. When tool discovery is needed (MCP servers self-describe via list_tools). When audit and observability matter — MCP’s JSON-RPC 2.0 format provides correlation IDs and consistent instrumentation. Or when a community or vendor MCP server already exists for the tool.
Use direct API calls when: low latency is critical. The tool is unique to one agent with no reuse planned. Or complex bulk data operations are better handled with developer-managed error control.
Production systems use both. MCP for flexible, dynamic tool use. Direct APIs for deterministic workflows and bulk operations. That’s just how it plays out.
On UTCP: Universal Tool Calling Protocol proposes direct tool-calling without a server intermediary — lower latency, no infrastructure. With the MCP ecosystem at 97M downloads and 10,000+ servers, UTCP is a niche consideration for new enterprise projects unless you have a specific requirement MCP can’t meet.
Self-hosted, cloud-hosted, or managed registry: how to choose?
Sort out your hosting model before you finalise platform selection — hosting constraints can drive the platform choice.
Self-hosted: Your organisation runs MCP servers on its own infrastructure. Maximum control over data residency, security, and access management. Required for regulated industries — healthcare, financial services, government — where data sovereignty prohibits vendor-infrastructure traversal. Operational overhead is real: patching, supply chain security, and server integrity verification all fall to you. For SAFE-MCP controls for self-hosted servers, the dedicated security framework covers the baseline.
Cloud-hosted: MCP server runs on vendor cloud infrastructure via SSE transport. Lower operational overhead; access control via vendor SSO and cloud IAM. Worth noting: an April 2026 analysis of 2,181 remote MCP endpoints found 52% dead and only 9% fully healthy — reliability planning is non-optional.
Managed registries: Vendor curates a catalogue of approved MCP servers. The Windows MCP Registry in Foundry is the enterprise example. Lowest friction, at the cost of vendor dependency and reduced control.
Here’s how the three stack up:
Self-hosted — highest control, highest operational cost, organisation-controlled data residency, best compliance fit for regulated industries, no vendor dependency.
Cloud-hosted — moderate control, moderate cost, data traverses vendor infrastructure, suitable for general enterprise use, moderate vendor dependency.
Managed registry — lowest control, lowest cost, vendor infrastructure, appropriate for low-sensitivity workloads, high vendor dependency.
Platform alignment: ADK is cloud-agnostic but Google Cloud-native for hosted options. Foundry is Azure-native with the Windows MCP Registry as a Microsoft-managed service. Koog is deployment-agnostic — Kotlin Multiplatform enables self-hosted and cloud-hosted equally well.
For governance questions once hosting is chosen — team ownership, lifecycle management, incident response — the operational governance guide has the detail.
Which platform should you start with? A decision framework
Given that MCP is now infrastructure, all three platforms deliver it as a documented, first-class capability. The decision is ecosystem alignment, not protocol access.
Here’s how they compare across the criteria that matter:
Google ADK — primary ecosystem: Google Cloud / Python; language: Python; MCP implementation: McpToolset (four-tool taxonomy); agent-to-agent: A2A via third-party; IDE integration: none; deployment: Google Cloud-native; LangChain path: direct via Third-party tools adapter; maturity: GA.
Microsoft Foundry — primary ecosystem: Azure / .NET; language: C# / .NET; MCP implementation: MCP toolchain in Agent Framework; agent-to-agent: A2A natively (Activity Protocol); IDE integration: none; deployment: Azure-native; LangChain path: indirect; maturity: public preview.
JetBrains Koog — primary ecosystem: JVM / Kotlin / JetBrains IDEs; language: Kotlin; MCP implementation: agents-mcp module (purpose-built); agent-to-agent: A2A natively; IDE integration: JB ACP (JetBrains IDEs); deployment: cloud-agnostic; LangChain path: indirect; maturity: growing.
Choose Google ADK if your team is Python-first, Google Cloud-committed, or has significant LangChain tooling. ADK’s four-tool taxonomy gives you the clearest published guidance on MCP placement within an agent architecture, and the LangChain adapter lets you keep your existing tool ecosystem without a full rewrite.
Choose Microsoft Foundry / Agent Framework if your team is .NET-first and Azure-committed. Native MCP + A2A dual-protocol support delivers a richer multi-agent architecture, and teams migrating from Semantic Kernel or AutoGen have a direct upgrade path.
Choose JetBrains Koog if your team is Kotlin-first, JVM-based, or invested in JetBrains IDE tooling. IDE-native agent integration via JB ACP is a developer-experience differentiator unavailable in either competing platform, and the MCP-native architecture — purpose-built rather than retrofitted — stands out for teams where MCP depth is the primary criterion.
Protocol confidence: Linux Foundation stewardship of MCP under AAIF provides vendor-neutral governance relevant to long-term platform risk assessment for all three platforms.
MCP infrastructure is settled. Once every major vendor ships a standard interface, teams stop asking whether and start asking with whom. All three platforms deliver. The right choice is the one whose ecosystem, language, and deployment topology match the team you have.
For teams exploring the layer above raw MCP tool calls, Code Mode as the next architectural layer covers where ADK MCP tools and Code Mode converge. For the full MCP foundation, see our MCP guide.
Frequently asked questions
Can I use MCP with LangChain, or do I need to switch to ADK?
No switch required. LangChain has its own langchain-mcp-adapters package. Google ADK also supports LangChain via its Third-party tools adapter — teams keep their LangChain ecosystem while using ADK as the orchestration layer. ADK is an addition, not a replacement.
Is Microsoft Foundry only for Azure-hosted workloads?
In practice, yes. Foundry is Azure-native; the Microsoft Agent Framework targets Azure deployment; the Windows MCP Registry is a Microsoft-managed service. For non-Azure organisations, ADK or Koog are more appropriate.
Does Koog’s Kotlin-first approach limit it to JVM environments?
No. Koog uses Kotlin Multiplatform targeting JVM, Android, iOS, and WebAssembly. Teams building mobile-adjacent or cross-platform agents aren’t limited to JVM. That said, Python or .NET teams would need to adopt Kotlin — a real adoption barrier worth factoring in.
What is the difference between AAIF ACP and JetBrains ACP in Koog?
Two separate protocols share the abbreviation. AAIF ACP (IBM/BeeAI, March 2025) was an agent-to-agent messaging protocol that merged into A2A under the Linux Foundation in August 2025. JB ACP (JetBrains Agent Client Protocol) is JetBrains-specific agent-to-IDE connectivity — entirely different purpose. They coexist in Koog: A2A for multi-agent workflows; JB ACP for IDE integration.
How does MCP differ from the A2A protocol?
MCP handles agent-to-tool connectivity; A2A handles agent-to-agent peer communication. Complementary, not competing. Microsoft Agent Framework and Koog implement both natively; ADK supports A2A via third-party integration.
When should I use a self-hosted MCP server instead of a cloud-hosted one?
Self-hosted is the right call when data residency requirements prohibit vendor-infrastructure traversal, for regulated industries (healthcare, finance, government), or when maximum access management control is required. Cloud-hosted works for most general enterprise use cases where cloud vendor trust is already established.
Is MCP support in enterprise agent platforms production-ready in 2026?
Yes. All three platforms ship MCP as a documented, first-class capability. The 10,000+ active servers and 28% Fortune 500 deployment rate confirm production-grade infrastructure status. Microsoft Agent Framework is in public preview, but its MCP support is production capability.
