We've updated the Massive MCP server from 53 tools down to just 4. This results in significantly less context overhead on every request. What your agent does now: -> Searches for any Massive endpoint by natural language -> Read its full docs automatically -> Call the API and store... results -> Query everything with SQL No bloated schemas. No stale tool definitions.show more

Why we rewrote the server The original Massive MCP server exposed one tool per API endpoint. That made sense early on, but as the platform grew, the tool count hit 53. This is extremely inefficient, because every tool definition (name, description, input schema) gets injected into the model's context window on every single request. Anthropic's engineering team documented this in their Advanced Tool Use guide: in a real-world setup with ~58 tools across five MCP servers, tool definitions alone consumed roughly 55,000 tokens before the conversation even started. They observed internal setups where tool definitions hit 134,000 tokens. That's context window space that could be holding your actual conversation, your data, your analysis.

Our 53-tool server had the same problem. Each Massive endpoint had its own tool with a full parameter schema. Some of the heavier tools, like our Benzinga earnings endpoint, carried upwards of 45 parameters each with types, descriptions, and filter variants. Across all 53 tools, the server exposed roughly 450 parameters total. Based on Anthropic's published benchmarks for similar tool sets, we estimate this loaded somewhere in the range of 15,000 tokens per session, just for tool definitions. That's tokens you're paying for on every request, and context space the model can't use for reasoning about your actual question.

The rewrite compresses everything into four composable tools with 11 total parameters. Based on the same benchmarks, total tool definition overhead drops to roughly 1,000-1,500 tokens. That's an estimated reduction of over 90%. But the token savings are only half the story. Anthropic's research also showed that tool selection accuracy degrades as tool count increases. With 50+ tools, the model has to read through dozens of schemas to pick the right one. Their testing showed that Opus 4 improved from 49% to 74% tool selection accuracy when using search-based discovery instead of a flat tool list. Fewer, well-designed tools means the model picks the right action more reliably. The new architecture also solves the maintenance problem. When we shipped a new endpoint under the old design, we had to add a new tool definition, update the server, and push a new version. Now, the server indexes endpoints dynamically from our documentation at startup. New endpoints are discoverable the next time the server restarts. No code changes, no version bumps.

The four tools Here's what the new server exposes: search_endpoints Search for API endpoints and built-in financial functions by natural language query. The server indexes every Massive REST endpoint at startup using BM25 ranking over the documentation served at get_endpoint_docs Once the agent identifies a relevant endpoint from the search results, it fetches the full parameter documentation: path parameters, query parameters, types, defaults, and constraints. This is the equivalent of the agent reading the docs page for a specific endpoint, except it happens programmatically and only for what's needed. call_api Call any Massive REST API endpoint. The agent constructs the request from the parameter docs it just read, and the server handles authentication, pagination hints, and response parsing. The key feature here is the store_as parameter: pass a table name and the response gets stored as an in-memory DataFrame. You can also pass an apply parameter to run built-in financial functions on the results inline, without a separate tool call. query_data Run SQL against stored DataFrames using an embedded SQLite engine. This supports everything you'd expect: JOINs, CTEs, window functions, aggregations. It also supports utility commands like SHOW TABLES, DESCRIBE <table>, and DROP TABLE.

How the search index works At startup, the server fetches the llms.txt index from Massive's documentation site. This index lists every REST endpoint with its name, URL pattern, and a short description. The server tokenizes these entries and builds a BM25 index in memory. When the agent calls search_endpoints with a natural language query, the server ranks every endpoint by relevance and returns the top matches. Because the index is rebuilt on each startup, any new endpoints that Massive ships are immediately discoverable without updating the MCP server itself. This is the core architectural decision that makes the four-tool design work. The agent doesn't need to know about every endpoint in advance. It searches, finds what's relevant, reads the docs for just that endpoint, and calls it. Context usage stays minimal. If you've read Anthropic's documentation on tool search patterns, this will look familiar. Their recommended approach for scaling beyond a handful of tools is to replace static tool catalogs with search-based discovery. We've baked that pattern directly into the server itself, so you don't have to implement it in your client.

Built-in financial functions The server ships with 13 built-in financial functions that can be applied to API results or SQL query outputs via the apply parameter. These run server-side, so the agent doesn't need to write Python or import libraries. Options Greeks (Black-Scholes) bs_price, bs_delta, bs_gamma, bs_theta, bs_vega, bs_rho These compute standard Black-Scholes values. Useful when you're working with raw options chain data and need Greeks that aren't included in the snapshot, or when you want to recalculate under different assumptions. Returns analysis simple_return, log_return, cumulative_return, sharpe_ratio, sortino_ratio Run these against stored price series to get return metrics without exporting the data or writing calculation code. Technical indicators sma (simple moving average), ema (exponential moving average) Apply these directly to OHLCV data stored from aggregate bar queries. The pattern looks like this in practice: call the API to fetch daily bars, store them as a table, then run a SQL query with apply: "sma(close, 20)" to get a 20-day moving average column appended to your results.

What a typical session looks like Once the server is connected, you interact with Massive's API entirely through natural language. Here's what a typical workflow looks like from the agent's perspective: 1. You ask: "Get me the last 30 days of daily AAPL data." with a query like "AAPL daily aggregate bars" and gets back the stocks aggregates endpoint as the top result. 2. The agent calls search_endpoints to read the parameter schema for that endpoint: path parameters (ticker, multiplier, timespan, from, to), query parameters (sort, limit, adjusted). 3. The agent calls get_endpoint_docs to save the results. 4. The agent calls call_api with the correct path and parameters, and passes store_as: "aapl_daily" 5. You follow up: "What was the average volume on up days vs down days?" 6. The agent calls query_data and uses SQL to retrieve results. No manual endpoint lookup. No URL construction. No context window filled with 53 tool schemas. The agent discovers what it needs, fetches only the relevant documentation, and keeps your conversation focused on the analysis.

The MCP server is open source and under active development. If you run into issues or want to request a feature, open an issue on the repo: We're particularly interested in feedback on the built-in financial functions. If there are calculations you find yourself running repeatedly after fetching data, those are good candidates for new apply functions. To get started, pick whichever client you prefer, plug in your API key, and ask your agent for the data you need. It'll figure out the rest.

You can also find it in the connectors section of Claude Desktop.

Disclaimer This content is for educational purposes only. Nothing in this post constitutes investment advice or a recommendation to buy or sell any securities or other financial instruments. Massive is a market data provider, not a broker-dealer, exchange, or investment adviser. Market data accessed through Massive may originate from third-party exchanges and data providers or may be derived or calculated by Massive; in either case, it is subject to the applicable terms of your Massive subscription agreement. The data and code samples provided by Massive are offered on an "as-is" basis without any warranty of accuracy, completeness, or timeliness. You are solely responsible for your use of the data provided by Massive and for compliance with all applicable terms and conditions, laws, and data licensing requirements.

You can start using the Massive MCP server for free by signing up for an API key over on

ngl cutting 53 tools down to 4 is the real refactor

what happens when the NL search hallucinates a non-existent endpoint

this is genuinely the kind of efficiency i want in my life

so you traded 53 tools for 4 and a search bar - how often does it hallucinate the wrong endpoint

So the server went on a schema diet and came back with SQL superpowers?

curious how you handle rate limits when you’re funneling all those calls through a single NL search step

so you replaced 53 tools with NL search - what's the latency penalty for the translation step

curious if the natural language search handles edge cases or if it just punts when it's ambiguous

Trimming 53 tools down to 4 is like @0xndra and @Lawliw switching from a cluttered toolbox to a Swiss Army knife for better focus.

4 tools and an NL search - curious how you handle the false positives when the model misinterprets a query

gotta ask - embeddings or regex for the nl search?

fascinating. can it handle rate limit errors gracefully or does it just hang

NL search is the bottleneck now - what's your precision rate

Interesting perspective

4 tools is a flex but what’s the fallback when the NL search hallucinates an endpoint

does it cache the docs or fetch fresh each time

does it handle edge cases well

unexpected moment but I’m entertained