FREE daily pulse across the catalog: regime flips, funding extremes, CEX-vs-DEX spread extremes, biggest daily moves. One day of values — the history behind each number is the priced product.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key limitation: 'One day of values' and notes that 'history behind each number is the priced product', which tells the agent the scope and potential paywall. However, it does not explicitly mention read-only nature, auth requirements, or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that pack meaningful information: what the tool returns, the scope, and a pricing/limitation note. No wasted words; it is front-loaded with the most important phrase 'FREE daily pulse across the catalog'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and zero parameters, the description should fully explain return values. It names content areas (regime flips, funding extremes, CEX-vs-DEX spread extremes, biggest daily moves) but does not specify the exact structure or field names. Still, for a snapshot summary tool, it provides reasonable guidance. The note about history being the priced product adds context for expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description adds semantic context by listing the types of values returned (regime flips, funding extremes, etc.), which helps the agent understand what the output represents even though there is no parameter to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'daily pulse across the catalog' with specific components like 'regime flips' and 'funding extremes'. It differentiates from sibling tools (e.g., get_regime_label, get_funding_spread) by covering the whole catalog as a combined snapshot, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied via 'across the catalog' and the mention of 'one day of values', suggesting it's for a broad market overview rather than deep dives. However, there is no explicit 'when to use' or 'when not to use' guidance, nor references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools clearly target a distinct data resource: bars, events, fundamentals, funding, open interest, order flow, and so on. A few adjacent tools like audit_my_data and validate_backtest_data, or get_market_pulse and get_regime_label, are somewhat similar, but their descriptions provide enough separation for an agent to choose correctly.
The dominant pattern is get_<data_type>, used consistently across most tools and all in lowercase snake_case. The non-get tools are mostly still readable verb-noun names like build_bundle and validate_backtest_data, though lookahead_check and survivorship_check are minor deviations.
With 22 tools, this is on the heavier side for a single MCP server, especially since many tools have fairly specialized data sources. Each tool is individually justifiable, but the overall surface is large and may push agents to spend extra work choosing among near-adjacent data options.
The server covers far more than plain OHLCV: it includes fundamentals, insider and institutional ownership, funding rates, open interest, order flow, events, context, regime labels, and backtest-quality validation. Minor missing areas like trade-by-trade quotes or a broader symbol catalog mechanism exist, but the common market-data workflows are very well supported.