What to Do When an API Has Too Many Endpoints for One MCP Server

A developer outlines a strategy for splitting large APIs across multiple focused MCP servers rather than exposing hundreds of endpoints through a single server. The approach groups tools by user workflow—such as support, billing, and admin surfaces—so AI clients face less ambiguity when selecting tools. The developer argues that endpoints should only become MCP tools when a clear user request maps to them, and that overlapping endpoints should be consolidated or named by user-visible purpose.

Large APIs are where MCP design gets interesting. If your API has 15 endpoints, you can review each one by hand and decide which operations should become tools. If your API has 300 endpoints, exposing everything creates a different problem: the MCP server becomes technically complete but hard for an AI client to use. An AI client does not see your product the way your backend team sees it. It sees a list of tool names, descriptions, and input schemas. If that list is too large or too repetitive, the client has to spend more effort choosing a tool than solving the user's request. The fix is not to dump the whole API into one MCP server. The fix is to design focused capability surfaces. Most APIs grow around product history. You may have: That API shape may be fine for developers. It is not automatically a good AI-facing interface. If you convert every endpoint into one MCP tool, the client may see dozens of similar options: get customer get customer by id fetch customer list customers search customers admin get customer get customer summary get customer details Even if each tool works, the set becomes noisy. The model has to infer which tool is safest, which one returns the right fields, and which one matches the user's intent. That extra ambiguity leads to wrong calls, more retries, slower workflows, and harder debugging. The first reduction pass should be workflow-based. Do not start with: "Which endpoints do we have?" Start with: "Which user task should this MCP server help with?" For example, a SaaS product may have several possible workflow groups: Each group needs a different tool surface. A support workflow might need: get customer list customer tickets get ticket list customer subscriptions It probably does not need: delete customer create invoice adjustment rotate api key update workspace permissions run internal report Grouping by workflow helps you remove endpoints without arguing about whether they are "important." Many endpoints are important to the product, but irrelevant to a specific AI workflow. For a large API, one MCP server can become a junk drawer. Focused servers are easier to reason about. For example: Support MCP server - get customer - list customer tickets - get ticket - create ticket note Billing MCP server - list customer invoices - get invoice - get subscription Admin MCP server - get workspace settings - update workspace setting These do not have to be separate products. They are separate AI-facing surfaces. The advantages are practical: This is especially useful when different roles should have different access. A support agent, sales rep, billing admin, and internal developer should not always see the same MCP tools. Some endpoints exist because the frontend or backend needs them. That does not mean an AI agent needs them. Good MCP tools usually map to user requests like: Weak MCP tools often map to implementation details: When reviewing a large API, ask this for each endpoint: What would a real user ask that should cause an AI client to call this tool? If you cannot write that request clearly, leave the endpoint out for now. Large APIs often contain overlapping endpoints. GET /customers/{id} GET /customers/{customer id}/profile GET /crm/customers/{id} GET /support/customers/{id} These might serve different backend needs, but they can create confusing MCP tools: get customer get customer profile get crm customer get support customer If the agent's task is support context, expose the one that returns the right support-facing shape. Do not expose all four unless the differences are clear and necessary. If two tools must remain, name them by user-visible purpose: get customer support profile get customer sales profile That is better than making the model guess the difference between crm and support from internal naming. Tool overload can come from the number of tools, and it can also come from one huge schema. Watch for tools that accept: data payloads This kind of schema makes the AI client guess how to construct a safe request. Instead of one giant update tool: update customer Consider smaller tools: update customer billing email update customer support status update customer account owner The smaller tools are easier to describe, easier to permission, and easier to test. There is a tradeoff. Too many tiny tools can also become noisy. The line I use is simple: split a tool when the actions have different permissions, side effects, or user intent. Some endpoints should not be mixed into a general-purpose MCP server. Review these carefully: These operations are not forbidden forever. They need stronger review. For sensitive tools, define: If a sensitive endpoint is useful only to internal staff, do not expose it in the same MCP server used by customers. When an AI client chooses a tool, the description does real work. For a large API, weak descriptions compound fast. Bad: Gets customer. Better: Get the support-facing profile for one customer by customer ID. Use this before checking tickets or subscription status. Updates ticket. Change the status of one support ticket after the user confirms the new status. Descriptions should answer: If you have 40 tools with vague descriptions, adding 20 more tools makes the system worse. Fix the existing tool interface first. For large APIs, I prefer an allowlist. A denylist says: "Expose everything except these dangerous routes." That is risky because new endpoints may appear later and slip into the MCP surface by default. An allowlist says: "Expose only these selected operations." That is safer and easier to review. A simple allowlist can look like: servers: support context: expose: - GET /v1/customers/{customer id} - GET /v1/tickets - GET /v1/tickets/{ticket id} - POST /v1/tickets/{ticket id}/notes billing lookup: expose: - GET /v1/invoices - GET /v1/invoices/{invoice id} - GET /v1/subscriptions/{subscription id} admin controls: expose: - GET /v1/workspaces/{workspace id}/settings - PATCH /v1/workspaces/{workspace id}/settings This makes the decision explicit. It also makes reviews cleaner when the API changes. Testing each tool by itself is necessary, but it is not enough. When the API is large, you also need to test tool selection. Use prompts that resemble real user requests: Find open tickets for customer cus 123. Show the latest unpaid invoice for customer cus 123. Update ticket tick 456 to resolved. Can you delete this customer? Then check: If the agent keeps choosing the wrong tool, do not patch around it only with prompts. Reduce the tool set, rename tools, improve descriptions, or split the server by workflow. With 0mcp https://0mcp.io/ , teams can import a supported Swagger, OpenAPI, or Postman definition, review detected operations, and select which API functions should become MCP capabilities. That selection step matters for large APIs. The point is not to publish every route. The point is to choose the useful operations, refine names and descriptions, test the result in the Playground, and host the selected server over Streamable HTTP. 0mcp currently supports hosted Streamable HTTP servers, not local stdio servers. Existing API authentication continues to be used through API key, Bearer token, or OAuth pass-through. The original API still owns business logic, authorization, tenant boundaries, pagination, rate limits, and validation. That division is important. A hosted MCP workflow can make selection, hosting, testing, logs, analytics, and version management easier. It should not replace your product's permission model. For a deeper website guide on endpoint selection, see how to choose which API endpoints to expose as MCP tools https://0mcp.io/blog/choose-api-endpoints-for-mcp?utm source=devto .