market_pulse_price

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is handled. The description adds useful behavioral context beyond that: the data source is Coinbase, and symbol normalization behavior is disclosed ('A trailing -USD or /USD is tolerated and stripped'). This is valuable operating detail without contradicting the annotations.

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 extremely compact: one sentence for the tool purpose and a short Args block for the parameter. No repeated schema information, no filler, and the most important semantic detail is front-loaded. Every sentence earns its place.

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-parameter, read-only spot price lookup, the description is complete. Annotations carry the read-only/idempotence guarantees, the output schema handles return-value documentation, and the description covers source, price type, and symbol formatting. The sibling `market_pulse_supported_assets` even covers the complementary concern of which symbols are valid.

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?

Schema description coverage is 0%, so the description must carry the full explanatory burden for the single parameter. It does this well by defining `symbol` as a base ticker, providing concrete examples ('BTC', 'ETH', 'SOL'), and documenting accepted suffix forms. An agent can confidently construct valid inputs from this description alone.

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 opens with a specific verb and resource: 'Get the current spot price for a crypto asset from Coinbase.' The word 'spot' plus 'current' clearly distinguishes it from sibling tools like market_pulse_candles or market_pulse_orderbook. It is immediately obvious what the tool does and where it fits.

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 establishes clear context for when to use it: whenever the agent needs the current spot price. It does not explicitly name alternatives or when-not-to-use cases, but the phrase 'current spot price' implicitly excludes historical candles, order books, funding rates, and derived indicators. A short explicit pointer to a sibling for historical data would make this a 5.

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