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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe, local nature of the operation is covered by structured data. The description reinforces this with 'No search is run', which is genuinely useful for preventing misuse, but says nothing about how the 500-item maximum is handled (truncation vs error), whether field names are flattened, or what the caller receives back.

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?

Two sentences, no filler, with the transformation and its input source front-loaded ahead of the negative constraint. Every clause carries information.

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?

This is a simple two-parameter, read-only utility whose safety profile is already in annotations, so the description covers the essentials. However, with no output schema, the description never clarifies whether the tool returns the CSV/JSON text or writes a file, which is the one thing an agent still needs to know.

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 50% – the results parameter is documented, and format carries an enum with a default but no prose. The description adds light meaning by attaching use cases to each format (CSV for spreadsheets/CRM, JSON as 'clean'), which is slightly more than the enum alone, but 'clean JSON' is not defined and the maxItems cap is not mentioned.

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?

States a specific verb and resource ('turns results ... into CSV ... or clean JSON') and names the exact upstream tools (firsay_search, firsay_search_more) that produce its input, so it is unmistakable from its siblings.

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 phrase 'No search is run' explicitly excludes the search behaviour of its siblings and implies this is a post-search formatting step, plus it names concrete downstream targets (Google Sheets, a CRM). It stops short of stating when not to use it, e.g. that inputs are capped at 500 items, so it lands just below a full 5.

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