Originally published at fadymondy.com. 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.
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:
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.
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.
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.
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. It is the cheapest way for both sides to see whether the project makes sense.
A good spec answers:
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. It keeps the server easy to grow after handover.
This is where an official server earns its name.
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.author_kind = 'agent', so a human can always tell them apart.
Unit tests aren't enough. Connect the server to Claude, ChatGPT and Cursor and run the prompts from the spec. Watch for:
Be honest about scope up front. These usually add time:
None of them blocks a project. They belong in the spec so the plan and the price stay fixed.
I build MCP servers for my own products, and they run in production:
If you want the same for your product, see MCP server development. The process starts with a free one-page tool spec.