Loading ToolBench
Market Data MCP Server - stocks, forex, crypto, commodities & more via Model Context Protocol
This MCP server exposes 5 tools with mixed quality. Three meta-tools (TOOL_LIST, TOOL_GET, TOOL_CALL) are self-referential and lack substantive business logic. Two data tools (INDEX_DATA, INDEX_CATALOG) provide actual market data but have incomplete input schemas and limited descriptions. Tool names are action-oriented (good), but parameter descriptions are sparse, and no output schemas are documented. The server does implement tool annotations (a current pattern), but lacks comprehensive error handling guidance and parameter constraints. Average per-tool quality is 58, fair but with significant gaps in schema completeness and parameter documentation that would hinder LLM-driven tool selection and execution.
Returns the full list of supported index symbols with their long-form names.
Returns daily, weekly, or monthly OHLC time series data for 200+ major market indices (e.g., DJI, SPX, COMP, NDX, VIX, RUT). For the full list of supported indices, use INDEX_CATALOG.
Executes a named Alpha Vantage API tool with the provided arguments and returns its result.
Returns the full schema for one or more named tools, including each tool's name, description, and parameter definitions (JSON schema). Accepts a single tool name or a list of tool names.
Lists the available Alpha Vantage API tools, returning each tool's name and short description without parameter schemas.
INDEX_DATA and INDEX_CATALOG input schemas lack required constraints and type annotations. The 'interval' parameter in INDEX_DATA lists supported values only in the description ('daily, weekly, monthly') but does not enforce them as an enum constraint. The 'datatype' parameter similarly lacks enum specification. LLMs cannot parse free-form descriptions reliably and will hallucinate invalid values.
No output schemas are documented for any tool. Clients and LLMs have no way to know what fields to expect from INDEX_DATA, INDEX_CATALOG, or the meta-tools. Without documented return types, agents cannot plan downstream calls or extract the correct fields. This violates the baseline that 100% of A+ tools have documented return types.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 34 | 1.12.3+ | v1 |
INDEX_DATA and INDEX_CATALOG descriptions are generic and lack action-oriented guidance. The INDEX_DATA description does not specify what time series data is returned, what fields are included, or when to call it vs INDEX_CATALOG. Descriptions should state WHAT the tool does, WHEN to use it, and key prerequisites, currently they merely list parameters.
TOOL_CALL, TOOL_GET, and TOOL_LIST descriptions do not explain error scenarios, recovery paths, or failure modes. If a tool call fails, the LLM has no guidance on what to do next. Error handling descriptions are absent.
INDEX_DATA and INDEX_CATALOG lack parameter minimum/maximum constraints and format specifications. The 'symbol' parameter has no validation hints. The 'datatype' parameter should enforce json|csv but relies on description alone. Unbounded or under-constrained parameters allow LLMs to pass invalid values that will fail at runtime.