get_round

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It describes the return content and optionality of shots, but does not explicitly state read-only semantics, potential performance implications of include_shots, or any side effects. It adds some context but leaves room for more transparency.

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 concise and front-loaded: the first sentence gives the core purpose and content, the second provides usage guidance and sibling differentiation. Every sentence earns its place with no wasted words.

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?

With an output schema present, return value details are covered. The description adequately covers the tool's scope, input source, and optional behavior of shots. It does not explain include_holes, but that is relatively self-explanatory given the schema and the context. Slightly more detail on what 'header' contains could improve completeness, but it's sufficient for a moderate-complexity 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 description coverage is 0%, so the description must compensate. It meaningfully explains round_id (from list_rounds) and clarifies include_shots ('optionally every shot'). However, it does not mention include_holes beyond the schema's default, so it's slightly incomplete. Overall, it adds value beyond the schema for the most important parameters.

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 what the tool does: 'Get one round in depth' with specific return content (header, hole-by-hole scorecard, optionally every shot). It also distinguishes itself from sibling get_shots by noting when to prefer that tool for shot analysis/mapping.

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?

Explicit usage guidance is provided: round_id comes from list_rounds, and the description explicitly recommends using get_shots instead when the goal is shot analysis or mapping. This clearly delineates when to use this tool versus the alternative.

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