MCP Server Examples for SaaS Companies: What to Copy

What is an MCP server? It is a small program that sits in front of a product and tells AI agents what they can do there. MCP, the Model Context Protocol, is an open standard for connecting AI applications to external systems. A server publishes a list of tools, each with a name, a description, and an input schema, and an agent like Claude or ChatGPT reads the list and calls the ones it needs. That is what an MCP server is for AI agents: the door into your software.

Most roundups of MCP server examples are written for the developer wiring servers into an editor. This one is for the company on the other side, the SaaS vendor deciding what its own server should contain. Below are eight real servers, each built by the company that owns the product, with what each one exposes and why the design is worth studying. After that comes the part the lists skip: what belongs in your tool list, and what belongs behind a service you run.

Eight MCP server examples, and what each one exposes

I picked servers where the vendor made a design decision you can see from the outside. Everything below comes from their public docs as I read them in September 2026.

• GitHub. GitHub's server groups its tools into toolsets such as repos, issues, pull_requests, and actions. Five toolsets are on by default, and a --read-only flag removes every write tool. Lesson: a large surface should be opt-in, one group at a time.
• Stripe. Stripe's server skips the tool-per-endpoint approach. It ships stripe_api_search, stripe_api_details, stripe_api_read, and stripe_api_write, plus documentation search, and certain writes such as refunds wait for a human to confirm. Lesson: split reads from writes, and put a person in front of money.
• Linear. Linear's hosted server has tools for finding, creating, and updating issues, projects, and comments. It also runs a second endpoint that only ever exposes read tools. Lesson: make read-only a first-class way to connect.
• Notion. Notion's tools are named for what a person does in a workspace: notion-search, notion-fetch, notion-create-pages, notion-update-page. The agent connects as one user, and results include only what that user can read. Lesson: the agent inherits the user's permissions, nothing more.
• Figma. Figma's server is built around one job, turning a design into code. Its default entry point, get_design_context, returns a selection as React and Tailwind unless you ask for something else. Lesson: shape the output for the work the agent is about to do.
• Cloudflare. Cloudflare's API server covers over 2,500 endpoints with two tools, search() and execute(). The agent writes code against the API spec, which Cloudflare says costs about 1,000 tokens against more than a million for a tool per endpoint. Lesson: a huge API needs a different pattern, not a longer list.
• Sentry. Sentry's server searches errors, triages issues, and reads documentation. Its README says it is "primarily designed for human-in-the-loop coding agents," not as a general-purpose server for all Sentry functionality. Lesson: choose the caller you are building for.
• HubSpot. HubSpot's remote server gives read and write access to CRM objects and engagements, and read-only access to organizational and marketing data. What an agent can reach is set by the scopes on a user-level app. Lesson: reads can be wider than writes.

The best examples do not mirror the API

Read that list again and look at what the vendors with the largest APIs did. Stripe and Cloudflare put a large API behind a handful of tools. GitHub keeps most of its surface switched off until you ask for it. Sentry says in writing that its server does not cover the whole product. None of the four handed the agent one tool per endpoint and called it done.

There is a measured reason for that. Anthropic's documentation says Claude's ability to pick the right tool degrades once you exceed 30 to 50 available tools, and that a typical multi-server setup can spend about 55,000 tokens on tool definitions before any work starts. Your server is rarely the only one connected. I went through the numbers in why too many MCP tools makes your agent worse, so I will not repeat them here.

Mirroring the API is still the sensible first move. You already have an OpenAPI spec, the generators exist, and a one-to-one server ships fast. The trouble is who reads it. A REST API is written for a developer who reads the docs once and writes code that runs for years. A tool list is read by a model on every request, on behalf of a customer who asked for one thing to be done.

So the examples worth copying start from that customer. Figma did not expose its file format. It exposed "give me this design in a form I can build from." Sentry picked debugging, and Notion named its tools after things a person does in a workspace. Even Cloudflare's two-tool pattern, which I covered in Code Mode explained for product teams, is a decision about the caller: a developer's agent that can write code.

How to build an MCP server is the easy question

The mechanics are solved. The official tutorial walks through a weather server with two tools, get_alerts and get_forecast, in eight languages. If your team can ship an API endpoint, it can ship a server. For an MCP server for SaaS, the hard question is what goes in it and who it acts as.

The rule I would start from is short: reads broadly, writes narrowly, and only as the signed-in customer. The examples above already point this way. Linear has an endpoint that can only read. GitHub has a flag that removes every write. HubSpot reads more than it writes, and Stripe holds a refund until a person approves it.

Reads are where an agent earns trust. Search, list, and get tools let it answer a customer's question about their own account, and the more it can see, the better the answer. Writes deserve a smaller set: additive, reversible, scoped to the caller's own account. Every call should run as the person who connected, with their permissions, never through a shared service account that can see everyone. I made the full case, including the prompt injection incidents that make this more than caution, in what to expose to your customers' AI agents.

Workflow automation does not belong in the tool list

This is where most of the interest in MCP server workflow automation ends up. The MCP server business use cases people describe are rarely "call this endpoint." They are outcomes: the weekly report, the account audit, the monitor that acts when something drifts. The tempting move is to let the agent chain twenty primitives to get there, or to add one giant run_weekly_audit tool.

Chaining does work in a demo. It also works for a developer in an editor who approves each step. It stops working when nobody is watching, because an outcome needs things a tool schema cannot carry: a schedule, a scope fixed for that customer, a limit on what may change, an approval rule for the risky step, and a run log someone can read afterwards. A tool is stateless, and a model decides when to call it. A service is a named job the vendor defines once and then runs.

Here is what that looks like for an inventory product. The names and numbers are made up to show the shape.

Mon 06:00  Weekly reorder audit, Northwind Supply (runs as their admin)
06:00  list_products          412 SKUs
06:01  list_reorder_rules     9 reorder points below last month's weekly sales
06:01  update_reorder_rule    raised 7, each within the limit this job allows
06:01  held for approval      2 changes above the limit
06:02  send_summary           emailed to the account owner

Every line is a tool your MCP server already has. The reads are broad and the writes are narrow, same as above. What moved is the decision. You decided once which tools this job may touch, how far a change may go, and what waits for a person, so the model is not deciding that at six on a Monday morning. The customer's choice gets simpler too: they are no longer picking among forty tools, only saying whether they want this job done.

That is also where the business sits. Transport keeps getting cheaper, which is the argument in MCP vs CLI vs code mode. A tool list anyone can reach is the baseline. An outcome you are willing to put your name on is something a customer can ask for, rely on, and pay for.

Where Aimdoc sits

This is the layer we build at Aimdoc, the customer agent platform for B2B SaaS. You connect your product's MCP, and Aimdoc works through the tools it already exposes. It authenticates as each customer, so every call runs as that user, with their permissions, in their account. Then the customer agent and every service do real work in your app, on your website, and over email, with a task definition teaching the browser path where a tool is missing. A service is the job in the log above: a named outcome, configured to each customer, run through the same MCP on a schedule or on an event, and kept running.

Two honest limits. The work is only as good as the tools your MCP exposes, so the choices in this post are still yours to make. And a customer's own outside agent calling a service directly is next, not now. The details are on the services page, and signup is self-serve if you want to try it against your own MCP.