How to Add an MCP Server to Your SaaS: A Practical Guide (2026)

An MCP server lets people use your product from inside Claude, ChatGPT and other AI assistants. If your SaaS already has a documented REST API, you don't need new endpoints. An MCP server sits on top of the API, describes a handful of actions as "tools" the assistant can call, and handles sign-in. The work is mostly in choosing the right tools and describing them well.

Simon built and runs the MCP server for Workspace369, App369's own SaaS. This guide is the checklist App369 follows for its fixed-price MCP Connector.

What MCP is

The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, for connecting AI applications to outside tools and data. A server exposes three kinds of things:

• Tools: actions the model can call, such as "create an invoice" or "search clients".
• Resources: data the client can read into context, such as a document or a record.
• Prompts: reusable templates a user can pick.

For a SaaS integration, tools do most of the work. Each tool has a name, a plain-language description and a JSON schema for its inputs. The assistant reads the descriptions and decides when to call which tool.

Local or remote

MCP servers talk to clients over one of two transports:

• stdio: the server runs as a local process on the user's machine. This suits developer tools, but asks every user to install something.
• Streamable HTTP: the server runs on the web at a URL. This is what a SaaS wants: users add your connector by URL and sign in, with nothing to install.

Build a remote server over Streamable HTTP unless you have a reason not to.

Step 1: Pick 5 to 10 tools

Don't mirror your whole API. Pick the jobs people would actually ask an assistant to do, and make each one a tool:

• Read tools first. "Find a client", "list overdue invoices", "show this project's tasks". They are safe, and they are what people try first.
• A few write tools. "Create a draft invoice", "add a note". Prefer creating drafts over sending or deleting, so a person confirms the final step in your app.
• No destructive tools at first. Deleting, refunding or emailing customers from a chat is where mistakes get expensive.

Step 2: Write descriptions for the model

The model only knows what your descriptions tell it. For each tool:

• Say what it does and when to use it, in one or two sentences.
• Name every input in plain words, with formats ("ISO date, e.g. 2026-10-12") and allowed values.
• Return compact, labelled JSON. Strip internal IDs and fields the user would never ask about, and paginate long lists.
• Return errors as readable messages ("No client named 'Acme'. Try search_clients first."), so the model can recover.

A minimal tool with the official TypeScript SDK looks like this:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

const server = new McpServer({ name: 'your-saas', version: '1.0.0' });

server.tool(
  'list_overdue_invoices',
  'List invoices that are past their due date, newest first. Use when the user asks who owes them money.',
  { limit: z.number().int().min(1).max(50).default(10) },
  async ({ limit }) => {
    const invoices = await api.get('/invoices', { status: 'overdue', limit });
    return { content: [{ type: 'text', text: JSON.stringify(invoices) }] };
  },
);

The api client is your existing REST client, called with the signed-in user's credentials.

Step 3: Decide how users sign in

There are two common options:

• API key or personal access token. The user pastes a key from your settings page. It is the fastest to build and fine for technical users and internal teams.
• OAuth. The user clicks "Connect", signs in to your product and approves access, with no keys to copy. The MCP specification defines authorization for HTTP transports based on OAuth 2.1. It takes longer to build, but it is what non-technical users expect, and directories tend to favour it.

Either way, every tool call must run as the signed-in user, with that user's permissions. Never give the MCP server one shared admin key.

Step 4: Host it next to your API

A remote MCP server is a small web service. Cloud Run, Cloudflare Workers and Vercel all work well; pick whatever already hosts your API, so logs, secrets and billing stay in one place. Keep API keys and OAuth client secrets in your platform's secret manager, not in environment files committed to git.

Step 5: Test in real clients

1. Use the MCP Inspector to call each tool directly and check its schema and output.
2. Add the server as a custom connector in Claude and in ChatGPT, and ask ordinary questions ("who owes me money this month?"). Watch which tools the model picks, and rewrite descriptions where it picks wrong.
3. Test a user without permission to a record, and a user from another account. They must get errors, not data.

Step 6: Submit to directories

Anthropic and OpenAI both list third-party connectors, and both review submissions. Prepare listing copy, screenshots, a privacy policy that covers the connector, and a test account for the reviewers. Approval is up to each directory, so plan your launch around your own users first: a "Connect to Claude" page in your help center works on day one.

What it costs

Built in-house, expect one to three weeks for an engineer who already knows your API, depending mostly on authentication and how many tools you start with. App369 builds it as a fixed-price MCP Connector: $2,500 for up to 8 tools over your existing documented API with API-key or token auth, deployed to your own cloud account and tested in Claude and ChatGPT, with a directory-submission packet. OAuth sign-in is a $1,000 add-on. For broader AI work, see AI integration services.

Frequently Asked Questions

Do I need to build new API endpoints for an MCP server?

No. If your REST API is documented and already supports the actions you want, the MCP server calls those endpoints on behalf of the signed-in user. New endpoints are only needed when an action people want doesn't exist in your API yet.

Does one MCP server work in both Claude and ChatGPT?

Yes. MCP is a shared protocol, so one remote server can be added as a connector in both. Test in each client, because they can choose and display tool calls differently.

Should I use OAuth or API keys for my MCP connector?

Start with API keys or personal access tokens if your users are technical or internal. Use OAuth if non-technical customers will connect it themselves or you plan to list it in public directories. Either way, each call must run with the signed-in user's own permissions.

Is it safe to let an AI assistant write data in my app?

It can be, if you limit what tools can do. Start with read tools, make write tools create drafts rather than send or delete, run every call with the user's own permissions, and log tool calls so you can see what happened.

How many tools should an MCP server have?

Start with 5 to 10 that cover the questions users actually ask. Too many similar tools make the model pick the wrong one. Add more once you have seen real usage.