What is an MCP server? A SaaS founder's guide to whether you need one

What is an MCP server?

An MCP server is a service that describes what your product can do in a form AI assistants understand, so a signed-in customer can ask Claude, ChatGPT or GitHub Copilot to work with their own data in your product. It speaks the Model Context Protocol (MCP), an open standard for connecting AI applications to outside tools and data. Your API still does the work; the server sits in front of it, signs people in and tells the assistant which actions exist.

For a help desk product, that means a customer can ask the assistant they already pay for to summarize this week's escalated tickets, and the answer comes from your product, with that customer's permissions.

Anthropic introduced MCP in November 2024 and in December 2025 donated it to the Agentic AI Foundation, a Linux Foundation fund co-founded with Block and OpenAI. As of October 2026 the current revision is 2026-07-28, the protocol's fifth dated revision. This guide covers the decision before any build; our MCP server development service covers the build.

How a request moves through an MCP server

Three parts are involved: the host is the AI application your customer uses, a client inside it keeps one connection to one server, and the server is yours. By design, a server doesn't read the whole conversation or see into other servers: you receive tool calls and their arguments, not the chat around them.

From the customer's side:

1. They add your server to their assistant, by URL or from a directory, and sign in with their account in your product.
2. The assistant asks your server for its tools and reads each one's name and description.
3. They ask a question, and the model picks a tool and its arguments.
4. Depending on the client and the tool, the assistant asks them to confirm the call.
5. Your server checks the token and that tool's permission, calls your API and returns a short result.
6. The model writes the answer, or calls another tool.

Step 3 surprises most product teams: the model chooses tools from their names and descriptions, so that text is product copy read by a model. Review it like interface text and test it with real requests.

Tools, resources and prompts

An MCP server can offer three kinds of things, and the specification separates them by who decides when they're used:

Start with tools: they're what customers notice, and client support for resources and prompts varies.

Where customers would use it, and how they'd find it

The assistants your customers already use connect to remote MCP servers, hosted on the internet rather than installed by each user; Anthropic's foundation announcement lists ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code among the products that support MCP. As documented in October 2026, they differ in how a customer adds your server and what a public listing asks of you:

Two review rules shape the product itself. Anthropic's connector review criteria reject a catch-all tool that both reads and writes, such as an api_request tool with a method parameter, and the Claude directory doesn't accept connectors that transfer money. OpenAI's review requirements ask that tools return only what the request strictly needs. If your product moves money, plan on a server customers connect by URL, with a confirmation before every payment.

Do your customers actually want one?

A server nobody connects is upkeep with no return, so check first:

• Count the asks. Search 90 days of support tickets, sales notes and community threads for ChatGPT, Claude, Copilot, Cursor and MCP. A request that names a job, such as "can Claude read our tickets?", tells you more than one that names the protocol.
• Search the registry for your product's name. The MCP Registry lists public servers under namespaces their publishers verified. On 14 October 2026, a name search for Zendesk returned six servers and for HubSpot seven, none under a namespace either company controls; Stripe returned fifteen, including Stripe's own com.stripe/mcp. The registry isn't complete, so a missing entry proves nothing, but third-party servers for your API are visible demand, and some customers may already be giving their API keys to a server you can't vouch for.
• Check your category in the directories. If competitors are listed in Claude's or ChatGPT's directory and you aren't, expect it in sales calls.

Then run the cheapest real test: a read-only server with three or four tools, offered to a few design partners. For a month, watch how many connect it and how many come back after the first try. If nobody returns, you've learned it before building writes, listings and support.

To get AI assistants to recommend your company, a server won't help: no assistant documents finding a site's tools on its own, as our agent-ready website notes record, and our guide to appearing in AI answers covers what does. For AI that runs a process inside your own company, see AI automation.

What to expose first

Pick three to five jobs your customers already do in your product and would hand to an assistant, and give each its own tool, reads before writes. For a hypothetical help desk product:

Three rules make the table work:

• Return less than your API does. Full threads, internal notes and every custom field fill the model's context with data the question didn't need. Return summaries and IDs; let get_ticket fetch the rest.
• Label every tool honestly. Tool annotations tell clients whether a tool only reads or may destroy something. By the protocol's defaults, an unlabeled tool is assumed destructive, and Claude's review criteria say read-only tools can run without asking each time while destructive ones always prompt. Accurate labels mean fewer interruptions for reads.
• Make drafts the default write. A draft the customer approves in your product gives the assistant useful work without the last word.

Sign-in is a product decision

With OAuth, each person signs in with their own account and the assistant gets only what they approve. MCP's authorization rules handle the mechanics; the product questions are yours:

• Which workspace a connection reaches. Many SaaS users belong to several. Decide whether one connection covers one workspace or all, and say which on the consent screen.
• What the scopes are called. An admin can approve tickets:read and drafts:write; a request for full access gets turned down. MCP's security best practices list wildcard scopes and advertising every possible scope as common mistakes.
• How an admin sees and revokes it. List connected assistants in your settings next to API keys, with a last-used date and a revoke button.
• How teams share it. On Claude's Team and Enterprise plans, an owner adds the connector and each member connects with their own account; one shared credential gives every member its access. Shared keys suit internal tools, not customer data.

The security risks that come with it

The model calling your tools can be talked into things. OWASP ranks prompt injection first among LLM application risks, including the indirect kind, where instructions arrive inside content the model reads: a support ticket, a shared document, a web page. Your customers' own data can carry it. Anthropic's help page on custom connectors also warns that malicious servers can hide instructions, and that Claude's Research mode can call connector tools without further approval.

Simon Willison's lethal trifecta is the most useful test we know: private data, untrusted content and a way to send data out. An assistant with all three can be steered into leaking data, and he argues no guardrail reliably prevents it. A help desk server has the first two by nature, since tickets are private and written by outsiders. So ask of every write tool whether it adds the third: could send_reply email one customer's data to an address planted in another ticket?

Three questions for every tool before it ships:

1. Can any text it returns have been written by someone other than the signed-in user?
2. Can it send data outside the account, or fetch an address it's given?
3. If a manipulated model called it with the worst valid arguments, what could happen within its permission?

Where tools that answer yes to the first two can meet in one conversation, split their scopes, require confirmation or drop one. Two rules from the MCP specification aren't optional: accept only tokens issued for your server, and never pass a customer's token through to another API. The model's judgment is never your access control.

What it costs to build and keep

The server itself is rarely the big cost; the estimate grows with everything around trust:

• An API that isn't ready: missing endpoints, no per-user permissions, no rate limits. Without one, the first project is web app development.
• OAuth, if your product doesn't already run sign-in with consent screens and scopes.
• Each write tool, with its scope, confirmation and audit trail.
• Each client and directory you promise, with test accounts, privacy policy updates and review rounds.
• Interactive views inside the chat (MCP Apps), if text isn't enough.

Then the upkeep. Five dated revisions in under two years show the protocol moves; the latest dropped the opening handshake earlier servers rely on. Deprecated features normally stay at least twelve months before removal, which makes upgrades plannable, not optional. Treat the server like any public API, with a version policy, monitoring and a named owner. Our pricing page explains how we scope this work.

What running our CMS through MCP taught us

The CMS behind dardo.studio, EmDash, has a built-in MCP server that accepts OAuth or personal access tokens. Our agents work through it: they create article drafts, upload images, link each article to its services and read every draft back before anything goes live. This article reached the CMS that way. Four things we'd carry into a customer-facing server:

• A long tool list suits your own agents, not your customers. An internal server can expose dozens of tools; for customers, ship a small set, since near-identical choices make the model's pick less reliable.
• Label every tool. Tools without a read-only or destructive hint are treated as possibly destructive, which is safe but means more confirmations, and directory reviews ask for a hint on each.
• Expect version gaps. Servers and clients move to new protocol revisions at different speeds; test against the revisions your customers' clients actually use.
• Ask for the fewest scopes by default. A consent page that lets the person clear scopes works for a small team; a product with thousands of customers should request less up front.

Two lessons came from use. The CMS's Markdown import flattens tables into plain lines, so our agents send tables in its structured format and check the result with a read tool: give agents a way to verify their own work. And the rules that matter live in the server: the CMS refuses to publish an article without an excerpt, a cover image with alt text and alt text on every image, whatever an agent was told. Our public server on dardo.studio, two read-only tools with no sign-in, is described in our agent-ready website notes.

Should you build one now?

Build a small, read-only server now if customers ask to use your product from an assistant, your API already enforces per-user permissions, and the registry or the directories confirm the demand. If your API isn't ready or nobody has asked, fix the API first and run the design-partner test when someone does.

When you're ready, our MCP server development service starts from your API and the jobs your customers ask for. Send us both and we'll tell you whether a server is worth building yet.