Oh sorry I didn't explain that we are not dumping the entire endpoint list to the MCP. We have 400+ endpoints so this would be terrible.

We tag each endpoint by category in the OpenAPI spec and require the MCP to request actions by tag and optional query term. At most we return 10 endpoints at a time and the LLM can request more using pagination.

These tags also create your categories in API doc websites like swagger/mintlify so its a win win.

OpenAPI spec is the single source of truth.

I created MCP AQL, which is an extension to the MCP spec, specifically to reduce the bloat for MCP tools.

It only has five CRUDE endpoint: Create, Read, Update, Delete, and Execute using a GraphQL-like structure for tool calling of the operations within the endpoints. It's very efficient, and robust. there's all kinds of exemplar tools and components to make adapters for any MCP server. You don't even need to rewrite your own MCP server. Just create an adapter for it.

All open source at MCPAQL.com

Just because a MCP server offers 100 MCP tools doesn't mean that they all have to be in your context. Any decent harness will let you filter out ones you don't want. And to take that concept further you really should be designing specialized subagents that only have access to a small subset of total MCP tools in the first place.