conflict_seasons

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

Despite having no annotations, the description thoroughly discloses behavior: 'response shape depends on the selector', 'Makes one logical GET request', 'Does not auto-fetch continuation pages', 'Array responses are locally limited to 100 rows and 256 KiB', and 'Oversized records are refused without partial fields'. It also notes that 'Other declared filters are forwarded as supplied; their effectiveness is not implied by the schema', which is a critical caveat. This is an exceptionally transparent description for a tool without annotation support.

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 front-loaded with the core purpose and then provides a dense but valuable set of behavioral details. It is a bit long and has a minor typo ('request Does'), but each sentence adds distinct information, and the structure moves from purpose to selector semantics to request behavior to local limits. No sentence is wasted.

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?

The description thoroughly covers request behavior, limits, and truncation, but it lacks an explanation of the actual return data: there is no output schema and no description of what fields compose a 'conflict season' beyond a passing mention of 'nullable prize settings'. It also leaves the meaning of 'lore' unexplained. For a tool with no output schema and 0% parameter coverage, this is a noticeable gap in completeness, even though other aspects are well covered.

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 provides no descriptions for 'id' or 'lore' (0% coverage), so the description must carry the burden. It does: 'Without id the upstream returned 24 records; an explicit id returned one object' gives practical semantics for 'id', and 'Other declared filters are forwarded as supplied; their effectiveness is not implied' warns about the reliability of filters like 'lore'. This adds meaningful guidance beyond the bare schema, though it could be more explicit about the exact meaning or format of each parameter.

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 opening phrase 'Read conflict seasons' clearly states a specific verb and resource, which distinguishes it from most sibling tools like conflict_status or conflict_players. However, it does not explain what a 'season' contains or explicitly differentiate from the other conflict_* tools, leaving some ambiguity for an agent unfamiliar with the domain.

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?

No guidance is given on when to use this tool versus alternatives. The description explains that the 'id' selector changes the response shape, but it never states conditions such as 'use this to list all seasons' or 'use this when you need a specific season by id' in comparison to other conflict-related tools. Context about required inputs is vague ('Required inputs reflect tool policy') but does not help choose between tools.

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