- MCP standardizes how agents talk to tools: retrieval, APIs, databases, code execution, and other agents.
- It separates what the agent wants from how the tool is implemented.
- MCP servers expose tools; MCP clients (agents) discover and call them at runtime.
- Most production agents use both MCP and function calling: function calling at the model level, MCP as the tool catalog.
- Enterprise h2oGPTe and the H2O AI Super Agent support MCP through an MCP Runner.
What is MCP?
MCP replaces bespoke, per-integration plumbing with a common, discoverable interface, the way HTTP replaced custom application protocols on the web.
Before MCP, every AI agent needed a custom adapter for every tool. A different call for retrieval, another for a CRM lookup, another for a database query, each with its own auth, schema, error handling, and quirks. As the number of tools grew, integration overhead outpaced the value of adding new agents.
MCP solves this by defining a small, universal contract: an MCP server exposes tools (with typed inputs, typed outputs, and a description), and an MCP client, typically an agent, discovers those tools at runtime and calls them. The contract is model-agnostic and vendor-neutral. The same tool works with any MCP-compatible agent, and any agent can talk to any MCP-compatible tool.
MCP is the answer to a specific 2025–2026 problem: organizations want agents to touch dozens of internal systems without writing custom integration code for each one. It sits alongside, and often complements, function calling, which handles the same problem at the individual model level.
How does MCP work?
An MCP exchange has three parts (discovery, selection, and execution), all mediated by an MCP Runner on the agent side.
- Discovery. The MCP Runner asks the server: "What tools do you expose?" The server returns a list of tools with names, descriptions, and JSON schemas for arguments and results.
- Selection. The agent's reasoning LLM reads the descriptions and decides which tool to call for the current step, often via function calling.
- Execution. The client sends a typed request, the server executes it (calling a database, an API, a code sandbox), and returns a typed response. The agent uses the result to plan the next step (orchestration manages the loop).
See the Enterprise h2oGPTe MCP integration docs for details on how H2O's MCP Runner handles auth, retries, and permission enforcement.
MCP vs. function calling
MCP
Function calling
Standard
Open, cross-vendor
Model-specific (OpenAI, Anthropic, etc.)
Discovery
Runtime, from a server
Static list in the prompt
Scope
Tools, prompts, resources, sampling
Tools (functions) only
Composition
Multiple MCP servers per agent
Single flat list per model
Best for
Enterprise tool ecosystems
Small, well-known toolsets
Most production agents use both: function calling as the model-level mechanism and MCP as the enterprise-level tool catalog.
Benefits of MCP
Write once, use everywhere. A tool exposed via MCP works with any compatible agent. Retire the "N agents × M tools" integration explosion.
Central governance. Because MCP servers sit between the agent and the underlying system, you can enforce permissions, quotas, and audit logging in one place.
Vendor portability. Swap the reasoning model without rewriting your tool layer.
Challenges of MCP
Ecosystem maturity. MCP is young. Not every tool has an MCP server; not every agent framework speaks MCP fluently. Expect gaps.
Security surface. An MCP server that speaks to your CRM is a new privileged endpoint. Treat it like any critical API: authenticate strongly, log everything, red-team it.
Discovery hygiene. Poor tool descriptions confuse the model. Investing in clear, minimal tool descriptions pays back in agent accuracy.
MCP use cases
- Enterprise agent platforms exposing dozens of internal tools (CRM, ticketing, data warehouse, docs) to a common agent runtime.
- Multi-agent systems where specialist agents call each other's capabilities via MCP.
- Vendor-neutral AI stacks that need to swap models without changing integrations.
- Regulated environments that need auditable, centrally governed tool access.
MCP in H2O AI
Enterprise h2oGPTe and the H2O AI Super Agent include an MCP Runner that connects agents to any MCP-compatible tool, plus tooling to expose H2O capabilities (RAG, Document AI, feature stores) as MCP servers. Governance and audit are enforced at the runner layer. Agents deployed on-prem or air-gapped keep the same protocol semantics they have anywhere else on the platform.