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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description goes further by disclosing the substantive counting rules, the 20% manual-share and 541-exemption logic, and even flags that this reflects "this server's reading" of the rules. That interpretive disclosure is valuable, but it says nothing about output shape beyond prose, limiting it to a 4.

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?

Every sentence carries substantive regulation-derived content with no filler, and the regulatory basis is front-loaded. The second sentence is an extremely dense run-on that nests multiple conditions, which strains readability, keeping it from a 5.

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 no output schema, the description must carry the return semantics, and it does describe the three things the tool reports. Input semantics are fully covered by the schema, and annotations cover safety, so an agent has what it needs; only a cleaner statement of the return structure is missing.

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%, so baseline is 3; the description nonetheless adds real meaning by mapping role values to the counting rule (laborers/mechanics/apprentices count; supervising foreperson, exempt 20%+ owner, office staff do not; working foreperson over 20% manual duties does). This links the enum choices to the legal test rather than restating them.

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 states a precise verb and resource — counting whether an employer hits the four-worker threshold that triggers the apprentice requirement (26 CFR 1.45-8(d)) — and enumerates what the tool returns (who counts, whether an apprentice is required, whose hours leave the denominator). It is far from a tautology, though it never names a sibling tool to contrast against, so it stops short of the top mark.

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?

It tells the agent what input to supply ("Give the people one employer used on this facility with their roles") and implies the goal is deciding whether an apprentice is required, which is useful context. But it gives no explicit when-to-use vs when-not, and does not route to check_apprentice_hours, check_daily_ratio, or other siblings that address adjacent questions.

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