Loading ToolBench
An MCP server for accessing Massive.com financial market data APIs, including stocks, options, crypto, forex, futures, indices, and economic data. Provides endpoint discovery, API calling, data storage, SQL querying, and financial function calculations.
This server demonstrates good definition quality overall with clear, action-oriented tool names and detailed descriptions that guide LLM usage. All 6 tools are explicitly registered with comprehensive input schemas using Pydantic Field annotations. Descriptions are well-written (100-400+ chars) and include usage hints, prerequisites, and chaining instructions that match production baseline standards. However, there are gaps in output schema documentation, no explicit schema definitions are provided for tool responses, and some parameter descriptions could be more precise about return formats and edge cases.
Apply finance functions (Greeks, technical indicators, returns, etc.) to a stored DataFrame. Returns a new table with computed columns. Supports chaining multiple functions via semicolon-separated expressions.
Call any Massive.com API endpoint. Takes path and optional query parameters. Returns raw JSON. Use search_endpoints first to find the right endpoint. Optionally store results in a DataFrame for further analysis with query_data or apply. Pass apply with a function name to compute Greeks, technical indicators, or other derived metrics inline. Supports pagination via cursor parameter or next_url hints.
Delete a stored DataFrame by name.
List all stored DataFrames and their schemas.
Query any stored DataFrame using SQL. Returns results as formatted text or CSV. Use store_as in call_api to populate tables first. Query results can be further analyzed with apply to compute derived metrics.
Search for market data API endpoints and built-in finance functions by natural language query. Use this FIRST to find the right endpoint before calling call_api. Covers stocks, options, forex, crypto, futures, indices, ETFs, and economic data. Pass market to pin results to a specific asset class when you already know it; omit it and the server will infer from the query. Use detail="more" to see query parameter docs needed for building call_api requests.
Output schemas not documented. No explicit definition of what each tool returns (field names, types, structure). LLMs must infer response format from description text alone, increasing hallucination risk and preventing reliable downstream composition.
Parameter 'apply' in call_api and 'apply' in apply tool lack specification of valid function names and their signatures. Description says 'Example: apply="bs_delta(S=close, K=strike, T=dte, r=0.05, sigma=iv)"' but does not enumerate available functions or document syntax/validation rules. LLMs may invent invalid function names.
drop_table tool is destructive (WRITE risk noted) but lacks any confirmation/dry-run pattern or detailed error guidance. Description does not explain consequences or recovery options. Per pattern:confirmation-request, irreversible operations should require explicit confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
search_endpoints 'market' parameter enum is clear (Stocks, Options, Crypto, etc.), but several parameters lack detail level: 'params' in call_api is type 'object' with vague description 'Query parameters as key-value pairs', no guidance on which parameters are required, valid values, or format expectations. Requires users to call search_endpoints first to discover API structure.
list_tables description is minimal (7 words: 'List all stored DataFrames and their schemas.'). Lacks guidance on when to call it, what schema information is returned, or how it fits into typical workflows.
No error handling documentation. Tools provide no explicit guidance on recovery paths (e.g., 'If API returns 401, credentials may be invalid; check MASSIVE_API_KEY'; 'If store_as table already exists, call drop_table first'). Per pattern:recovery-guide, error responses must tell the LLM what to do next.
Response size limit (MAX_RESPONSE_SIZE_BYTES = 50 MB) exists in code but is not documented in tool descriptions. LLMs cannot reason about truncation or pagination without knowing this constraint. Per mxe:enforce-result-limits, response caps should be stated in tool descriptions.