De nieuwe enterprise-capaciteitsschicht voor AI – Deel 1

Door Tomydas Pall, Groepsproductmanager

In this two-part blog series, I explore how Modelcontextprotocol (MCP) is evolving from a mechanism for connecting AI applications to tools and data into something much more significant for the enterprise.

This evolution comes at a critical point in enterprise AI adoption, as the focus shifts from what AI can answer to what it can securely and reliably do. That requires governed access to tools, data and workflows.

In July 2026, Atlassian reported more than five million MCP tool calls per working day through its Rovo MCP Server. More than half of active users were enterprise customers, 44% were outside software teams, and nearly one-third of calls were write operations.

That is a pretty good indication of how quickly MCP has moved.

MCP started in late 2024 as a way to connect AI applications to external tools and data. Less than two years later, it has moved well beyond developer experimentation. The MCP project now reports close to half a billion monthly downloads across its Tier 1 SDKs, while production implementations are generating millions of tool invocations every day.

I have been closely involved in enabling MCP on the Jitterbit Harmony platform, and my understanding of the protocol deepened considerably as we worked through the details.

At first, I mostly saw MCP as another interoperability mechanism. What stood out was realizing that making a tool callable was the easy part.

The harder questions were:

• Who should be able to discover it?
• Who should be able to invoke it?
• What identity should the request carry?
• How should the action be governed?
• How do we test it?
• How do we trace what happened afterward?
• How does it connect back to the APIs and workflows already running the business?

That is when MCP started to look less like another integration protocol and more like something broader: an AI-facing capability layer for the enterprise.

What MCP Actually Standardizes

At its core, MCP uses a client-server architecture.

An AI application acts as the host. Within that host, MCP clients communicate with one or more MCP servers, which expose context and capabilities the AI application can use.

Three server-side primitives sit at the center of the protocol:

• Tools expose functions the model can invoke, such as calling an API, querying a database or executing a business operation.
• Middelen expose contextual information such as files, schemas, application data or other information the AI can use when reasoning.
• Prompts expose reusable interaction templates and workflows that clients can discover and invoke.

That combination is important.

MCP is not just about function calling. It gives AI systems a common way to understand what they can do, what information they can use, and how certain interactions should be structured.

The current specification has also moved beyond the basics. It includes dynamic capability updates, remote HTTP operation, authorization, user elicitation and extensions for long-running Tasks and interactive MCP Apps.

A useful way to think about the difference between OpenAPI and MCP is this: OpenAPI describes software interfaces. MCP adds an AI-oriented interaction model for discovering and using capabilities, context, and reusable workflows.

From AI Answers to Enterprise Action

The first wave of generative AI was mostly conversational. A user asked a question and the model produced an answer.
Enterprise agents need to do more than that.

Imagine asking an agent to identify delayed orders, check available inventory, determine which customers are affected and notify the right account managers.

That requires two different things:

• Context: customers, orders, inventory, policies, prior interactions.
• Capabilities: updating an order, generating a quote, creating a case, sending a notification.

MCP represents those two needs directly.

Resources provide context. Tools provide action. Prompts package repeatable interaction patterns.

The interaction is shifting from:

User → AI → Answer

toward:

User → Agent → Enterprise Action

The Atlassian numbers make this more than a theoretical point. Nearly one-third of its MCP calls are writes, including creating work items and updating statuses.

That means AI is starting to participate in business processes, not just answer questions about them.

Why MCP is Gaining Traction

MCP is not the only way to connect AI to enterprise systems.

You can expose existing APIs through OpenAPI and native model tool calling. AI vendors can build proprietary connectors. Agent frameworks can define their own tool abstractions.

For a small number of tools, those approaches are perfectly reasonable. In many cases, I would probably choose them myself.

The problem changes when the environment gets larger.

Suppose an organization has:

• (M) AI platforms
• (N) enterprise capabilities

Without a common interface, the number of bespoke relationships can conceptually approach:

[ M x N ]

With a shared protocol, the architecture moves closer to:

[ M + N ]

This is not a literal reduction of enterprise integration complexity. Authentication, authorization, semantics, workflow logic and data models do not disappear.

The point is simpler: MCP shifts the architecture away from many one-off pairings toward a common client-server contract.

That is where I think MCP starts to earn its keep.

Its discovery model helps too. Clients can ask a server which capabilities it supports rather than depending entirely on hard-coded knowledge. Tool, resource and prompt catalogs can evolve, and clients can be notified when they change.
That makes MCP feel less like a static connector definition and more like a discoverable capability interface.

MCP and A2A: Different layers of the agent architecture

It also helps clarify the relationship with A2A:

• MCP: AI application ↔ capabilities
• A2A: agent ↔ agent

I do not see these as competing standards so much as different layers of the emerging agent architecture.

The Real Opportunity: Turning Connectivity into Capability

MCP is evolving beyond a common way for AI applications to connect to tools and data. It is becoming a potential foundation for how enterprise capabilities are discovered and consumed by AI agents. But exposing a capability is only the beginning. The bigger opportunity lies in rethinking how enterprises make their existing business capabilities available to AI without rebuilding the integration layer for every new model or agent platform. What does that look like in practice? And what will it take to make this architecture work at enterprise scale?

In Part 2 of the blog series, I will explore how integration platforms can evolve to expose business capabilities through MCP, why the protocol is becoming infrastructure in its own right, and why a robust control layer will be essential to governing how AI agents access and act on enterprise systems.

Klaar om aan uw Agentic AI-reis te beginnen?

Bekijk hoe Jitterbit u kan helpen bij het bouwen, verbinden en schalen van agentische AI-oplossingen met AI-assistenten, AI-agenten en de integratiebasis die nodig is om te concurreren in een AI-gedreven markt.

• Read: blog on Jitterbit MCP: De veilige basis voor Enterprise AI-agents
• Watch: Jitterbit MCP video
• Discover: Jitterbit MCP-klant
• Learn: from our experts, see Jitterbit AI agents in action and discover best practices for scaling deployment in this webinar.