# How to Ship an Official MCP Server for Your SaaS in 2 Weeks

> A practical 2-week plan to build an official MCP server on your existing API: tool spec, OAuth and scopes, testing in Claude/ChatGPT/Cursor, docs and handover.

*2026-10-11T11:43:43Z*

Your customers are starting to ask a new question in sales calls and support tickets: *"Does it work with Claude?"* Sometimes it is ChatGPT or Cursor instead, but the request is the same. They want to ask their AI assistant to do real work inside your product, without copying data between tabs.

The standard way to make that happen is an **MCP server**. The Model Context Protocol is the open protocol AI assistants use to discover and call tools in other products. If you already have a decent API, an official MCP server is a small, well-bounded project. Here is how I plan and ship one in about two weeks, and what to decide before anyone writes code.

## What an MCP server actually is (for a SaaS team)

An MCP server is a thin layer that sits **beside** your product and talks to your existing API. It exposes a short list of *tools*, each with a name, a plain-language description and a typed input schema. The assistant reads those descriptions, decides which tool fits the user's request, and calls it.

Three things follow from that:

- **Your backend doesn't change.** The server is a client of your API, like your web app is.
- **Your language doesn't matter.** I usually build in TypeScript or Go, or PHP for Laravel products, whatever your team can maintain.
- **Tool design matters more than code volume.** Most of the work is deciding what the assistant should be able to do, and describing it so the model picks the right tool.

There are two common ways to run one: **remote** (a hosted HTTP endpoint your cloud customers connect to with OAuth) and **local** (a package the user runs on their machine, which suits self-hosted installs). Many SaaS products start with remote.

## Why "official" matters

If you don't ship one, someone else might. Community MCP servers for popular products appear quickly, and they usually ask users to paste a full-access API key into a config file. Your customers then run unvetted code with their production credentials, and you get the support tickets.

An official server lets you control three things: which actions are exposed, how authentication works, and how your product is described to the assistant.

## The 2-week plan

Two weeks is realistic when the API exists and is documented, and the first version focuses on the 10–20 actions people actually ask for. Here is the sequence I use.

### Step 0: a one-page tool spec (before any commitment)

Before building, I read your API docs and write a one-page spec. It lists the proposed tools, what each one does, its inputs, whether it reads or writes, and which auth scope it needs. I offer this for free, because it is the cheapest way for both sides to see whether the project makes sense.

A good spec answers:

- What are the five things a user will ask the assistant to do on day one?
- Which of those are read-only and which change data?
- Which actions are destructive or expensive and need a clear warning?
- What does the assistant need to *find* things (search, filters, IDs)?

### Days 1–3: tool design and scaffolding

Turn the spec into tool definitions. Keep the list short and the names obvious. **Don't mirror every endpoint.** An assistant does better with `find_customer` and `create_invoice` than with forty CRUD endpoints that differ by one field.

Write the descriptions as instructions to the model: when to use the tool, what it returns, and what *not* to use it for. In my experience this is the work that most changes how well the server performs.

On my own servers, tools live in a **registry**: one list the protocol layer reads. Adding a tool later means adding one entry, not touching the transport or auth plumbing. That is how the MCP surface on fadymondy.com's issue tracker is built, and it keeps the server easy to grow after handover.

### Days 4–7: authentication and permissions

This is where an official server earns its name.

- **OAuth for remote servers.** The MCP authorization spec is built on OAuth 2.1. On [Zekra](https://zekra.dev/en/docs/mcp)'s remote MCP endpoint I implemented the full flow: PKCE (S256), dynamic client registration and per-brain consent, with access re-checked against current membership on every call.
- **Scoped API keys as a fallback.** In [Moharrik](https://moharrik.com), keys are read-only by default and expire after 90 days.
- **Read and write separated.** Mark read-only tools as read-only (MCP tool annotations support `readOnlyHint` and `destructiveHint`). On Zekra, adding read-only annotations let AI coding agents and other MCP clients run recall and list tools without an approval prompt, while writes still ask.
- **Make agent actions traceable.** When an assistant writes data, record that it was an agent. On my issue tracker, comments created over MCP are stored with `author_kind = 'agent'`, so a human can always tell them apart.

### Days 8–10: test against real assistants

Unit tests aren't enough. Connect the server to Claude, ChatGPT and Cursor and run the prompts from the spec. Watch for:

- the assistant picking the wrong tool (fix the description, not the model);
- tools returning too much data (paginate and trim; context is not free);
- vague errors (return messages the assistant can act on, like "customer not found, try search_customers").

### Days 11–14: docs, listing and handover

- **Setup guides** for each assistant: one page each, with the exact config.
- **A permissions page** that explains in plain language what each scope allows. In Moharrik this explainer is generated from the tool registry, so it can't drift from the code.
- **Listings** in the main MCP directories, so users can find the official server.
- **Handover.** The repository, deployment notes and a short walkthrough. The code ships under your name and licence.

## What stretches past two weeks

Be honest about scope up front. These usually add time:

- no public API yet, or an API that can't do what users ask;
- complex multi-tenant permissions that aren't modelled in the API;
- long-running jobs that need progress reporting or webhooks;
- a self-hosted package *and* a remote endpoint in the first release.

None of them blocks a project. They belong in the spec so the plan and the price stay fixed.

## Checklist before you start

- [ ] Your API is documented and stable enough to build against.
- [ ] You have listed the top 5 user requests the assistant should handle.
- [ ] You know which actions must never run without a confirmation.
- [ ] You have decided on remote, local or both.
- [ ] Someone on your team will own the server after handover.

## Proof, not promises

I build MCP servers for my own products, and they run in production:

- **[Orchestra MCP](/en/projects/orchestra-mcp)**: an AI-agentic IDE framework with a plugin-host architecture.
- **[Zekra](/en/projects/cabrain)**: shared memory for AI agents, served over a remote MCP endpoint with OAuth 2.1.
- **[Moharrik](https://moharrik.com)**: a CRM with inbox and WhatsApp that is fully operable over MCP.
- **[Nasaq UI](https://mcp.nasaqui.com)**: an open-source design system with its own MCP server.

If you want the same for your product, see [MCP server development](/en/services/mcp-server-development). The process starts with the free one-page tool spec. If you run a Laravel or Filament product and need more than the MCP layer, there is also [white-label Laravel and Filament development](/en/services/white-label-laravel-filament).

[Ask for your free tool spec](/en/contact).

---

Source: https://fadymondy.com/en/blog/ship-official-mcp-server-for-saas-in-2-weeks