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

With no annotations, the description carries the full behavioral burden and adds valuable caveats: task judgments have limits, the impact index is not a probability of job loss, and it always appears with confidence and assessment date. This meaningfully reduces misinterpretation, though it does not describe return shape or side effects.

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?

Two sentences with no filler, front-loaded with the core purpose. The second sentence earns its place by preventing misuse of the impact index and clarifying what the assessment does not establish.

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?

The description provides strong conceptual context about the assessment's content and caveats, which is important given no output schema or annotations. However, it omits parameter semantics, especially locale, and does not clarify the return structure, leaving an agent unable to confidently construct a correct call from the description alone.

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%, and the description never mentions slug or locale. It only implies that the slug identifies the occupation; locale semantics are entirely absent. The description does not compensate for the schema 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 opening phrase 'Full task-level assessment of one occupation' clearly identifies the resource and deliverable. It distinguishes get_occupation from the sibling find/search tools by emphasizing a single occupation's full task-level detail, though it does not name a specific alternative.

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?

No guidance is given on when to use this tool versus siblings like get_role_tasks or find_transition_paths. The description implies a use case, but it never states exclusions, prerequisites, or when an alternative would be more appropriate.

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