Quote

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

Beyond the readOnly/openWorld/destructive annotations, the description discloses important behaviors: unknown symbols raise an MCP isError, tokens without a current quote return metadata with bid/ask None, and multiplier pending is None when nothing is queued. It also warns that adjusted fields must be read next to multiplier, which is valuable operational context.

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 dense and front-loaded with the core result, and every sentence adds useful information. The long first sentence lists many fields that may already be present in the output schema, but it also adds interpretive guidance like 'always read them next to multiplier,' so the length is justified.

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?

The description covers the main operational concerns: what data is returned, what happens for unknown symbols, and what happens when no quote exists. It would be even more complete with an explicit pointer to the quotes sibling for multi-token requests, but nothing critical is missing for invoking this tool correctly.

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 compensate. It does so by providing an example (quote(symbol="AAPL")), clarifying that the symbol must come from the valid set exposed by token_list(), and explaining the failure mode for unknown symbols. It doesn't specify case-sensitivity or formatting, but for a single string parameter this is sufficient guidance.

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 states a precise operation — "One token's live quote joined with its asset metadata" — and enumerates the exact fields returned. The singular framing clearly distinguishes this from sibling tools like quotes (plural), token_list, and token_detail.

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?

It gives clear context for when to use this tool: for a single token's live quote. It also provides concrete guidance on the valid symbol set by telling the agent to call token_list() when an unknown symbol error occurs. It does not explicitly contrast with quotes or other siblings, but the usage context is clear enough.

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