CorpusIQ exposes 40+ connectors to AI assistants. Internally, that is 225 underlying tools across all connectors. Presenting 225 tools to ChatGPT hits a practical ceiling: the model has to scan every tool description before choosing one, which is slow and expensive in tokens.
The fix is a pattern we call mega-tools: collapsing 225 tools into 24 that ChatGPT sees, with dynamic routing to the real tool underneath. This post explains why the pattern exists, how it works, and the tradeoffs.
The tool count problem
Every MCP tool a model sees costs tokens. The model reads the tool name, description, input schema, and output schema before deciding whether to call it. Those tokens add up.
With 225 tools exposed naively, every user message consumes a significant fraction of the context window just on tool descriptions. That has three consequences:
Latency. More tools to scan means more tokens to process before the model can respond. Users feel this as "slow ChatGPT."
Cost. Tokens are billable. Exposing 225 tools to every conversation pays a per-message tax in perpetuity.
Accuracy degradation. At scale, the model starts to confuse similar tools. "Search Gmail" and "Search Outlook" can look similar enough that the wrong one gets called.
ChatGPT's deployment surfaces these tradeoffs most sharply. The effective ceiling for clean routing is well below 225 tools.
The mega-tool pattern
Twenty-four mega-tools. Each represents a category of action across connectors. Examples:
search_documents (replaces specific search tools for Drive, Dropbox, OneDrive)
get_financial_data (replaces specific tools for QuickBooks, Shopify)
query_database (replaces specific tools for PostgreSQL, MSSQL, Cosmos)
get_customer_data (replaces specific tools for HubSpot, GoHighLevel, Shopify customers)
Each mega-tool has parameters that specify source and action. The model sees "search_documents" with a connector parameter and a query. ChatGPT routes by intent at the category level, which is easier and cheaper.
How the dispatch layer works
Behind each mega-tool is a dispatcher.
When ChatGPT calls search_documents with connector=drive, the CorpusIQ server routes to the Google Drive search tool. With connector=dropbox, it routes to the Dropbox search tool.
The dispatch layer is thin. It is not doing anything complicated; it is just mapping a normalized interface to the underlying connector-specific tool. The complexity lives in keeping mega-tool definitions coherent across connectors.
For cross-connector queries ("search all my document storage for X"), the dispatcher can fan out to multiple connectors and merge results. This is where the mega-tool pattern actually adds value beyond cost: it makes multi-connector reasoning easy.
The intent classifier
Some CorpusIQ deployments add a lightweight intent classifier in front of the mega-tools. Before the main model sees the tool list, a fast cheap model (Claude Haiku in CorpusIQ's case) classifies the user's intent and pre-filters the tools shown.
If the user asks "what is my cash position," the classifier recognizes this as financial, and the main model sees only financial-category tools. If the user asks "search my calendar," the classifier routes to scheduling tools.
The classifier costs one extra token round-trip per message, which is small compared to the tokens saved by not showing the model 225 tool descriptions.
The risk: a bad classifier denies the main model access to a tool it actually needed. The fix: conservative defaults. When the classifier is uncertain, it shows more tools rather than fewer.
Why this is not just compression
Mega-tools could be criticized as a cosmetic fix. If the underlying tools exist, why hide them behind a narrower interface?
Two reasons it matters.
First, cognitive load on the model. A model presented with 225 near-duplicates picks wrong more often than a model presented with 24 distinct categories. The abstraction helps the model reason about what to call.
Second, interface stability. When CorpusIQ adds a 23rd connector, its tools slot into existing mega-tool categories. The mega-tool interface does not grow. Clients (Claude, ChatGPT, Perplexity deployments) do not need to update. The system scales without protocol breakage.
What this looks like for ChatGPT specifically
ChatGPT's Actions and Connectors architecture requires tools to be exposed through a manifest. The manifest size is bounded in practice.
CorpusIQ's ChatGPT deployment exposes 24 mega-tools in the manifest. ChatGPT's model works efficiently because the manifest is small. The dynamic dispatch happens entirely inside CorpusIQ's server, invisible to ChatGPT.
For Claude, the same mega-tools are exposed but the cost pressure is lower. Claude can handle more tools in practice, so CorpusIQ's Claude deployment can expose both mega-tools and some direct connector-specific tools where that helps.
The engineering cost
Mega-tools are not free to build.
Each mega-tool requires a schema design that works across every underlying connector. "Search documents" needs to handle Drive's metadata, Dropbox's folder structure, and OneDrive's SharePoint quirks. That is real engineering work.
Each mega-tool requires a dispatcher with complete coverage. Missing a case means the model calls a mega-tool and gets an error. Users notice.
Each new connector onboarding requires mapping its tools into the existing mega-tool categories. The template exists, but the mapping is still work.
The payoff is ChatGPT integration that actually scales, and a cleaner interface for Claude too. The payoff justifies the cost at CorpusIQ's scale. At smaller scale, exposing tools directly is fine.
What we learned
Three lessons from deploying this at production.
Mega-tool interfaces need versioning. When CorpusIQ changed a mega-tool's schema, existing conversations with cached tool definitions broke. The fix is explicit versioning and backward compatibility.
Error messages matter disproportionately. When the dispatcher fails, the user sees a vague "tool error." Making those errors informative (which connector failed, which scope was missing) recovers user trust.
The classifier is worth the cost. Measured latency and accuracy improvements justify the extra round-trip in every case we tested.
See also
FAQ
Why does ChatGPT have a tool limit?
Tool selection costs tokens and slows responses. Practical limits exist to keep the experience fast. The exact ceiling varies by model and deployment.
Does Claude have the same limit?
Claude's ceiling is higher in practice but the underlying dynamics (token cost per tool description) are the same. The mega-tool pattern is useful for both.
Does this degrade accuracy?
When implemented carefully, no. The intent classifier has to be good. A bad classifier routes calls to the wrong handler. This is engineering tradeoff.