Which of Your API Endpoints Should Never Become MCP Tools?

TL;DR: Never expose an endpoint as an MCP tool if you cannot scope it, preview it, or undo it. That rule excludes most admin and superuser endpoints, bulk delete and purge operations, credential, token, and permission management, billing and refund controls, raw database or search query endpoints, impersonation and login-as features, and internal debug or migration routes. The argument is principle, not statistics: least privilege and scoped permissions, drawn from MCP security guidance read 2026-10-25, say an agent should hold only the authority its task requires. Every endpoint you wrap in a tool is authority a model can exercise at machine speed, including on the day it misunderstands you.

Key Takeaways

• A tool list is a permission grant. Deciding which endpoints become tools is a security review, not a completeness exercise.
• Apply three tests to every candidate endpoint: can it be scoped to a task and a principal, can its effect be previewed, and can its effect be undone. Failing any test is a reason to keep it human only.
• Admin, credential, billing, and impersonation endpoints fail those tests by design, because their purpose is broad authority.
• Raw query and bulk operation endpoints fail the scoping test even when they look read only or merely efficient.
• When an agent workflow seems to need a forbidden endpoint, the usual answer is a narrower purpose built tool with limits inside it, not the endpoint itself.

Why is mirroring the API the wrong starting point?

The construction guidance in how to build an MCP server for your SaaS makes the positive case: project your product as jobs and outcomes, do not mirror your API. This post is the negative case, the exclusion list, and it matters more, because the harm from one wrong inclusion outweighs the convenience of ten easy ones. The framing in what actually changes when an agent calls your product through MCP instead of your API applies directly: the interface looks similar, the caller and therefore the risk model do not.

The principle underneath is least privilege with scoped permissions, the standard drawn from the MCP security guidance read for this post on 2026-10-25 and labelled as such. An agent should receive the minimum authority, for the minimum scope, for the minimum time its task requires. Any endpoint whose authority cannot be cut down to that size does not become a tool, however useful it would be in a demo.

Which categories should never become tools?

Admin and superuser endpoints. Anything built to bypass normal limits, edit any tenant's data, or override validation exists for exceptional human intervention. Scoping it down removes the very quality it exists for, so it cannot be made agent safe without becoming a different endpoint. Keep it behind human authentication and human judgement.

Bulk delete, purge, and hard delete operations. Soft deletes with a restore path can be discussed. Purges cannot. A bulk destructive endpoint fails the undo test absolutely and fails the preview test in practice, because a model composed filter with one wrong field can select far more than intended. The incident logic in how an agent deletes a production database is this category failing in the wild: one permitted call, irreversible effect.

Credential, token, and permission management. Endpoints that create API keys, rotate secrets, grant roles, or change who can do what must never be agent tools. An agent that can widen its own permissions defeats every other control on this list, and an agent manipulated through its inputs that reaches such an endpoint turns a prompt level problem into an account level one. This is the single clearest line in the post: tools must never be able to mint or expand authority.

Billing, refunds, and plan changes. Money movement is outward facing, regulated in many contexts, and frequently irreversible in practice even where a reversal mechanism exists. Agents can usefully read billing state, summarise usage, and draft a change for a human to execute. Executing the change is a human step.

Impersonation and login-as endpoints. Support tools that let staff act as a customer collapse your audit trail by design. In agent hands they also collapse your permission model, because every scoped limit can be bypassed by becoming someone the limits do not bind. Never expose them, and treat their presence in an internal API as a reason to separate that API from any agent reachable surface entirely.

Raw query endpoints. A tool that accepts free form SQL, a raw search query language, or an unrestricted filter grammar is not one tool; it is every tool you declined to build, with none of their limits. Read only versions are not exempt. A raw read can still exfiltrate at scale, joining tables the task never needed. Replace raw access with named, parameterised tools whose result sets are bounded by design.

What about endpoints that are merely dangerous?

Between safe and never lies a middle band: single record deletes, sends to real customers, status changes with downstream effects, and writes to shared resources. These can become tools, but only with the controls working together: scoped credentials, a preview or dry run, honest destructive annotations, and an approval gate proportionate to the effect.

Annotations deserve a caution, covered in how many MCP servers ask before they act: hints help a client decide when to ask, but they are not enforcement. The enforcement must live in your authorization layer and in the tool implementation itself, in limits the model cannot argue its way past, such as maximum record counts, allow listed targets, and server side validation of every argument.

What do you build instead when a workflow needs one of these?

Usually the real need is narrower than the endpoint. A support workflow does not need impersonation; it needs a read only view of what the customer sees. A cleanup workflow does not need purge authority; it needs a tool that proposes candidates, shows them to a human, and soft deletes the approved set with a restore window. A billing workflow does not need refund execution; it needs the refund calculation and a prepared action for a human to confirm in the billing system.

Building that narrower tool is more work than wrapping the endpoint. That difference in effort is the security model working as intended. The audit perspective in what is inside the MCP server you installed shows how this looks from outside: customers and their security teams increasingly read a tool list as a statement of judgement. A short, deliberate list signals a team that understood its own product. A complete list signals a mirror, and a mirror of an admin API is a finding waiting to be written up.

How do you run this review in practice?

Take your endpoint inventory and sort it into three columns: becomes a tool, becomes a narrower tool, never becomes a tool. Force every endpoint through the three tests in writing: scoped, previewable, undoable. Where a team member argues for an exception, record who argued, why, and what compensating control replaces the failed test, and set a review date.

Repeat the review whenever endpoints are added, because APIs grow quietly and a server that mirrors growth will drift toward danger without any single bad decision. The goal is not a small tool list for its own sake. It is a tool list where every entry can answer the question an incident will ask: why was the agent allowed to do that at all. If an endpoint cannot answer that question in advance, it should never become a tool.