What is the Model Context Protocol (MCP)? A guide for SaaS teams

The Model Context Protocol (MCP) is, in its own documentation's words, "an open-source standard for connecting AI applications to external systems." The documentation compares it to a USB-C port: one standard plug instead of a different cable for every device. For a SaaS company, that means one integration that works in every AI assistant that supports the standard, instead of a separate one for each. This guide explains what MCP is, how it works, what a server offers, and what it means for your product, from the specification itself.

Where MCP came from

Anthropic introduced MCP on November 25, 2024, naming the problem it set out to solve: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale." It launched with three parts: the specification and SDKs, support for local MCP servers in the Claude desktop apps, and an open-source repository of servers.

Since then the specification has been published in dated revisions; the current one is 2026-07-28. Its documentation names Claude, ChatGPT, Visual Studio Code and Cursor among the applications that support it.

How it works: hosts, clients and servers

The specification defines three roles:

• Host: the AI application the person uses, such as Claude or ChatGPT. It starts the connections.
• Client: the connector inside the host that talks to one server.
• Server: the service that provides context and capabilities. For a SaaS company, this is the part you build.

They exchange JSON-RPC 2.0 messages over one of two standard transports:

• stdio: the host starts the server as a process on the user's machine and talks to it through standard input and output. This suits local tools.
• Streamable HTTP: the server is a web endpoint, and each message is an HTTP POST. This is the one a SaaS product uses, because the server runs on your infrastructure and every user reaches the same URL.

In the 2026-07-28 revision, every request is self-contained: it carries its own protocol version and capabilities, instead of relying on a session set up at the start. The specification says it takes some inspiration from the Language Server Protocol, which standardized how code editors support programming languages.

What a server offers

A server can offer three kinds of features:

• Tools: functions the model can call, such as "create an invoice" or "search tickets". Each tool has a name, a description written for the model, an input schema and optional hints such as readOnlyHint. Tools are what most SaaS servers are about.
• Resources: context and data that the user or the model can read, such as a file or a record.
• Prompts: templated messages and workflows that a user can pick.

A client can also offer features back. The main one is elicitation: the server asks the user for missing information through the host, instead of guessing. On top of the core, optional extensions add more. MCP Apps, for example, let a server show interactive interface elements, such as charts and forms, inside the conversation.

An example: our own server

We run an MCP server over our Platform Requirements dataset at mcp.invokary.com. It is open source, published in the Official MCP Registry and listed in Claude's Connectors Directory. It offers six read-only tools, such as get_platform_requirements and search_requirements. If you connect it in an assistant and ask "what does ChatGPT need before it lists a plugin?", the model reads the tool descriptions, decides that get_platform_requirements fits, calls it with platform: "chatgpt", and answers from the result, with sources and check dates.

You don't write any code for that conversation to happen. The model picks the tool from its name and description, which is why those two fields matter more in MCP than in a normal API.

MCP and your API

An API is built for developers, who read the documentation and write code against it. An MCP server is built for a model, which reads each tool's description and decides at runtime whether and how to call it. Most SaaS MCP servers sit in front of the product's existing API, but they rarely mirror it endpoint by endpoint. Our guide to MCP vs API explains what changes, and MCP server best practices covers how to design the tools.

Safety is part of the protocol

The specification is direct about the risk: MCP "enables powerful capabilities through arbitrary data access and code execution paths." Its principles:

• Consent: users must explicitly agree to the data access and the actions, and stay in control of them.
• Data privacy: the host must get the user's consent before it exposes their data to a server.
• Tool safety: tools are treated as code execution. The host must get the user's consent before it calls a tool, and it treats a tool's own description of its behavior as untrusted unless the server is trusted.

For a SaaS server, that means real sign-in for each user (usually OAuth), permissions no wider than the user's own, and honest descriptions and hints. Our guide to MCP connector security covers the threats in detail.

What MCP means for a SaaS product

One MCP server can serve many assistants, but being usable isn't the same as being found. Each assistant has its own directory, with its own review:

• Claude has the Claude Connectors Directory.
• ChatGPT has the ChatGPT Plugins Directory. Our ChatGPT app submission guide walks through it.
• Cursor has the Cursor Marketplace.
• The Official MCP Registry lists public MCP servers for any client to find.

What each directory requires, with sources and check dates, is side by side on our requirements comparison. Before you submit anywhere, test the server the way a reviewer will. The terms used on this page are defined in our glossary.

Where we come in

Building the server, getting it through each directory's review, and keeping it working as the specification changes is what we do. A Connector Launch Sprint builds and lists it. The Agent Distribution Audit starts with where your product stands today.