prices_current

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

With no annotations, the description carries the full behavioral burden, and it does so exceptionally. It discloses open-ended keys, upstream changes, pass-through values, cache behavior, single-GET semantics, no continuation fetching, row/size limits, truncation reporting, and refusal of oversized records. These are behaviors an agent could not infer from the empty schema.

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 first sentence is front-loaded and the caveats are transparent, but the description is lengthy and includes generic statements about continuation pages, declared filters, and array limits that seem irrelevant to a zero-parameter price-object endpoint. There is also a wording/line-join error after 'GET request'. It could be tighter while retaining the important cache and truncation details.

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 no-input, no-output-schema read, the description covers most behavioral essentials: source, open-ended key set, value pass-through, cache, truncation, and oversized-record refusal. The main gap is that it never sketches the returned object shape, so the agent must infer from the tool name and runtime response what the price object actually looks like.

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 schema has zero parameters, so the schema fully documents inputs and the no-param baseline is high. However, the description contains boilerplate about 'required inputs' and 'other declared filters' that are not present in the schema; this adds noise and could mislead an agent into thinking parameters are accepted. It adds no valuable parameter-level meaning.

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 ('Read'), a precise resource ('current public token-to-USD price object'), and a source ('official price feed'). This clearly separates it from the many sibling tools, none of which claim this price-feed purpose.

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: this is the tool for current public token prices, with no pagination and a bounded cache. It does not name an alternative or explicitly say when not to use it, but no price-feed sibling exists, so the provided context is sufficient for selection.

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