market_context

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden, and it does so well. It explicitly notes no authentication is required, explains date defaults and the 730-day limit, describes the fallback from daily snapshots to monthly archive tables after 365 days, exposes metadata.resolution and metadata.dataCompleteness, and mentions the 5-minute cache. This is substantial transparency, though it stops short of fully describing the response shape or error behaviors.

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 front-loaded with the core purpose, but it repeats the same list of sources twice in nearly identical phrasing ('Fear & Greed, whale summary, sentiment, stablecoin flows, funding rates, golden alerts, analyst summaries' vs 'Fear & Greed, whale daily summary, social sentiment, stablecoin flows, BTC funding rates, Golden Alerts daily count, analyst daily summaries'). It also ends abruptly with 'hi', suggesting truncation or an editing artifact. The redundancy undermines conciseness.

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?

For a single-optional-parameter aggregator with no output schema, the description covers the essential operational context: what sources are aggregated, how the date parameter behaves, what archive fallback occurs, what metadata fields to inspect, and that no auth is needed. It is sufficient for an agent to invoke the tool correctly, though a fuller response-shape description would make it complete.

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?

There is only one parameter, date, and the input schema already documents its format, default, maximum lookback, and the 365-day archive fallback with 100% coverage. The description largely restates this same information rather than adding meaningful new parameter-level guidance, so the baseline 3 is appropriate.

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?

Description opens with a specific verb and resource: 'Get aggregated market context for a date in one call', then enumerates the 8 data sources included. This clearly identifies the tool as a multi-source aggregator and differentiates it from the many sibling endpoints that cover individual sources like fear_greed, funding_rates, or stablecoin_flows.

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?

The description makes the use case clear: when an agent needs a single-call cross-section of Fear & Greed, sentiment, whale activity, flows, and analyst summaries for a date. It does not explicitly name alternatives or state when not to use it, but the 'single-call aggregated snapshot' framing strongly implies the choice over calling multiple sibling source-specific endpoints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.