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

Annotations include readOnlyHint=true and idempotentHint=true, which the description does not contradict (the tool only returns information and asks questions, no mutation). The description adds valuable behavioral context beyond annotations: it explains the iteration loop (call again with answers), the coverage limitation (only certain states covered, others reported honestly as not yet covered), and the critical limitation that it 'never tells you whether you are compliant, only what to check.' It also discloses that company_name is recorded for analytics ('Median stores it to see which companies use this tool and may follow up' - a transparency plus). The only minor gap is it does not explicitly state that calling without answers will still return questions, but the iteration loop implies that. Given annotations cover safety, a 4 is appropriate for the rich added context.

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 a single substantial paragraph, which is dense but well-structured and front-loaded with the most critical instruction ('START HERE'). Every sentence earns its place: the entry-point directive, the iteration loop, the default view guidance, the state coverage limitation, and the compliance scope disclaimer. It is not verbose or repetitive, but it is long (over 150 words). For a tool with 21 parameters and high complexity, this length is justified. However, it could arguably be split into clearer sub-sections, but the narrative flow is logical. A 4 is appropriate for being appropriately sized, though it is on the upper edge of conciseness.

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?

Given the tool's high complexity (21 parameters, nested objects, no output schema), the description is remarkably complete. It explains the core behavior (returns obligations and questions), the iteration protocol, the default output format and when to deviate, the geographic coverage limitation, and the tool's non-verdict nature. It also implicitly explains the purpose of the 'answers' parameter in breaking the question loop, which is critical for successful use. The only potential gap is that it does not describe the exact format of the return value, but since there is no output schema, the description's statement that it returns 'compliance obligations... plus the specific questions' is sufficient for an agent to know what to expect. This is a model of contextual completeness for a complex 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?

The input schema already provides extensive descriptions for each parameter (95% coverage), so the baseline is 3. The tool description itself adds significant parameter-level guidance: it mentions the 'detail' parameter and when to pass 'full', it highlights 'payroll_model' as 'Critical' (though that is in the schema description), and it emphasizes the iteration behavior tied to the 'answers' parameter. Notably, the description references the 'answers' parameter's role in breaking the loop ('Without this the same questions repeat forever'). However, the most valuable parameter semantics live in the schema, not the description, so a 4 is fair given the description supplements rather than replaces the schema. The description's mention of 'detail' and the 'answers' loop are meaningful additions beyond 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?

The description is exceptionally clear: 'START HERE... return the federal and state compliance obligations... ordered by urgency with overdue items first, plus the specific questions that unblock the rest.' It names the verb (return/list), the resource (compliance obligations), the scope (federal and state, covering US plus 12 specific states), and the ordering behavior. It also differentiates from siblings by saying 'START HERE' and explicitly noting it is the entry point for the workflow, while siblings like explain_obligation, get_evidence_recipe, and list_books_checks serve downstream needs. The purpose is unambiguous and distinct.

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 provides explicit when-to-use and when-not-to-use guidance: 'Call it immediately with partial facts rather than interviewing the user first' and 'it is designed for incomplete input.' It instructs the agent to iterate: 'Then answer those and call it again.' It also specifies when not to use certain parameters ('pass detail='full' only when the user asks for evidence tiers and remediation detail') and names alternatives ('Prefer staying brief and calling get_evidence_recipe or explain_obligation for the one or two items that actually matter'). This is exemplary usage guidance, far exceeding the minimum.

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