get_league_overview

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

With no annotations, the description carries the full burden for behavioral disclosure. It says 'Get' implying a read-only operation, and 'local' suggests cached data, but it never explicitly confirms that this does not trigger a sync, nor does it explain what 'sync provenance' includes. Important behavioral traits (e.g., whether the league must be initialized first, whether this is safe) are absent.

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 one concise sentence with no filler. It quickly enumerates the data categories returned. It loses one point because 'sync provenance' is a slightly unclear term that could be expanded, but overall the length is appropriate.

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?

Although an output schema exists (which can document return structure), the description lacks necessary context about the tool's role in a broader workflow. It does not clarify what 'local' means relative to sync tools, when this should be called, or how it relates to the many sibling tools. This is a minimal description that assumes prior knowledge.

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 input schema has one optional parameter (league_id) with zero description coverage. The description does not mention league_id at all, so the agent has no indication of what it means, what values are valid, or what happens when it is null or omitted. This is a complete gap.

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 uses a specific verb ('Get') and names a concrete resource: 'current local league format, rosters, managers, and sync provenance.' It clearly states what the tool returns, and those categories distinguish it from siblings like get_sync_status or get_draft_state. However, it does not explicitly contrast with alternative tools, so it stops short of a 5.

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 no guidance on when to use this tool versus alternatives such as sync_league, get_season_context, or get_sync_status. There is no statement of prerequisites, exclusions, or recommended scenarios. The agent is left without contextual direction.

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