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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description earns credit for adding that this is a public endpoint returning English natural-language text with preserved sources, conditions and pagination. That return-shape and sourcing context goes beyond the structured hints.

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 tight sentences with no filler; the inclusion list and exclusion clause are front-loaded before the endpoint-behavior note. Dense but readable, and every clause carries 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 partially compensates by describing the return format (English natural-language text, preserved sources/conditions/pagination), and annotations plus 100% schema coverage carry the rest. A little more on return structure or an explicit sibling routing would make it fully complete.

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 100%, so both the occupation and locale parameters are already well documented in the schema, including the exact-match precedence rule and enum semantics. The description adds nothing further about parameter behavior, so the baseline 3 is appropriate.

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 gives a specific resource ('occupation basic facts') and enumerates its contents (identity, ANZSCO version, names, tasks, skill level, lists, shortages, assessing authority references). It clearly distinguishes itself from content-bearing siblings like get_occupation_courses and get_course_pathways by stating what it does not cover, though it never explains how it differs from the plain get_occupation sibling.

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?

Usage is only implied through the exclusion clause 'Does not fetch assessment pathways, courses or other topics', which signals when-not-to-use without naming the alternative tools that should be used instead. No explicit routing (e.g. 'use get_course_pathways for...') is provided, so an agent must infer the boundary.

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