What should you expose when you build an MCP server on your own SaaS?

Expose questions, not endpoints. The catalog of an MCP server for your SaaS should be a short list of read-only tools, each answering one question an outside agent really asks, plus a few resources for stable reference material. Leave out anything that writes, anything that returns more than the question needs, and anything you cannot describe in one sentence.

Most teams start the other way: they take the API reference and wrap every endpoint. That produces a server in an afternoon and a catalog nobody chose. This article is about the choosing.

What the catalog is, and why it is the design

Catalog: the list of tools and resources an MCP server declares to a client, with a name and a description for each. It is everything the agent knows about what the server can do.

The protocol itself is covered in what an MCP server is, in plain language, and the change that comes when a program is the caller in asking your codebase questions via an API. Here we only look at the list.

The list matters because the agent reads it to decide what to call. Names and descriptions are the whole interface. Every entry is a surface you maintain, a surface you secure, and one more option the agent can pick wrongly. A catalog of forty tools does not make the agent more capable. It makes the choice harder, and every wrong choice looks like a product bug.

Tools and resources: which goes where

An MCP tool is something the agent calls with arguments, and the answer can depend on them. A resource is a piece of content with an address that the client can read. Both are in the protocol; the difference is in what you put behind them.

A practical rule: if the answer is the same for everyone and changes slowly (the plan limits, the list of webhook events, the authentication scheme), it is a resource. If the answer depends on the question (what changed since a date, what this error code means), it is a tool.

Three questions, applied to a catalog

Run every candidate through the same three questions. If one answer is no, the candidate is out of v1.

1. Does an outside agent actually ask this? Source it from your support inbox and your integrators' questions, not from the API reference.
2. Can it be answered without changing anything?
3. Does the answer reveal no more than the question needs?

To see them work, take an appointment-booking SaaS. It is invented for this article, as is every name below. Its team lists eight candidates.

• get_plan_limits: yes, read-only, nothing sensitive. Keep, as a resource.
• what_changed_since(date): asked weekly by support and integrators, read-only, answers about the product. Keep, as a tool.
• list_available_slots: asked constantly, read-only, and a slot is not personal data. Keep, with a date range as a required argument so it cannot return everything.
• list_webhook_events: stable reference, read-only. Keep, as a resource.
• get_booking(id): asked, read-only, but the answer holds a customer's name and phone number. It fails the third question unless the server knows who is asking. Leave out until identity is settled.
• cancel_booking: fails the second question by definition. Leave out of v1.
• export_all_customers: fails the third, loudly. Leave out.
• run_query(sql): fails all three. It is not a tool, it is a back door with a description.

Eight candidates, four kept. Do not read the ratio as a benchmark: the example is invented. Read it as the shape. Much of what an API can do is not what an agent should be handed.

Writes: a separate decision, taken later

A write tool changes the rules. The agent can be wrong, or be misled by text it read elsewhere, and the consequence is no longer a bad answer but a changed record. The protocol lets a tool declare itself read-only or destructive, but those flags are hints for the client, not enforcement. The enforcement has to live in your server: scopes, confirmation steps, limits.

So start without writes. Add one when you can name the confirmation path, the audit trail and the way to undo it, and add them one at a time. A server that only answers can be wrong, but it cannot change anything.

Write the descriptions for a new colleague

Name tools after the question, not after the endpoint: what_changed_since beats getReleaseDiffs. Write the description the way you would brief someone on their first day: what it answers, what it does not, what an argument means, what an empty result means. An empty result deserves a sentence of its own, because an agent that gets nothing back tends to fill the gap.

The catalog is documentation, and it ages

Here is the part teams discover in month three. The descriptions in a catalog are statements about your product. When a limit changes, a field is renamed or a tool starts returning something else, the description stays as written and the agent keeps repeating it. A catalog drifts like any other documentation; see how to detect documentation drift.

Two habits slow it down. Keep descriptions short, because a short description has less to go stale. And tie the catalog to the release process, so that a change to a tool's behavior is part of the diff review, not an afterthought.

"We'd rather build our own"

Often right, and worth saying plainly. If you want agents to act in your product, create a booking, refund an order, change a setting, nobody can build that surface for you. It is your domain, your permissions, your risk. Everything above is a method for building it well.

DeployIt is a different thing and does not replace it. It answers questions about your product rather than operating inside it: it reads the real code (resynced on every push) and the git history (commits and diffs), and checks the code before asserting anything. The connection is read-only and revocable at any time, one MCP server per project. The two can coexist: yours acts, ours answers "what changed this week?" without anyone maintaining a catalog by hand. The access model is described in authentication and revocable access for an MCP server, and the broader picture in giving AI agents access to your code safely.

Three frequent questions

How many tools is too many? There is no threshold in the protocol. The practical signal is when you cannot explain the difference between two tools in a sentence, or when an agent regularly picks the wrong one. Merge or cut at that point.

Should the catalog mirror the OpenAPI spec? Use the spec as a source of candidates, never as the catalog. A spec describes what exists. The catalog describes what you decided to hand over.

Do we need resources at all? No. Tools alone work. Resources earn their place for stable reference content, because a client can load them without the agent spending a call to ask.

Where to start

Write the eight candidates before writing any code. Run the three questions. Ship the ones that pass, with descriptions a new colleague could use, and review the list again after the first month of real calls.

DeployIt's MCP server is in early access / design partner program, and the program is open. DeployIt is free during early access; paid plans arrive in January 2027.