cricinfo_match

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the scorecard is public, that upcoming matches return an empty innings list, and that live-score URLs are normalized. It does not mention error handling or rate limits, but for a read-only fetch tool, these are minor omissions.

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 three sentences, front-loaded with the purpose, and includes only relevant details. It is concise, well-structured, and avoids redundancy.

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?

Given the single parameter, no output schema, and no annotations, the description is comprehensive. It covers what is returned, the edge case of upcoming matches, and the URL requirements. An agent can correctly invoke this tool without further clarification.

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 already describes the URL, but the description adds significant semantics: the canonical URL pattern and the normalization of live-score URLs. This goes beyond the schema's minimal description and helps the agent construct valid inputs.

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 states the action ('Get a Cricinfo match scorecard') and the resource, and it lists the return contents (match state, team scores, innings totals, batter/bowler lines). It also distinguishes from sibling tools like cricinfo_scores or cricinfo_commentary by focusing on scorecard retrieval.

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 gives clear context on what the tool does and the URL format required, but it does not explicitly compare to alternatives or state when not to use it. It implies usage by specifying the return type and normalization behavior, but lacks explicit exclusions.

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