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

The readOnlyHint annotation already signals a safe read operation, and the description adds meaningful context: the output is CSV text, it matches the web export, and it contains a concrete set of fields. It does not describe edge cases like large results or formatting details, but for a read-only CSV export this is not a significant gap.

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 a single dense sentence that front-loads the core output, then efficiently lists the included fields and the return format. Every clause adds information, and there is no filler, misleading prose, or unnecessary repetition.

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 CSV export, the description covers what the output is, how it relates to the web export, and what data it contains. The absence of an output schema is mostly compensated for by the explicit statement that the response is CSV text. Minor missing details such as headers or pagination do not materially prevent correct usage.

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 single parameter 'show' is fully documented in the schema itself, including type, example, and a pointer to list_shows for discovery. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate since the structured schema carries the full burden.

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 clearly identifies the resource: citation-ready season cast CSV, and explicitly states it is returned as CSV text. It also names the fields included, which makes it easy to distinguish from sibling tools like get_cast or get_engagement. The title and description together give a direct, specific statement of what the tool produces.

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 'citation-ready' and 'same file as the web export' imply the intended use case, but the description never explicitly tells the agent when to choose this tool over a sibling like get_cast or get_engagement. The input schema does add useful discovery guidance via list_shows, but the description itself depends on inference for choosing this export.

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