conflict_leaderboard

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

With no annotations, the description fully shoulders the burden and does so excellently. It discloses that the upstream returns 200 rows, the server truncates to a bounded leading portion, totals and prizes are retained, pagination is not functional, only one GET is made, filters are forwarded without effectiveness guarantees, the list is limited to 100 rows/256 KiB, truncation is reported, and oversized records are refused without partial fields. This is exceptionally transparent about behavior, limits, and failure modes.

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 thorough yet efficient. It leads with purpose, then systematically covers upstream behavior, request characteristics, filter semantics, local limits, truncation handling, and refusal behavior. Every sentence adds distinct value with no filler or redundancy. The logical flow makes it easy to scan.

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 simple one-parameter tool with no output schema, the description is nearly complete. It explains what the response contains (totals and prize metadata, truncation reported), key constraints (100 rows, 256 KiB, single request), and failure behavior (refusal of oversized records). It does not detail the exact output schema, but that is not required. Minor omission: it doesn't describe error formats for non-oversized failures, but overall it is sufficient.

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 coverage is 0% and there is only one parameter (id). The description adds only 'by id', which is minimal and somewhat tautological given the tool name. It does not explain what kind of id this is (e.g., a leaderboard id, season id) or where to obtain it. The sentence 'Required inputs reflect tool policy as well as measured upstream requirements' does not clarify semantics. This is adequate but leaves a clear gap about the id's meaning and provenance.

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') plus a precise resource ('conflict leaderboard, totals and prize metadata by id'). It clearly distinguishes this from other conflict_* tools by focusing on leaderboard data keyed by id, and the phrase 'by id' sets it apart from list-style endpoints. It is unambiguous about what the tool does.

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 behavioral context (no pagination, single GET, bounded response) but does not provide any guidance on when to use this tool over sibling conflict endpoints like conflict_players or conflict_player_rank. It never names alternatives or exclusion criteria, leaving the agent to infer from the name alone. This is a clear gap.

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