MCP vs API vs Function Calling: Technical Comparison

Before the Model Context Protocol (MCP), connecting an AI assistant to an enterprise data source meant either writing a custom plugin, using the model's function calling mechanism, or building a dedicated API layer. Three approaches, three levels of complexity, three different ways to expose data to an LLM. This article compares these three mechanisms in a technical and concrete way, for developers and architects who need to choose.

The context: why connect an LLM to external data?

A language model, by default, only knows its conversation context and its training data. For it to reason about your data — your IT architecture map, your knowledge base, your CRM — you need to give it a mechanism to access those sources in real time.

Three technical approaches coexist today:

Direct API call: the developer exposes a REST/GraphQL API, integrates it into the LLM orchestration, and handles request/response serialisation manually.
Function calling: the model declares available functions in its system prompt; at inference time, it decides which function to call, and the orchestrator executes it.
MCP (Model Context Protocol): a standardised protocol, driven by Anthropic, that defines a universal interface contract between an LLM host and any external context source.

Comparison table: MCP vs API vs function calling

Criterion	Direct API	Function calling	MCP
Standardisation	None (each API differs)	Partial (provider-specific)	Universal (open protocol)
Integration effort	High (orchestration layer to build)	Medium (JSON schema declaration)	Low (ready-to-use MCP connector)
Portability across models	No	No (vendor-locked)	Yes (any compatible MCP client)
Context management	Manual	Manual	Native (protocol handles context flow)
Security / access control	Must be implemented on the API side	Must be implemented in the orchestrator	Handled by the MCP server
Call traceability	Must be implemented	Must be implemented	Built-in (server-side logging)
Read-only possible	Yes (if the API provides it)	Yes (if the function provides it)	Yes (by design in UrbaHive)
Multi-tenancy	Must be implemented	Must be implemented	Handled by MCP server (token = tenant)
Compatibility	Depends on the LLM client	Depends on the provider	Claude Desktop, claude.ai, Claude Code, any MCP client

Direct API: powerful but costly to integrate

Calling a REST API from an LLM is technically feasible. The developer retrieves the JSON response, formats it, and injects it into the model's context. But this approach has several limitations:

Every API is different. Authentication, response schema, pagination, error handling: everything must be reimplemented for each data source.
Orchestration is the developer's responsibility. Deciding *when* to call the API, *what* data to extract, *how* to present it to the model — all of this requires specific code.
Maintainability is low. Changing an API or switching models often requires refactoring the entire integration.

For production use across multiple data sources, direct API integration without an abstraction layer quickly becomes technical debt. That is precisely the problem MCP solves.

Function calling: progress, but vendor-locked

Function calling (or tool use) is a significant step forward. The developer declares a list of available functions with their JSON schema in the system prompt. At inference time, the model decides to call a function if the question requires it, returns a structured call, and the orchestrator executes the function before feeding the result back to the model.

Advantages:

The AI decides *when* to call which tool.
JSON Schema declaration is relatively standard.

Limitations:

Vendor dependency. OpenAI's function calling syntax differs from Anthropic's or Google's. A connector written for GPT-4 is not directly portable to Claude.
Manual context management. The developer still decides which functions to expose, handles errors, and formats results.
No discovery standardisation. Each integration redefines its own tool catalogue.

MCP: the universal standard for LLM-to-system connection

MCP introduces a higher abstraction layer. Instead of describing model-specific functions, you create an MCP server — a service that exposes resources, tools, and prompts according to a standardised JSON-RPC protocol. Any MCP client (Claude Desktop, claude.ai, Claude Code, or any compatible third-party client) can connect to this server without additional integration code.

What MCP standardises concretely:

Capability discovery: the client asks the MCP server what it can do (tools/list, resources/list).
Structured calls: requests and responses follow an identical JSON-RPC 2.0 schema regardless of the data source.
Transport: stdio for local processes, HTTP/SSE for remote servers.
Context management: the protocol natively handles the information flow between the model and the source.

For an enterprise architect, the analogy is USB: before USB, every device had its own connector. MCP is the USB of AI connectors.

Why UrbaHive chose MCP

UrbaHive exposes its IT architecture map via an MCP server rather than a dedicated API or function calling, for three reasons:

Immediate portability. The same MCP server works with Claude Desktop, claude.ai, and Claude Code without modification.
Security by design. The MCP server can be designed as read-only at the protocol level — no need for guardrails at the orchestrator level.
Simplified developer experience. Generate a token, paste a JSON configuration, ask questions: no client-side code to write.

To see this in practice, read our article Connecting Claude to your IT map via MCP and our complete MCP guide.

When to use which approach?

Use case	Recommended approach
One-off integration, single source, technical team available	Direct API
Chatbot with business tools, single model, limited scope	Function calling
Connecting multiple data sources to multiple AI models	MCP
AI access to IT architecture map with GDPR compliance	MCP (sovereign server)
Quick prototype without infrastructure	Function calling

Conclusion

MCP, direct API, and function calling are not in competition: they address different levels of maturity and complexity. For teams that want to connect an AI assistant to their enterprise data in a durable, portable, and secure way, MCP is currently the most robust approach.

For architects and developers who want to experiment concretely, UrbaHive offers a ready-to-use MCP server, connected to your IT architecture map, read-only and hosted in Europe.

Create your UrbaHive account and test the MCP connector today. See also the Connectors page for technical details.

FAQ

Does MCP fully replace function calling?

No. Function calling remains relevant for simple, single-model integrations with a limited set of tools. MCP adds value when you need portability across models, multiple data sources, or shared infrastructure across teams.

Can an MCP server expose write operations?

Yes, the MCP protocol allows it. But it is not required. UrbaHive chose to expose only read operations to guarantee connector security. Each implementer decides what to expose.

Is MCP compatible with OpenAI or Gemini models?

The MCP protocol is open and third-party clients are beginning to implement it. Natively, MCP is supported by the Claude family (Anthropic). Compatibility with other models depends on the client used.

What is the difference between an MCP tool and an MCP resource?

An MCP tool is an action the AI can trigger (e.g., search for an application by name). An MCP resource is a document or data stream the AI can read directly (e.g., a server record). Both are exposed by the MCP server.

How long does it take to build an MCP server?

A minimal MCP server (a few tools, one data source) can be built in a few hours using available SDKs (Python, TypeScript). Complexity grows with the number of sources and security requirements.

Internal links: