How We Build an MCP Server for a SaaS Product
An MCP server is a small amount of code and a large amount of design. Most of the two to four weeks goes on deciding what to expose and how to describe it so an agent picks the right tool every time. This is how we do it.
- Published
Steps 1–4 — design the tool surface
- List the ten things a customer most often does in the product. Not endpoints — jobs. "Create an invoice for a customer", "find overdue accounts", "reschedule a delivery".
- Turn each job into one tool with a verb_noun name and the smallest input that gets it done. Ten to twenty tools is the sweet spot; a tool per REST route is the classic mistake.
- Separate read tools from write tools, and mark anything destructive so the host can require confirmation.
- Write each description for a model: what the tool does, when to use it instead of its neighbours, one example call. Then test the descriptions by giving an agent five tasks and watching which tools it reaches for.
| API endpoints | MCP tool | Why |
|---|---|---|
| POST /customers, POST /invoices, POST /invoice_lines | create_invoice(customer, lines) | One job, one call |
| GET /invoices?status=…&due<… | find_overdue_invoices(days) | Model-shaped input |
| DELETE /invoices/{id} | void_invoice(id) — destructive | Host asks for confirmation |
Steps 5–7 — build and secure it
- Implement as a remote (HTTP) server using the official MCP SDK for your language, on top of the existing API — the server should be thin.
- Auth per connection, scoped to what that user could do in the UI. Never a shared admin token. Rate-limit per connection; log every call with arguments.
- Security pass: treat every input as hostile, validate strictly, and run prompt-injection scenarios where a tool result tries to instruct the agent. The server must never be the path by which an agent is tricked into a destructive action.
Steps 8–9 — evaluate and hand over
- Eval: an agent runs 50+ real customer tasks through the server. Grade on correct tool, correct arguments, correct result. Fix descriptions first when it fails — that is usually the cause.
- Handover: the server in your repo, a test harness, a README written for the registries and app directories your customers use, and a one-hour session for your team.
Two to four weeks from kickoff to a server your customers’ AI tools can use. We build them for SaaS products and internal platforms, and run a one-day MCP design workshop for teams building their own.
Frequently asked questions
Local or remote server?
Remote for anything customers use — central auth, versioning and rate limits. Local for developer tooling that runs beside a codebase.
How do we version tools without breaking agents?
Add tools, never change a tool’s meaning. Deprecate with a description note, remove after a notice period. Keep the eval running against every version.
What about resources and prompts, not just tools?
Resources (read-only data) are worth exposing for documents and records; prompts are optional. Start with tools — that is what drives usage.
