get_match_picks

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

With no annotations, the description carries the full burden. It discloses the scope ('every suggestion', 'single match'), the return shape ('same BetSuggestion shape as list_picks'), and the relationship to sibling list_picks. While it doesn't explicitly call out read-only or pagination, the behavior is sufficiently transparent for a simple fetch-by-ID tool.

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, front-loaded with the main action, and zero filler. Every clause adds value: the action, the use case, and the output shape comparison.

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 one-parameter tool with no output schema, the description provides enough context: it explains the scope, the return shape, and the use case. The reference to list_picks covers the missing output schema details, and the tool is simple enough that no additional edge-case disclosure is needed.

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 100%, with match_id already described in the schema. The tool description adds no further parameter details beyond referring to 'a single match,' so the minimum viable baseline of 3 applies.

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?

Purpose is explicitly stated: 'Fetch every suggestion the Statos engine has emitted for a single match.' The verb 'Fetch' identifies the action, the resource is clearly the predictions for one match, and the phrase 'scoped to one match' directly distinguishes it from sibling list_picks.

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?

Clear use case is given: 'Useful for per-match analysis' with an illustrative question. It also contrasts with list_picks by noting the same shape but scoped to one match, implicitly guiding the agent to choose this when a single match is of interest. Explicit exclusion of when not to use is absent, so not a perfect 5.

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