cricket_build_dream11_team

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that projections are model output (meta.estimated: true) and notes credit constraints (total_credits <= 100). It also details the return structure including boosts. No contradiction with annotations.

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?

Well-structured with Args, Returns, and Example sections. The description is moderately lengthy but each sentence adds value. The main purpose is front-loaded. Could tighten the strategy description slightly, but overall efficient.

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 an output schema is present (context signals), the description covers all input parameters and describes the output structure in detail (players, captain, vice_captain, credits, projected points, meta note). No obvious gaps for a team-building tool.

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 100%, with all parameters documented. The description reinforces and extends the schema by explaining the relationship between match_id and team_a/team_b/venue (mutual exclusivity) and noting future strategy variants. This adds practical context beyond the raw schema.

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 it recommends an optimal fantasy XI plus captain and vice-captain for one fixture. It uses a specific verb ("Recommend") and identifies the resource (fantasy team). It distinguishes from siblings like cricket_captain_recommendation (which focuses only on captain) and cricket_differential_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?

Explicitly explains two input modes: using match_id alone or providing team_a, team_b, and venue together. It states when each parameter is required ("Required if match_id is absent"). However, it does not directly advise when to use this tool over alternatives like cricket_captain_recommendation, though the purpose differs.

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