MCP: The Open Standard That Prevents AI Vendor Lock-In for ITSM

The vendor lock-in problem in AI for ITSM

In 2025, three of the largest AI-for-IT-support companies were acquired by platform vendors:

• Moveworks → ServiceNow ($2.85B)
• Aisera → Automation Anywhere
• Espressive → Resolve Systems

Each acquisition turned an independent AI product into a captive feature of a larger platform. For customers who were not on that platform, the writing was on the wall: invest elsewhere.

This is the vendor lock-in problem. When your AI is tightly coupled to a single ITSM backend through proprietary connectors, changing your ITSM means losing your AI investment.

What is MCP?

Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools and data sources. It defines a simple interface: JSON-RPC 2.0 messages over stdin/stdout.

In practical terms, MCP means an AI agent does not need to know how Freshservice or HaloITSM works internally. It calls standardized tool functions like create_ticket, search_kb_articles, or get_asset_relationships. A separate MCP provider module translates those calls into the specific API requests for each ITSM platform.

How MCP works in practice

The architecture separates concerns cleanly:

AI Agent (voice/chat) → MCP Client → MCP Provider (Freshservice)
                                   → MCP Provider (HaloITSM)
                                   → MCP Provider (ServiceNow) [future]

The AI agent speaks MCP. It never makes direct API calls to Freshservice or HaloITSM. The MCP provider is a sidecar process — a separate Node.js application that runs alongside the agent and handles all ITSM-specific logic.

Adding a new ITSM platform means building a new MCP provider module. The core AI agent, with all its voice processing, language understanding, and conversation management, stays untouched.

Why this matters for IT teams

1. ITSM migration does not break your AI

If you move from Freshservice to HaloITSM (or vice versa), your voice AI agent continues working. You switch the MCP provider. The agent, its voice pipeline, its authentication system, its conversation history — all preserved.

2. Multi-ITSM environments are supported natively

MSPs managing clients across different ITSM platforms can use the same AI agent with different MCP providers per tenant. No need for separate AI deployments per ITSM platform.

3. Custom integrations follow a standard pattern

Need to connect to an internal ticketing system? The MCP specification is public. Building a custom MCP provider follows the same pattern as the built-in ones. JSON-RPC 2.0 is well-understood and widely supported.

4. The AI investment is portable

Your investment in prompt engineering, conversation flows, authentication configuration, and operational knowledge is not tied to a single vendor. The MCP architecture ensures that the AI layer and the ITSM layer are independently replaceable.

31 ITSM tools via MCP

A comprehensive MCP implementation covers the full ITSM workflow:

Ticket management: Create, update, close, reopen, reassign, get history

Knowledge base: Search articles, get article details, search known errors

Change management: Create change requests, list changes, check status

Asset management: Search assets, get relationships, report issues

Approvals: Create requests, check status, list pending approvals

Service catalog: Get catalog items, create service requests

Each tool is a standard MCP function call. The AI agent decides which tools to use based on the conversation — the same way a human agent would decide which screens to open in Freshservice.

The alternative: proprietary connectors

Without MCP, AI-ITSM integrations look like this:

• Vendor A builds a custom Freshservice connector
• Vendor B builds a custom ServiceNow connector
• Each connector is proprietary, maintained by the AI vendor
• Switching ITSM or switching AI vendor means starting over

This is the model that led to the 2025 acquisition wave. When your AI is structurally coupled to one ITSM, the acquisition of the AI vendor by the ITSM vendor becomes a logical conclusion. And a problem for everyone who uses a different ITSM.

Looking forward

MCP is still early. The protocol specification is evolving, and the ecosystem of MCP-compatible tools is growing. But the core idea — standardized interfaces between AI agents and the systems they interact with — is sound.

For IT teams evaluating AI solutions, the question is worth asking: if we change our ITSM platform in three years, does our AI investment survive?

With MCP, the answer is yes.