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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint, so the safety profile is fully covered elsewhere; the description adds nothing on top. It says nothing about whether routing is company-scoped, whether an empty result means routing is unconfigured, or what the routing payload contains. The sentence is a verbatim restatement of the title, so behavioral value beyond structured fields is zero.

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?

One tight sentence with no filler and the key concept front-loaded. The problem is not length but that every clause duplicates the title field, so the brevity buys nothing in information.

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 single-parameter read tool with a full annotation set and no output schema, an agent can plausibly call it — but it lacks the return-shape hint (eligible teammate list plus routing rules) and the required company scoping, both of which the schema does not supply. Adequate but with clear gaps.

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% for the single required parameter, so the description carries the burden and must explain that "company" is the tenant UUID scope. Instead it never mentions the parameter at all — the schema's uuid/pattern is the only clue, and the caller gets no explanation of whether the company id controls tenant scoping or is a filter.

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 concrete verb ("Read") with two named resources — eligible teammates and automatic routing — scoped to three workflows (new issues, plan reviews, human tasks). That is specific enough to know what the tool returns. It never names or distinguishes itself from the obvious siblings, summer_work_routing_update (the write counterpart) or summer_teammates_list (which also exposes teammates).

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?

There is no when-to-use statement, no mention of the paired mutation tool summer_work_routing_update, and no guidance on choosing this over summer_teammates_list when the agent needs teammate data. The agent must infer all routing decisions from the name alone.

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