What Is an MCP Server? The Complete Guide

TL;DR - An MCP server is a lightweight process that exposes tools, data sources, and prompts to AI models via the Model Context Protocol — an open standard created by Anthropic. - It lets an AI agent call real-world APIs, query databases, and trigger workflows without custom glue code for every integration. - MCP servers work with Claude Desktop, Cursor AI, and any MCP-compatible client — think of them as USB-C for AI tooling. - Unlike a REST API, an MCP server is *agent-aware*: it exposes capability descriptions the model reads directly, so it knows *what* it can do and *when* to do it. - OpenHelm's hosted MCP server at mcp.openhelm.ai adds credential vaulting, audit trails, and human-in-the-loop approvals on top of raw protocol support. - Teams across hedge funds, SEO agencies, and RevOps are already running production workflows over MCP — not just experimenting.

---

What is an MCP server, and why does it matter?

Large language models are extraordinarily capable at reasoning. They are considerably less capable at *doing* — fetching live data, writing to a CRM, or firing off a Slack message. The gap between knowing and acting is where most AI projects stall.

The Model Context Protocol (MCP) closes that gap. An MCP server sits between your AI model and your tools, translating agent intentions into real-world actions. Since Anthropic published the open specification in late 2024, adoption has been rapid — and for good reason. It is the first genuinely standardised way to wire an AI agent into your existing infrastructure.

This guide explains exactly what is an MCP server, how the protocol works under the hood, and what it looks like in practice for real enterprise teams.

---

The Model Context Protocol: a brief history

Anthropic released MCP as an open standard in November 2024, with simultaneous support in Claude Desktop and the Claude API. The goal was straightforward: stop every developer from reinventing function-calling glue code and give the ecosystem a shared lingua franca.

Within six months, major IDEs (Cursor, Zed, VS Code via extensions), automation platforms, and dozens of SaaS vendors had shipped MCP-compatible servers. By mid-2025 there were over 2,000 community-built MCP servers indexed on mcp.so.

The protocol itself is transport-agnostic. It works over standard I/O (for local tools), HTTP with Server-Sent Events (for remote servers), or WebSockets. That flexibility is a large part of why it spread so quickly.

---

How an MCP server works: the technical picture

Think of an MCP server as three things packaged together:

1. A capability manifest — a machine-readable list of *tools*, *resources*, and *prompts* the server exposes. The AI model reads this manifest to understand what actions are available.
2. A request handler — logic that receives a structured tool-call from the model, executes it (query a database, call a REST API, run a script), and returns a structured result.
3. A transport layer — the channel between the AI client and the server, most commonly HTTP/SSE for remote deployments.

When a user asks Claude "What are our top five accounts by ARR this quarter?", here is what actually happens:

1. The MCP client (e.g. Claude Desktop) sends the user message plus the server's capability manifest to the model.
2. The model decides it needs the query_crm tool and emits a tool-call in its response.
3. The client forwards that call to the MCP server.
4. The MCP server authenticates, calls your CRM's REST API, and returns the results.
5. The model synthesises the data into a clean answer.

No custom prompt engineering required. No hard-coded API keys in the model context. The separation of concerns is clean by design.

---

MCP servers vs REST APIs: what's the difference?

This is the question every developer asks first. The short answer: a REST API is for *humans and apps*; an MCP server is for *AI agents*.

A REST API tells another *application* what it can do. An MCP server tells an *AI model* what it can do — and crucially, provides enough semantic context that the model can decide *when* to use each capability autonomously.

You can absolutely build an MCP server that wraps an existing REST API. Most do exactly that.

---

A realistic example: the RevOps analyst at a Series B SaaS company

Sara is a RevOps analyst at a 120-person SaaS company. Her Monday morning ritual: pull ARR by segment from Salesforce, cross-reference churn flags from Gainsight, check pipeline velocity in HubSpot, and write a board-ready summary by 9 AM. It takes about 90 minutes — every single week.

Her company deployed an OpenHelm MCP server connected to all three platforms. Now Sara opens Claude Desktop, types "Prepare Monday's revenue digest", and the agent executes the same three-step data pull automatically. It surfaces anomalies, drafts the narrative, and drops a formatted report into Notion.

The whole thing runs in under four minutes. Sara spends the remaining 86 minutes doing analysis the model genuinely cannot do: building the strategic argument for the board.

This is not a hypothetical. It is the pattern we see consistently across RevOps use cases where data lives in three or more disconnected systems.

---

What can you expose through an MCP server?

The protocol supports three primitive types:

Tools

Actions the model can invoke — equivalent to function calls. Examples: search_web, query_database, send_email, create_ticket, run_python_script.

Resources

Read-only data the model can pull into context — files, database records, API responses. Resources are fetched on demand rather than stuffed into the system prompt, which keeps context windows lean.

Prompts

Reusable prompt templates the server exposes to the client. Useful for standardising how agents approach recurring tasks — a legal review template, a financial summary format, an escalation script.

Most production MCP servers combine all three. A CRM server might expose update_account as a tool, accounts as a resource, and generate_account_summary as a prompt.

---

MCP server for ChatGPT, Cursor AI, and beyond

One of the protocol's genuine strengths is client diversity. As of mid-2026:

• Claude Desktop — Anthropic's official client, the original MCP reference implementation.
• Cursor AI — the AI code editor uses MCP to connect agents to dev tools, databases, and internal APIs. Many engineering teams run their entire internal tooling through a single Cursor-connected MCP server.
• mcp server for ChatGPT — OpenAI added MCP support in early 2026, meaning servers built to the spec work across model providers with no modifications.
• VS Code (via extensions) — GitHub Copilot and third-party extensions support MCP for code-adjacent workflows.
• Custom agents via the API — any agent built on the Anthropic API, OpenAI API, or open-source frameworks (LangChain, LlamaIndex) can call MCP servers directly.

The write-once, run-anywhere promise is largely delivered. Build a compliant server and it works across the ecosystem.

---

Security and enterprise concerns

Raw MCP is a protocol, not a security model. The specification deliberately leaves authentication, authorisation, and audit logging to implementors — which is sensible for an open standard but creates real work for enterprise teams.

Anthropic researcher Amanda Askell has noted: *"The power of tool use scales directly with trust. Getting the trust model right — who can call what, under what conditions — is the unsolved hard problem of agentic AI."*

For enterprise deployments, that means you need:

• Credential vaulting — agents should never see raw API keys. Secrets live in the server, not the prompt.
• Permission scoping — an agent doing customer support should not have access to billing mutation endpoints.
• Audit trails — every tool call logged with user, timestamp, inputs, and outputs.
• Human-in-the-loop approval queues — for high-stakes actions (sending an email to 10,000 customers, approving a payment), the agent should pause and ask a human before proceeding.

This is precisely the gap OpenHelm fills. Our hosted MCP server wraps the raw protocol with enterprise controls out of the box — credential vault, role-based scoping, immutable audit log, and an approval queue for flagged actions. You get all the speed of agentic automation without the governance headache.

For a broader look at how these human oversight patterns work, see our post on human-in-the-loop AI.

---

How to get started with MCP

Option 1: Run a local MCP server

The quickest path is installing an open-source server (e.g. the Filesystem MCP server) and connecting it to Claude Desktop via the config file. You are up and running in under ten minutes, but you manage everything yourself.

Option 2: Use a hosted MCP server

For teams that want production-grade reliability without running infrastructure, a hosted server like OpenHelm's MCP endpoint handles the transport, auth, and scaling. You connect your tools via the dashboard and get a stable endpoint URL to paste into your client config.

Option 3: Build your own

The MCP SDK is available in TypeScript and Python. Building a custom server makes sense when you have proprietary internal APIs or unusual auth requirements. Most teams combine custom servers for internal tools with hosted servers for commodity integrations.

To understand how MCP fits into a larger agentic architecture, our post on how AI workflow automation works is a solid companion read.

---

Frequently asked questions

What is an MCP server, in plain English?

It is a small programme that sits between an AI model and your tools. It tells the model what actions it can perform, handles the actual execution when the model requests an action, and returns the result. Think of it as the bridge between "the AI that thinks" and "the systems that act".

Is MCP the same as OpenAI's function calling or tool use?

No — though they are related concepts. Function calling and tool use are mechanisms *inside* a single API conversation. MCP is a *transport protocol* for connecting AI clients to external tool servers. You can implement MCP tool calls using function calling under the hood, but MCP adds capability discovery, session management, and a standardised server contract that function calling alone does not provide.

Does an MCP server work with models other than Claude?

Yes. The protocol is model-agnostic. OpenAI, Google, and open-source model providers have all shipped or announced MCP support. A server you build today will work with whichever model your team uses tomorrow.

How is an MCP server different from a plugin or integration?

Plugins (as in ChatGPT plugins from 2023) were proprietary and model-specific. MCP is an open standard, so the same server works across clients and models. Integrations in the Zapier/Make sense are trigger-action connectors designed for human-configured workflows; MCP servers are designed for *autonomous AI-driven* workflows where the model decides what to call and when.

Is it safe to give an AI agent access to production systems via MCP?

With the right controls, yes. The key safeguards are: credential vaulting (no raw secrets in the model context), scoped permissions (least-privilege access per agent role), audit logging, and human-in-the-loop approval for destructive or high-impact actions. Our agentic AI overview covers the broader safety considerations in depth.

---

Ready to connect your tools to AI?

MCP is fast becoming the default wiring standard for enterprise AI — the way REST became the default for web APIs in the 2010s. The teams moving earliest are compressing weeks of manual work into minutes, with full audit trails and governance controls.

If you want to see what a production-grade MCP deployment looks like for your team, try the OpenHelm web platform free, or book a 20-minute walkthrough and we will show you exactly how it fits your stack.