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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds substantial behavior: TN reads a live State Apprenticeship Agency list returning program/occupation/employers/county, while other states return only pointers (apprenticeship.gov finder and a State office to contact). That output-shape divergence by state is exactly the kind of context an agent needs and cannot get from 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?

Purpose and legal grounding lead; the TN behavior, the non-TN fallback, and the text-matching caveat follow in dense clauses with no filler. Roughly 70 words, all of which carry 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?

With no output schema, the description still describes what comes back for each state branch and how filters behave, and annotations cover the safety profile. An agent has enough to call it correctly and interpret the result.

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 the baseline is 3, but the description goes beyond it by disclosing that occupation is matched as free text rather than an enum ('"electric" finds Electrician programs') and that counties narrow results with an all-state default. That matching semantic is not derivable from the 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?

States a specific verb and resource ('Find registered apprenticeship programs'), names the legal basis (26 CFR 1.45-8(f)(1)), and defines the qualifying criteria (area covers facility, trains the occupation). An agent can distinguish this from siblings like check_good_faith_request or check_apprentice_hours without opening a schema.

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?

Places the tool in context ('a contractor can send a good-faith request to'), implicitly routing agents here before the good-faith-request workflow, and explains the state-dependent behavior. It does not explicitly name an alternative tool or state when NOT to use this one, so it stops short of a 5.

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