An MCP server (Model Context Protocol server) is a running software process that exposes your tools, data, and systems to an AI agent using a standardized interface. When a vendor says their product has “MCP support,” they mean their software can be connected to an AI like Claude so the AI can read data from it, take actions in it, or both — without custom integration code on your side. MCP is an open standard, first published by Anthropic in November 2024 and now governed by the Linux Foundation’s Agentic AI Foundation (AAIF), with adoption by Anthropic, OpenAI, and Google DeepMind as of early 2026.
What it is NOT
MCP is not a product you buy. You don’t pay for MCP. It is a protocol — a specification for how AI agents and software systems talk to each other. Think of it like HTTP, the protocol that governs how web browsers request pages: HTTP is not a browser or a server, it is the agreed-upon language they both speak.
MCP is not a guarantee of production readiness. A vendor claiming “MCP support” may mean anything from “we implemented the base protocol spec over a weekend” to “we run a hardened, SOC 2-compliant hosted MCP server with uptime SLAs.” The protocol compliance and the operational quality are separate things, and the gap between them is where real buyer risk sits.
MCP is not an agent or an AI. It is the plumbing that connects an AI agent to a system. The agent — Claude, or another LLM — is separate from the MCP server. A Salesforce MCP server exposes your CRM data to Claude; Claude is still Claude.
How it works (non-technical version)
An MCP server has three things it can offer an AI agent:
- Tools — actions the AI can perform: create a contact, update a deal stage, run a search query, send a message, trigger a workflow. These are the dangerous ones from a permissions standpoint; they write or act on your behalf.
- Resources — data the AI can read: files, database records, calendar events, contract text, job requisitions, pipeline data. Read-only. Lower risk.
- Prompts — pre-built templates the AI can invoke: structured queries, specialized workflow instructions bundled server-side.
When you register an MCP server in Claude (via Claude Code, the Claude desktop app, or a plugin), Claude discovers what tools and resources the server offers by reading the server’s manifest. From that point, when you ask Claude to do something that matches one of those tools — “update the deal stage for Acme Corp to Proposal” — Claude calls the tool, the MCP server executes the action against the real system, and Claude reports back.
The transport layer is either stdio (for a local server running on your machine) or HTTP/SSE (for a hosted server you connect to over the internet). Most vendor-provided servers are HTTP/SSE. Local servers are more common in developer workflows.
What “MCP support” actually means in a vendor pitch
Vendors have started adding “MCP support” to their positioning. The phrase can mean several distinct things:
- Level 1 — Protocol-compliant. The vendor built a server that follows the JSON-RPC 2.0 spec that underlies MCP. It works in demos. This is the minimum to claim MCP support. Token refresh, rate limiting, and pagination may not be handled. Production use requires your team to manage the operational complexity.
- Level 2 — Hosted and maintained. The vendor runs the MCP server for you. It handles OAuth token lifecycle (so your AI can still authenticate at 2 AM when tokens expire), rate limits against the underlying API, and provides an uptime SLA. This is what ops teams actually need to run reliable AI workflows.
- Level 3 — Managed MCP. A third-party provider (like a dedicated MCP infrastructure vendor) generates and maintains MCP servers across many SaaS tools from a single managed layer, handling multi-tenant isolation and operational complexity.
The difference between Level 1 and Level 2 is not visible in marketing material. You have to ask.
The five questions to ask any vendor claiming MCP support
Before relying on a vendor’s MCP server in a workflow, get answers to these:
- “Which AI platforms have you tested with?” If they say “we built it to the spec,” that is Level 1. If they name specific tested platforms and enterprise customers using it in production, that is more credible.
- “What happens when an OAuth token expires mid-workflow?” If they can’t describe the token-refresh behavior specifically, they haven’t handled it. This matters for overnight agentic runs and scheduled tasks.
- “Can I restrict my AI agent to read-only access?” Responsible MCP implementations let you configure whether the AI can only read data, or can also write and act. If they say no or look confused, the blast radius of a misconfigured AI workflow is larger than it needs to be.
- “Do you handle rate limiting on my behalf?” Your HubSpot, Salesforce, and Greenhouse each have different API rate limits. If the vendor’s MCP server doesn’t handle this, your AI workflows will start failing when they hit scale.
- “What is your SLA if the MCP server goes down?” An MCP server is now in the critical path of your AI workflow. Understand whether downtime is acceptable or whether you need an SLA-backed hosted service.
Why it matters for ops leaders right now
The MCP ecosystem had over 10,000 active public servers by early 2026 (source: Anthropic ecosystem reporting). Your RevOps, Legal Ops, and Recruiting vendors are adding MCP support to stay relevant to AI-first teams. This creates three concrete opportunities and one real risk:
Opportunities:
- AI agents (Claude, configured with Skills) can directly read and update your systems without custom integrations or API wrappers. A deal-review agent can pull MEDDICC data from Salesforce via MCP and update it after the call, with no manual data entry.
- Recruiting coordinators can run sourcing agents that read job reqs from your ATS via MCP, search candidates, and create draft outreach — all within a single Claude conversation.
- Legal teams can connect CLM systems via MCP so contract analysis runs against live documents, not stale copies.
The risk: “MCP support” as a vendor checkbox does not mean reliable production infrastructure. Treat vendor MCP claims the way you’d treat any API integration claim: ask about uptime, error handling, token management, and rate-limit behavior before building workflows on top of it.
MCP and Claude Skills working together
An MCP server alone gives Claude data access and action capability. It does not give Claude your team’s reasoning methodology. Pairing an MCP server with a Claude Skill — the Skill providing the procedure, the MCP server providing the live data — is what produces AI workflows that are both accurate and consistent. A contract-risk Skill connected to a CLM MCP server will outperform either layer alone, because the Skill encodes your risk thresholds and the MCP server provides the current contract text. For a full comparison of these two layers, see Claude Skill vs MCP server.
Common pitfalls
- Trusting “MCP support” without asking about operational quality. The protocol spec and production infrastructure are different things. Always ask the Level 1 vs Level 2 distinction before relying on a server.
- Giving the AI write access when read access covers the use case. Start with read-only MCP access. Add write tools incrementally, one at a time, and verify the scope before enabling them. An AI agent that can overwrite deal records or send emails needs tight scope controls.
- Assuming MCP eliminates integration work. Even at Level 2, someone configured the OAuth app, registered the server, and tested the tool outputs. MCP reduces integration cost substantially vs custom code, but it does not eliminate the setup step.
Related
- Claude Skill vs MCP server — how to pair the two layers for ops workflows
- Claude — the AI agent that consumes MCP servers