MCP (Model Context Protocol)

What is MCP (Model Context Protocol)?

MCP, or Model Context Protocol, is an open standard that defines how AI applications connect to external data sources, tools, and services. Rather than requiring a custom integration for every pairing of AI tool and data system (CMS, DXP, CRM, database, knowledge bases and documentation platforms, analytics platforms, etc.), MCP provides a shared interface: any compliant AI tool (such as Cursor, Claude Desktop, or GitHub Copilot) can discover and interact with any MCP-compatible server using the same protocol.

The standard works through two roles. MCP Servers expose capabilities such as reading content, executing operations, or querying data. MCP Clients are AI applications or agents that connect to those servers to retrieve context or take action at runtime. For enterprise content and marketing teams, this means a CMS, documentation platform, or content repository can be made accessible to any AI tool that speaks the protocol, without writing bespoke connector code for each individual integration.

What are the key benefits of MCP for enterprise digital teams?

Standardized AI integration: Connect any MCP-compatible AI agent or assistant to your content systems through a single, consistent interface, rather than maintaining separate integrations for each tool.
Reduced integration overhead: An MCP server built once works with any compliant AI tool. As new AI assistants and agents emerge, they connect to existing servers without additional development work.
AI-native content workflows: Developers and content teams can use AI tools that interact directly with live content models, documentation, and APIs, without leaving their primary work environment.
Vendor flexibility: Because MCP is a vendor-neutral open standard, organizations can adopt new AI tools without rebuilding their integration layer each time.
Governed AI access: MCP servers expose only the capabilities they are designed to expose. Teams control exactly what an AI can see and do, keeping security and content governance boundaries intact.

How does MCP work, and why does it matter for digital experiences?

MCP follows a client-server model. An MCP Server is deployed alongside a data source and exposes a defined set of resources and tools. An MCP Client, which can be an AI agent, an AI-powered development environment, or an AI assistant application such as Claude Desktop or ChatGPT, connects at runtime, discovers what the server offers, and calls what it needs. The AI does not need to know in advance how a given system stores its data; the server handles retrieval and returns results through the shared protocol.

For digital experience teams, this removes a significant barrier to practical AI adoption. Instead of choosing AI tools based partly on which CMS integrations they include out of the box, organizations can build an MCP server once and connect any compliant AI tool to it. That investment stays relevant as the AI tooling landscape evolves.

How does Xperience by Kentico support MCP?

Xperience by Kentico ships MCP server support as part of KentiCopilot, the platform's AI developer toolkit. Three MCP servers are included and can be enabled independently:

Content Modeling MCP: Allows AI assistants to query and work with content type definitions in Xperience by Kentico.Developers can scaffold and refine content models through natural language in their AI-powered development environment.
Content Management API MCP: Enables AI agents to create, update, and manage content through the Management API, surfacing content operations as tools any compliant agent can call at runtime.
Documentation MCP: Gives AI tools direct access to the official Kentico documentation at docs.kentico.com, so developers can query documentation without leaving their IDE or AI assistant.

In practice, a developer using Cursor or VS Code with an MCP-compatible AI assistant can query live content models, retrieve documentation, and manage content through their AI interface, without switching to the CMS administration interface or documentation site. This keeps development workflows faster and more connected to the platform's actual state.

Industry Insight

Model Context Protocol was released as an open-source specification by Anthropic in November 2024. It was created to address a fragmentation problem in AI-connected software: every tool was building its own proprietary connector for every data source. Within months of release, MCP was adopted by major AI development environments including Cursor, VS Code, and Claude Desktop, and enterprise software vendors across CMS, CRM, and productivity platforms began announcing support.

How do organizations benefit from MCP in their AI strategy?

Organizations that adopt MCP as part of their AI integration approach can expand their AI tooling without a corresponding growth in integration maintenance. Rather than evaluating AI tools partly on which CMS integrations they include out of the box, teams can choose the most capable tool for the job and connect it to existing systems through the shared protocol.

For enterprise teams managing complex content operations across multiple markets or product lines, MCP provides a path to involving AI assistants in content governance workflows and development tasks, without granting those tools uncontrolled access to production systems. The MCP server acts as a governed, intentional interface between AI capabilities and the content infrastructure they need.

How does MCP fit into an agentic AI strategy?

MCP is becoming a foundational component of agentic AI architectures, where AI systems need to dynamically discover and use tools rather than call a fixed set of predefined endpoints. As organizations deploy AI agents across content creation, personalization, and marketing automation, those agents need reliable and standardized access to the systems where content and customer data live. Without a shared protocol, each new agent requires its own integration work.

In Xperience by Kentico, the combination of a headless content architecture, an open Management API, and MCP server support through KentiCopilot positions the platform well as the content system of record in an agentic AI stack. It exposes governed, structured content to AI agents that need to retrieve, create, or update content as part of automated workflows, without requiring teams to rebuild that connectivity each time the AI tooling landscape changes.

What is the difference between MCP and a traditional API integration?

A traditional API integration requires a developer to write custom connector code for a specific pairing of AI tool and data system. Each new AI product a team adopts can mean a new integration to build and maintain.

MCP replaces that one-to-one problem with a standard protocol. A developer writes one MCP server for a data system, and any AI tool that supports MCP can connect to it. The AI tool discovers what the server exposes at runtime, rather than relying on hardcoded connector logic.

For Xperience by Kentico, this means the MCP servers included in KentiCopilot remain compatible with AI tools that adopt the protocol going forward, without requiring Kentico or its customers to build and maintain individual integrations for each new tool.

Frequently Asked Questions.

An MQL (Marketing Qualified Lead) is a prospect deemed ready for nurturing based on content engagement, while an SQL (Sales Qualified Lead) is one that sales has reviewed and confirmed is ready for direct outreach. The key difference is who owns the qualification and what criteria are used. MQLs are identified by marketing through behavioral signals like downloads or repeat visits. SQLs require validation against fit criteria such as budget, authority, need, and timing.

A lead typically moves from MQL to SQL when it crosses a predefined score threshold and a sales rep confirms it meets fit criteria. Most teams define this threshold collaboratively, combining marketing engagement data with firmographic or demographic filters. In Xperience by Kentico, automated workflows can trigger the handoff the moment a lead hits that threshold, so no qualified contact is left waiting.

Disagreements usually happen because marketing and sales are using different definitions of "ready." Marketing passes leads based on engagement; sales rejects them for lacking budget or authority. The fix is a shared, documented MQL and SQL definition with agreed scoring criteria. Platforms like Xperience by Kentico help by giving both teams visibility into the same contact behavior data, so the handoff is based on facts rather than opinion.

Leads that do not convert to SQL status should be returned to a nurture track rather than discarded. This is sometimes called a lead recycling process, and it keeps prospects engaged until their timing or fit improves. Xperience by Kentico supports automated re-nurture workflows that trigger when a lead is rejected by sales, ensuring marketing retains ownership and continues delivering relevant content..

Yes, some leads skip the MQL stage entirely and enter directly as SQLs. This typically happens when a prospect comes in through a high-intent channel such as a direct demo request, a referral from an existing customer, or an inbound inquiry with clear purchase intent. Most lead qualification frameworks account for this by allowing sales to manually promote a contact to SQL status regardless of their marketing engagement score.

Lead scoring is one of the main inputs into MQL qualification, but they are not the same thing. A lead score is a numerical value assigned based on behaviors and attributes. MQL status is the decision that score triggers once a threshold is reached. Some organizations also layer in manual review or additional fit criteria before granting MQL status, making qualification a process that scoring supports rather than replaces.