One U Education

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the bar is lower, and the description still adds substantial behavioral context: the four possible verdicts (next round, later round, not within the 24-month EOI life, stalled), the returned artifacts (estimated month, fast/slow scenarios, EOIs ahead, wait at other points scores), and that sources/conditions/pagination are preserved. The only blemish is that it declares "returns English natural-language text" while the locale parameter defaults to zh-CN/Simplified Chinese, a minor internal tension rather than an annotation contradiction.

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, front-loaded with the core purpose before inputs and return behavior, and every clause carries information (model provenance, inputs, verdict set, return format). It is dense but not padded; slightly long sentences keep 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 carries the burden of explaining returns and does so concretely (verdict categories, estimated month, fast/slow scenarios, EOIs ahead, cross-score waits, natural-language format). Combined with required inputs and the model's provenance, an agent has everything needed to call and interpret this tool correctly.

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 the schema already documents all five parameters in detail (locale enum, points range, YYYY-MM patterns, occupation code resolution rules). The description only restates the occupation and points inputs and gestures at the EOI date of effect, adding essentially no meaning beyond what the schema provides. 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?

States a specific verb and resource ("Estimate when a subclass 189 EOI could be invited") and names the exact model behind it (One U Education's queue model, same as oneuedu.com's predictor). This is distinguishable from the sibling get_189_invitations (actual invitation data) and get_eoi without opening either schema, since the description makes clear this is a forward projection, not a record lookup.

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 inputs to supply (internal occupationCode, points, optionally EOI date of effect) and points back to search_occupations for resolving the code, which is real usage guidance. However it never states when to prefer this over get_189_invitations or get_eoi, nor any exclusions or prerequisites (e.g., only relevant to subclass 189 EOIs onshore/offshore). Usage is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful context beyond them: it is a public endpoint (no auth), returns natural-language text rather than structured data, preserves sources and conditions, and handles pagination.

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?

Front-loaded with the core resource and delivered as a single dense sentence that lists the returned fields efficiently. It is a run-on comma-separated enumeration, but no sentence is wasted and nothing is buried mid-paragraph.

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 describe return values, and it does so thoroughly: round-level records, current pool, announced next round, and a frozen forecast, plus format, sources, conditions and pagination. The main gap is the absence of routing guidance relative to the sibling forecast 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?

Schema description coverage is 100%, covering both occupation (internal code/slug with precedence rules) and locale (enum with default and URL-prefix effect). The description adds no parameter-level detail beyond this, so the schema carries the full burden and baseline 3 applies.

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 (get) and resource (subclass 189/491 invitation round history for one ANZSCO occupation), then enumerates the exact data returned: round dates, invited status, points cutoffs, pool size, next round date, and forecast. The resource is clear, but it never names the closely related sibling estimate_189_invitation, so the boundary between the historical record and the forecast tool is left implicit.

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 says nothing about when to use this tool versus alternatives, nor any prerequisites. It does not mention estimate_189_invitation or explain whether history and forecast should be fetched together, leaving the agent to infer usage from the content list alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it explains the gating behavior of unlockCode (prices hidden without it, retail/settlement/profit fields added with it) and the shape of the response (English natural-language text, pagination preserved). It stops short of noting freshness/caching or error behavior for a bad code.

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 product scope are front-loaded, and the unlock-code caveat follows logically. The prose is dense and slightly repetitive about what the code unlocks, but nearly every clause carries information an agent needs.

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 correctly compensates by describing the return payload (natural-language text, sources/conditions/pagination preserved) and the price-field structure. Given four optional parameters and an open-world read, the definition is complete enough to call correctly, though error/empty-result behavior is unspecified.

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 the baseline is 3; the description adds meaning beyond the schema by spelling out what the unlock code reveals per product and what each category value maps to in the product catalog. Query and locale semantics are left largely to 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 names a specific verb+resource (One U Education's service price list for partner agents) and enumerates exactly which products it covers: visa applications, school applications, short courses and extras. It also distinguishes itself from the sibling fee-lookup tools by stating these are service fees only, with government/third-party fees excluded.

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?

Clear context for use: partner agents retrieving One U Education pricing, with the unlock code only passed when the user supplied it in-conversation. It does not explicitly name alternatives (e.g. get_visa_fees) or state when-not to use it, but the fee-scope sentence implicitly routes government-fee questions elsewhere.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds two traits annotations cannot express: the read is of a saved snapshot (point-in-time semantics) and the error-model caveat 'A failed lookup is not an empty application,' which prevents an agent from misreading a failure as an empty record.

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?

Three short sentences with the purpose front-loaded and no filler; each sentence contributes either scope, timing, or error semantics. Minor cost: 'Forms' is capitalized as an external concept the description never defines, assumed to be obvious from the product context.

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?

An output schema exists, so return values need not be described. Given a single required ID, the description covers purpose, timing, snapshot semantics, and failure interpretation. What remains thin is the relationship to list_applications and where the taskId originates.

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 single parameter taskId carries only a UUID pattern. The description never mentions taskId, where it comes from, or whether it is the application/task identifier returned by list_applications. The param name is fairly self-evident, which keeps this above 1, but the description does not compensate for the coverage 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?

A specific verb-plus-resource: 'Read the saved safe snapshot of your application.' The 'saved safe snapshot' phrasing signals this returns a persisted, validated state rather than live data. It does not explicitly distinguish itself from the sibling list_applications, so an agent must infer that one is single-record and one is enumerating.

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?

Names two concrete trigger points: 'Re-read after returning from Forms or before preparing submission.' That is real, actionable timing guidance tied to sibling workflows (open_application_form, prepare_application_submission). It stops short of an explicit 'use X instead when...' exclusion against list_applications or update_application.

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

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.

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: subsequent pages require an unchanged contentVersion, unknown arguments and includeSimilar are rejected, website OAuth is required on the public endpoint, and the returned content is English natural-language text that preserves sources, conditions and pagination. These are exactly the operational traits an agent needs and are not derivable from the schema.

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?

Front-loaded with purpose, then defaults, then filters, then flags, then output character — a logical order with essentially no filler. It is dense to the point of being run-on in places (sections, nesting and rejection rules packed into one sentence), which slightly hurts scanability but not correctness.

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?

For a 13-parameter tool with nested objects and no output schema, the description covers the section model, pagination/versioning contract, authentication condition, argument rejection behavior, and the nature of the returned text. The main remaining gap is the exact accepted formats for the `course` value (code vs URL shape), which the schema leaves as a bare string.

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 low (31%), with only locale, studentType, includeEvidence and passportCountry documented, so the description must compensate. It does: it enumerates the selectable sections, states topic options must be nested under their chosen section, and names the filter axes for fees, requirements, intakes and campuses. It stops short of documenting every leaf field, so 4 rather than 5.

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 sentence gives a specific verb+resource ('Read CRICOS course topics') and the two accepted input forms (code or URL), plus the default section behavior. It implicitly distinguishes itself from search_courses by being the single-course read, but it never names a sibling tool outright, so it falls just short of 5.

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?

Strong operational guidance: default sections, replacement semantics ('explicit nonempty sections replace the default'), nesting rules, and concrete narrowing levers (fee years/audience, requirement topics, date/campus filters, pageSize). It lacks explicit when-to-use-vs-alternatives guidance (e.g. vs search_courses or the package/pathway siblings), so it is clear context without exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive. The description adds real operational context on top: the default and maximum page sizes, the contentVersion requirement for paging past page 1, that this is a public endpoint, and that it returns English natural-language text preserving sources, conditions and pagination.

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 dense sentences with the core action front-loaded and paging constraints second. No filler, though the second sentence packs several unrelated facts (public endpoint, language, source preservation) into one run-on.

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?

For a 5-parameter, output-schema-less read tool with 20% schema coverage, the description covers pagination well but omits what the 'course' identifier is, what 'packages' contain, and any hint of the return structure beyond 'totals and shared interpretation.' Adequate but with clear gaps.

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 only 20%, so the description must carry weight. It partially does: it explains pageSize bounds, the page>1 contentVersion rule, and the locale's effect via schema. However, the required 'course' parameter (just a 4-char string) and contentVersion format are never explained, leaving the most important input under-defined.

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 ('Read complete packaged study plans in study order, with totals') and adds scope details (totals, shared interpretation). It is distinguishable from get_course and get_course_pathways, though it never names a sibling explicitly.

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?

Provides procedural conditions (default pageSize 5, max 20, page > 1 requires the original contentVersion) that imply usage context, but never says when to choose this over get_course, get_course_pathways or search_courses. Guidance is implied rather than comparative.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is lower, and the description does add genuine operational context: pageSize cap of 20, the rule that page > 1 requires the original contentVersion, and that responses are natural-language text preserving sources and conditions. However, its claim that the endpoint 'returns English natural-language text' sits awkwardly against the schema's locale default of zh-CN, which could mislead an agent about output language.

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?

Three sentences, no gross padding, and the pagination constraints are usefully front-loaded after the first clause. But the opening phrase 'without full migration policies' is confusing filler that spends space without adding meaning. Structure is adequate rather than tight.

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?

For a 5-parameter tool with 20% schema coverage and no output schema, the description covers pagination and return-format basics but omits the meaning of the required 'course' parameter and leaves the migration-policy scope undefined. An agent can call it, but not confidently predict what it receives.

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 only 20% (only 'locale' is documented), so the description must compensate. It does clarify pageSize's default/cap and the contentVersion prerequisite for paging, which adds real meaning, but it says nothing about the required 'course' parameter or the page/record relationship. Partial compensation, not full.

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 verb 'Read' plus the resource 'associated occupations' gives a rough sense that this returns occupations linked to a course, but 'without full migration policies' is opaque and never states what the association is. It does not distinguish itself from sibling tools like get_occupation_courses or get_course, which likely expose overlapping data. Minimum-viable clarity with real ambiguity.

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?

There is no statement of when to choose this tool over get_course, get_occupation_courses, or get_course_packages. The only contextual clue is that it is a 'public endpoint,' which does not help an agent route between siblings. Guidance is effectively absent.

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

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

With annotations already covering the safety profile, the description adds substantial unannotated behavior: anonymous access is capped to the latest published month plus two calendar months, earlier months need OAuth with mcp:read, counts below twenty are suppressed, state categories overlap, 189 has no state distribution, and each request reads the currently published data. These are exactly the traits an agent cannot infer from readOnly/openWorld 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?

Front-loaded with purpose before mode details, and no sentence is pure filler. It is dense and runs long for a single paragraph, but each clause (access tiers, suppression, pagination limits) carries functional 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 must characterize the return, and it does: English natural-language text with preserved sources, conditions and pagination, plus per-view result caps (six months, fifteen categories) and suppression rules. Nothing needed to invoke it correctly 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 high (89%), so the schema already carries most parameter meaning; the description reinforces which params pair with which view (history→fromMonth/toMonth, distributions→page) but adds little syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a precise verb+resource ("Read SkillSelect EOI data") and enumerates the exact scope (subclasses 189/190/491 state nomination, four view modes), so the agent knows precisely what the tool returns. It stops short of naming any sibling tool (e.g. get_state_nomination or get_189_invitations), so differentiation is implied by topic rather than stated.

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 maps each view to its preconditions (points/states require occupation and month; history needs fromMonth/toMonth; distributions need page) and gives real operational routing ("Preserve the other filters when continuing, and stop when the user's question is answered"). But it never says when to pick this tool over the many sibling nomination/invitation tools, and no exclusions are given.

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

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

Annotations already declare readOnly, idempotent and open-world, so safety is covered. The description adds real behavioral context beyond that: topics load only as requested and in parallel, missing data/failures are surfaced explicitly, and output is prose rather than structured JSON.

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?

Front-loaded with the key facts (sections, parallel loading, EOI/courses scope), but the final three sentences repeat the same claim about English prose and preserved sources/conditions/pagination, which is redundant padding that could be cut to one sentence.

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 carries the return-value burden and does so: it specifies English prose, identity, source links, and explicit missing-data/failure signaling. It is nearly complete, but does not describe response size or how the multi-topic result is keyed.

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 67% and the schema already documents locale and occupation well. The description still adds meaning the schema cannot: that eoi spans visas 189/190/491 and courses return the first 8 recommendations, which clarifies what each section value actually yields.

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?

Opening phrase 'Multi-topic occupation query' states a specific verb+resource, and the sections list defines exactly what topics are retrievable. It partially differentiates from siblings by noting standalone tools exist for finer control, though it never names which sibling covers a single topic.

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 gives one clear routing rule — 'For pagination or detailed topic filters use the standalone tools' — which tells the agent when to leave this tool for a sibling. It stops short of stating the positive condition (use this when you want several topics at once), so guidance is present but not fully symmetric.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new context: the endpoint is public, returns natural-language text preserving sources, conditions and pagination, and carries an explicit eligibility disclaimer. The 'returns English natural-language text' phrasing sits awkwardly against a locale param that defaults to zh-CN, which slightly muddies the behavioral picture.

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?

Front-loaded with the resource and returned fields, then features, disclaimer and routing in a compact sequence. Each sentence carries a distinct piece of information, though the public-endpoint/natural-language sentence is the least clear and could be tightened.

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 usefully names returned content (courses, tuition, URLs) and mentions pagination. For a paginated list endpoint with a required occupation plus locale, this is nearly complete; it could say more about how paging interacts with the occupation scope.

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 50%: locale and occupation are documented in the schema, page and pageSize are not. The description's only contribution is 'Supports page and pageSize,' which restates the param names without adding format, default or range semantics, and it never addresses the occupation parameter. Baseline 3 is appropriate since the description does not compensate for the coverage 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?

States a specific resource and scope: 'Published courses linked to one occupation, with tuition and course URLs.' It distinguishes itself from get_course explicitly ('Use get_course for course details') and from other occupation tools by scoping to courses, so an agent can select it without opening a sibling 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?

Provides a clear routing rule to a specific alternative ('Use get_course for course details') and a scope caveat (not a guarantee of registration, skills assessment or visa eligibility). It stops short of saying when to prefer this over search_courses or get_occupation_visas, so it is context-rich but not exhaustive about alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context, and it does: it is a public endpoint, it returns English natural-language text, it preserves sources/conditions/pagination, and it explicitly does not infer eligibility or employer offers. Pagination behavior and the no-inference boundary are genuine additions beyond the 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?

Three dense sentences with no filler; the resource scope comes first, then the behavioral guarantees, then the return characteristics. The opening clause is slightly roundabout but nothing is redundant.

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?

There is no output schema, so the description must describe returns, and it does reasonably: agreement counts, match types, concessions, preserved sources and conditions, and pagination. The one gap is that it never tells the agent that a valid occupation code must be obtained from search_occupations before calling, which matters given the tool's only required parameter.

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%, including a detailed occupation description explaining internal code vs URL/slug precedence and an enum-documented locale, so the baseline is 3. The description adds no parameter-level detail beyond restating that agreements are occupation-linked, leaving the schema to carry the full burden.

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 names a specific resource: occupation-linked labour agreement types, plus the DAMA summary as a separate source. It is distinguishable from get_state_dama_agreements by explicitly calling out the DAMA summary as an additional source rather than the primary subject. The 'same ... as the website' framing is a slightly vague anchor but the resource and its scope are clear.

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 implied by the name and by the scope boundary 'does not infer eligibility or employer offers', which tells the agent this is a reference lookup rather than a decision tool. However, it never states when to choose this over siblings like get_state_dama_agreements or get_occupation_visas, nor any prerequisite such as needing an internal occupation code first.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: it includes negative and unknown results, is a public endpoint, returns English natural-language text, and preserves sources, conditions and pagination. Return format and pagination handling are not detailed further, keeping it out of the top band.

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?

Four sentences, front-loaded with the core purpose and scoping, then filter behavior, then exclusions. Every sentence carries information, though the opening sentence's stacked list of statuses/conditions/exemptions is dense and slightly harder to parse than necessary.

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?

There is no output schema, so the description bears the burden of describing returns; it does so at a high level (natural-language text, negative/unknown results included, sources and pagination preserved). Combined with full schema coverage and full annotations, an agent has enough to call it correctly, though the exact response shape remains only loosely specified.

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 the baseline is 3. The description adds real semantic value by stating that omitting visaSubclass returns all options, which the schema does not spell out, and by framing results as partitioned per visa stream. It does not, however, add anything for locale or occupation beyond what the schema already documents.

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 resource and scope: occupation-level visa applicability broken down by visa stream, including statuses, mandatory assessment conditions and exemptions. It explicitly differentiates itself from nearby siblings (get_visa_fees, get_visa_processing_times) and rules out personal eligibility, so an agent can distinguish it without opening any 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?

Gives clear routing: optional visaSubclass narrows results, omitting it returns all, and fees/processing times live in separate tools. It also warns that this does not establish personal eligibility. It stops short of full when/when-not guidance relative to siblings like get_occupation or get_state_nomination_occupations, but the routing context is strong.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), yet the description still adds real behavioral detail: schools are matched by postcode text, deduplicated by school code, unranked by distance, and may include closed campuses. It also discloses the response form (English natural-language text, sources and conditions preserved, pagination present) and a scope limit on the classification.

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?

Three sentences, front-loaded with the core purpose, then deduplication semantics, then response format. Every sentence carries usable information, though the density makes it slightly heavy for a two-parameter lookup.

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 carries the return-value burden and does so reasonably well (content type, deduplication, pagination, caveats). Minor gaps remain: it never states what the 'Category 2/Category 3' values mean or whether results can be empty for a valid postcode.

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% and both parameters (postcode pattern, locale enum with default) are fully documented in the schema. The description adds no syntax, format, or default information beyond that, so the baseline 3 applies.

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 (get localities/state, regional category, and schools for one Australian postcode) with explicit scope. It is clearly distinguishable from the bulk search sibling by its single-postcode scope, but it never names an alternative tool, so it falls short of full sibling differentiation.

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: the tool is a per-postcode lookup, and the schema (not the description) tells the agent to feed it a postcode from search_postcodes. The description offers interpretation caveats (not distance-ranked, may include closed campuses, classification is not visa eligibility) but no explicit when-to-use or when-to-prefer-another-tool guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description goes further with non-obvious domain behavior: gap subtotal excludes interview/placement fees, anonymous providers must stay locked, candidates are not auto-approved, and output is English natural-language text with sources/conditions/pagination preserved. No contradiction with the read-only 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 is front-loaded in the first clause, followed by quote behavior, fee caveat, guardrails, and output format – each sentence carries distinct information with no filler.

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 and seven parameters, the description usefully states the return language (English natural-language text), preservation of sources/conditions, and pagination, plus the quote caveat. It is nearly complete for a read tool, though the roles of the three undocumented ID/pathway parameters remain unaddressed.

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 57%: slug, gapUnits and residency are described inline, but pathway, onlineTierId and providerPublicId are undocumented. The description adds partial meaning by naming the RPL/gap/online price dimensions (mapping loosely to pathway) and the fee-exclusion rule, but it does not explain how to obtain or use the undocumented identifiers, so it only partially compensates.

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 opens with a specific verb ('Read') and enumerates the resource contents: qualification requirements, risks, sources, public providers, and RPL/gap/online prices. Keying on 'exact slug' signals a single-record lookup, though it never names the sibling search_rpl_qualifications that produces the slug (that link only appears in the 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?

It states that optional selections yield an indicative quote and that missing choices stay explicit, which implies partial-input behavior. However, it never says when to call this versus search_rpl_qualifications, nor which optional parameters are required for a full quote – usage is inferred rather than spelled out.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive semantics, so the bar is low; the description still adds real context by stating this is a public endpoint (no auth), that results are English natural-language text, and that sources/conditions/pagination are preserved. The pagination and 'preserving sources' phrasing is vague and unexplained, keeping it short of a 5.

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 definition is front-loaded with the tool's identity and scope, then the use case, then output characteristics — a sound order with no repeated content. The first sentence is a long field laundry list, and 'preserving sources, conditions and pagination' is loose phrasing, but nothing is outright filler.

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 fully carries the burden of describing returns, and it does so comprehensively: identity fields, registration status/period, regulator, head office, all regulatory decisions with status/dates/review, and linked CRICOS schools with course counts. The only shortfall is that pagination behavior for decision lists is asserted rather than explained.

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 the schema already documents the accepted code/URL forms, the locale enum and the includeDecisionText toggle. The description only indirectly hints at the includeDecisionText effect via 'the original decision text' and adds no format or boundary detail beyond the schema — the baseline 3 applies.

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 opens with a specific verb+resource ('One Australian Registered Training Organisation (RTO) by RTO code') and then enumerates the exact fields returned, so the scope is unmistakable. It never names its closest siblings (search_rtos, get_rto_regulatory_actions), whose overlap with 'every regulatory decision' and with RTO retrieval is left for the agent to infer.

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?

'Use it to check whether a vocational provider is registered and in good standing' gives a clear intended use, which is better than nothing. But there is no routing guidance against search_rtos when the code is unknown, nor against get_rto_regulatory_actions even though this tool claims to return every regulatory decision — the agent is left to guess which to call.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive public endpoint, so the description does not need to restate safety. It adds useful behavior beyond annotations: newest-first ordering, aggregate totals before individual decisions, returned fields, pagination, and natural-language source preservation.

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 front-loaded with the core purpose and decision types, then output details, then a usage example. It is somewhat long and repeats the decision-type list already present in the schema, but the structure remains clear and largely earns its length.

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 appropriately explains what is returned: totals, individual decisions, statuses, review stages, references, RTO status, and links. It also covers ordering, public access, source preservation, and pagination, leaving only minor parameter-level detail to the schema.

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 moderate at 67%, with enum descriptions for type and locale already doing meaningful work. The description repeats the type choices and mentions overturned review outcomes, but it does not add syntax or filtering semantics for page, pageSize, since, or excludeOverturned beyond what the schema provides.

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 specific verb and resource: regulatory decisions of one type across all Australian RTOs. It enumerates the decision types and gives a concrete example question, making it easy to distinguish from sibling RTO lookup tools such as get_rto or search_rtos.

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 clearly indicates the tool is for questions like 'which colleges had their registration cancelled recently' and explains the default decision type. It does not explicitly say when to use sibling tools instead, but the context is strong enough for correct selection.

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

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

Annotations already cover readOnly/idempotent/openWorld, and the description adds genuinely new behavioral context: evidence reads require a website account on the public endpoint while the internal API-key endpoint reads it directly, no passport or student category is assumed, and the public endpoint returns English natural-language text preserving sources, conditions and pagination. That auth and output-format disclosure goes meaningfully beyond the 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?

The core purpose is front-loaded in the first sentence, and each subsequent sentence addresses a distinct concern (evidence flag, auth, defaults, locale, output format). It is dense and slightly repetitive in restating includeEvidence's default, but nearly every sentence earns its place.

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 5 parameters, no output schema, and 80% schema coverage, the description supplies the missing context an agent needs: auth requirements for evidence, the absence of default assumptions, locale behavior, and the shape of the response (English natural-language text with sources and pagination). Only explicit sibling routing 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 80%, so the schema already documents most parameters well. The description adds some value by stating that no passport or student category is assumed (relevant to the defaultless passportCountry and studentType) and that locale selects website links, but it adds little syntax or selection logic beyond the schema. 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 opens with a specific verb and resource ('Read school facts') and enumerates the returned domains: processing priority, campuses, dates and linked RTO. It clearly distinguishes the tool from a generic lookup, though it never explicitly contrasts itself with close siblings like get_school_campuses or get_rto, which also surface overlapping data.

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 implied rather than stated: includeEvidence defaults to false, and the account/API-key conditions are described. But there is no explicit when-to-use-this-vs-alternative guidance against the many sibling tools (get_rto, get_school_campuses, search_rtos), leaving the agent to infer routing.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower, and the description still adds real behavior: pagination caps (default 10, max 20), that continuation requires contentVersion, that counts/campusStates span the full filtered collection, and that output is English natural-language text with preserved sources. Return shape is partially disclosed but not fully.

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?

Front-loads the core purpose and ordering constraints, then packs filtering, paging and return-value notes into dense sentences with little waste. The final run-on sentence is heavy but every clause contributes new 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?

For a 10-parameter read tool with no output schema and near-zero schema documentation, it supplies the semantics needed to call it correctly: status behavior, filter meanings, pagination limits and continuation, and what counts/campusStates represent. Only a few parameters are left unexplained.

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?

With only 10% schema description coverage the description has to carry the load, and it does for the nontrivial parameters: status open/all semantics, state/postcode/regionalCategory filtering, pageSize default and maximum, and the role of contentVersion in continuation. It leaves school, courseCode and page to inference, which keeps it from a 5.

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?

Opens with a specific verb+resource ('Read school campuses') and immediately scopes it ('optionally limited to a course belonging to this school'), which is clearer than the bare title. It does not explicitly distinguish itself from sibling get_school or the search_* tools, so it stops short of a 5.

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 explains the semantics of status=open vs status=all and what each filter narrows, which implies usage. However, it never states when to prefer this tool over get_school or another sibling, and gives no exclusions or prerequisites beyond the endpoint being public.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), and the description adds genuinely new behavior beyond them: schedules are explicitly unavailable when not published, listed classes do not guarantee remaining seats, and output is English natural-language text with sources, conditions and pagination preserved. These are exactly the partial-result and caveat traits an agent needs.

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?

Front-loaded with the core action in the first clause and no filler sentences; the caveats are compressed into short statements. The final sentence about English text, sources and pagination is slightly dense relative to its value, keeping it out of the top band.

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 usefully sketches what comes back (dates, fees, provider/campus details, pagination) and what does not (unavailable schedules), so an agent knows what to expect. The claim that the endpoint 'returns English natural-language text' sits awkwardly beside a locale enum defaulting to zh-CN, leaving a small ambiguity about result language.

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 seoId and locale are already documented, including the enum values and URL language-prefix effect. The description only reinforces that seoId must be exact, which the schema already states, and says nothing new about locale; baseline 3 applies.

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 ('Get a published short course by exact seoId'), names the lookup key, and scopes the result (public provider/campus details, class dates, fees). An agent can distinguish it from sibling search_short_courses purely from the text.

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 'exact seoId' phrasing plus the schema note that seoId comes from search_short_courses implies this is a follow-up detail lookup rather than a search, and 'Read-only: use returned website links to apply' tells the agent what to do next instead of attempting a write. No explicit when-not or named alternative appears in the description itself, so it falls 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.

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavior: the 8-result cap, CRICOS rather than quality sorting, the international-student filter, the state/campus gating rule, and that no-candidate does not relax criteria. It omits return shape details, but for an annotation-covered read tool this is well above baseline.

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 candidate definition and state rule are front-loaded, which is good, but the text is telegraphic and the line 'No candidate does not trigger relaxation' is a confusing double negative that costs more than it conveys.

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 does note the return format ('English natural-language text, preserving sources, conditions and pagination'), which is helpful. Still missing are the semantics of the required course parameter and a clearer explanation of the relaxation behavior, leaving an agent under-informed on inputs.

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 33% (only locale is documented), so the description carries more burden. It compensates for state with the nationwide/eligibility rules, but leaves course entirely unexplained beyond the schema's minLength, and adds nothing to the already-documented locale.

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?

It states a specific verb and resource and pins down the candidate set ('up to 8 same-qualification/same-narrow candidates, open to international students, sorted by CRICOS'), which separates it from siblings like search_courses and get_course_pathways. However, 'same-qualification/same-narrow' is domain jargon and the description never names an alternative tool, so the differentiation is implicit.

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?

'Omit state for nationwide' and the state-eligibility rule give usable context for the state parameter. But there is no explicit statement of when to reach for this tool instead of get_course_pathways or search_courses, so usage is only implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the added value here is that it is a public endpoint returning English natural-language text with sources, conditions and pagination preserved. With no output schema, disclosing the return shape and pagination is genuinely useful. It does not mention rate limits or result-size characteristics, so 4 rather than 5.

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 authoritative scope are front-loaded in the first clause, and the operational guidance (occ, then occ+passportCountry) follows before the return-format note. Dense but every element carries information; the first sentence is long and parenthetical-heavy, which costs it the top mark.

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?

For a four-parameter, zero-required, read-only lookup with no output schema, the description covers what the tool returns, that access is public, that output is natural-language rather than structured, and how parameters compose. Only minor gaps remain (no guidance on what happens with an unknown authority, or result volume), so it is close to 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 the baseline is 3. The description goes beyond that by explaining parameter interaction: occupation alone resolves the authority and pathways, while occupation plus passportCountry determines which TRA streams (OSAP vs TSS) apply. That added relational meaning is real value the schema text does not supply.

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 (skills assessment rules for an Australian assessing authority) and immediately bounds the scope by naming the covered authorities (TRA, ACS, VETASSESS, Engineers Australia, etc.). It also enumerates the content dimensions returned (qualification, work experience years/hours/recency, English, fees, processing time, exclusions, misconceptions), so an agent can tell it apart from sibling lookup tools like get_occupation or get_visa_fees without opening the 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?

Gives concrete invocation guidance: 'Pass occupation alone to look up its authority and pathways' and 'with occupation (and passportCountry) says which apply,' which tells the agent exactly when the extra parameter changes the answer. It also notes the narrow TRA sub-case (MSA, PSA, Job Ready, OSAP, TSS). It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it falls just short of 5.

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

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context about public access, 20-per-page pagination, retained cross-state agreement types, and natural-language return text, though the claim of English natural-language text sits awkwardly with the locale enum supporting zh-CN and zh-TW.

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 four tight sentences with the scope constraint front-loaded. Every sentence adds useful filtering, exclusion, or return-behavior context without waste.

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 covers scope, exclusions, pagination, public access, and the general nature of returned text. It is sufficient for correct invocation, though it does not detail the response fields beyond sources, conditions, and pagination.

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 low at 33%, with only locale described in the schema. The description compensates by explaining employerState as employer location rather than policy region and by specifying 20 results per page, though page-number semantics and locale behavior are left largely to 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 states a specific resource and filter: DAMA employer agreement records filtered by employerState. It also distinguishes employer location from DAMA policy region, so an agent can tell what this list represents.

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 gives clear exclusions: it does not query regional eligibility, agreement occupations, or concessions, and it clarifies the employer-location scope. It does not name sibling alternatives, so it stops short of full when-to-use routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower; the description still adds real context: this is a public endpoint (no auth), returns English natural-language text, and preserves sources, conditions and pagination. It stops short of rate limits or error behavior, so it is strong but not exhaustive.

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?

Content is front-loaded (what it returns first, sibling routing next, endpoint behavior last) and short. A few telegraphic fragments ('program only filters briefs') are dense but not wasteful.

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 return-value burden; it does so by naming the returned units (allocation, used, remaining) and the response format (natural-language text with sources/pagination). For a 5-parameter, all-optional tool this is largely sufficient, though the shape of the program directory entries is only loosely characterized.

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 adds meaning beyond the schema: occupation is what triggers program-list matches and invitation records, and program 'only filters briefs' rather than full rules. These behavioral effects are not visible in the parameter descriptions themselves.

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 specific resource and scope: state policy overview plus exact 190/491 program directory including nomination places (allocation, used, remaining). It also names the two closest siblings (get_state_nomination_detail, get_state_nomination_occupations) and how they differ, so an agent can distinguish it without opening schemas.

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 explicitly routes to alternatives with conditions: 'Full policy is in get_state_nomination_detail; lists are in get_state_nomination_occupations,' and adds a caveat that 'program only filters briefs.' The boundary between this tool and its nearest siblings is stated, not inferred.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety bar is low. The description adds meaningful context beyond them: 'available means data was read, not verified, undisputed or personal eligibility', programRules returns one upstream compiled record, and the endpoint returns English natural-language text with pagination preserved.

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 core purpose is front-loaded, but the body is dense and semicolon-heavy, and several clauses restate the schema's program/visaSubclass guidance almost verbatim. Sentences are information-bearing but the length is at the edge of readability.

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?

For a read tool with no output schema and only 60% param coverage, the description covers prerequisites, scoping, section selection, and data-quality caveats. What remains thin is the exact shape of returned blocks per section, but that is largely optional for invocation.

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?

With 60% schema coverage, the description compensates well: it explains the identity-reuse rule for program/visaSubclass ('reuse the exact state/visaSubclass/program identity previously returned') and warns that user-provided pathway names are not verified API identities. It also gives per-section usage examples that the schema does not.

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 ('Read selected policy blocks for one state') and constrains it with 'sections is required and nonempty'. It is distinguishable from siblings like get_state_nomination and get_state_nomination_occupations, though it never explicitly contrasts itself against them by name.

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?

Gives explicit selection criteria ('start with the fewest blocks directly relevant...; fees for costs; application and policyNotes for state deadlines') and names the prerequisite alternative tool ('first call get_state_nomination_occupations without program'). It also states when program/visaSubclass are required vs omitted and how they scope programRules only.

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

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

Annotations already establish a safe read (readOnlyHint, idempotentHint, non-destructive, openWorld), and the description adds genuinely new behavioral facts: page has no meaning in directory mode, 40 records per page, a list match is not personal eligibility, unknown projects error while empty known lists return no_data, and output is English natural-language text with sources and conditions preserved.

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?

Three dense sentences with no filler, and the mode split is front-loaded so an agent immediately knows which branch applies. It is on the packed side, but each clause carries operational meaning rather than restating the name.

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 carries the return-shape burden and does so: pagination size, English text output, preserved sources/conditions, and the empty-vs-error distinction. Combined with the mode split and the parameter caveats, an agent has everything needed to call it correctly.

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 low (~40%), so the description must compensate, and it does for the two hardest parameters: it explains that page is meaningless in directory mode, and that program must be an exact previously-returned API identity rather than a user-supplied pathway name. It does not add anything for visaSubclass beyond the conditional that pairs it with program.

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 names two specific verbs and resources: discovering a state/visaSubclass/program directory, and reading one official or national baseline occupation list. The dual-mode framing makes the tool's job unambiguous, though it never names the nearby siblings (get_state_nomination, get_state_nomination_detail) to sharpen the boundary.

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 gives an explicit conditional: use without program for directory discovery, and with program + visaSubclass to verify identity and read one list. It also states the error semantics (unknown projects are errors, empty known lists are no_data). What is missing is any reference to the sibling tools it should be chosen over.

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

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

Annotations already establish read-only, idempotent, non-destructive and open-world, and the description adds genuinely new facts: offer cases are excluded, the case url is included, the case is public/anonymised, and it warns that an individual case does not predict another applicant's outcome. The closing sentence about 'this public endpoint returns English natural-language text... pagination' is muddled for a single-record fetch and sits awkwardly against the locale parameter, which weakens an otherwise informative disclosure.

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 first sentence is long but well front-loaded, putting the verb, resource and identifier source first. The trailing sentence about 'English natural-language text, preserving sources, conditions and pagination' reads as boilerplate that adds little for a single-case lookup and actively introduces ambiguity about locale and pagination.

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?

There is no output schema, so the description carries the return-value burden and does so by naming the fields an agent will get (highlights, duration, advisor, canonical link, case url) and by stating the offer-case exclusion. The locale/English-language ambiguity is the one real gap for a tool whose only optional parameter changes language and URL prefix.

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%, with both id (public id, not internal caseId) and locale (zh-CN default, en-US, zh-TW, also selects URL language prefix) fully documented in the schema. The description reinforces the public-id requirement but never addresses locale, and the claim that the endpoint 'returns English natural-language text' is in tension with a default of zh-CN, leaving the agent to trust the schema over the prose.

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?

Specific verb ('Get') plus a precisely scoped resource: the full published, anonymised background of one successful 500/600/485/820 visa case, keyed by public id. It enumerates what the payload contains (highlights, processing duration, advisor, canonical link) and explicitly points at sibling search_visa_cases as the id source, so it is instantly separable from that tool.

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 the precondition (id must be the public id obtained from search_visa_cases, not the internal caseId) and a scope exclusion (offer cases are excluded). It stops short of an explicit 'when not to use' or a statement of behaviour when the id is unknown/invalid, so it is clear context rather than full routing guidance.

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

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

Annotations already cover the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds genuine context: output is Markdown with source links and retrieval date, every source record is returned without merging, and the endpoint is public and paginated. This goes meaningfully beyond what the annotations declare.

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?

Front-loaded with the core purpose and generally dense, with most sentences earning their place. The final sentence partially restates the earlier English-text point, a minor redundancy rather than bloat.

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 carries the return-value burden and does so: Markdown descriptions, source links, retrieval date, English natural-language text and pagination. Combined with the language-handling and no-merge notes, an agent has enough to call it correctly.

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 50%, with the code parameter undocumented beyond its pattern. The description compensates by reinforcing the four-digit code semantics and by clarifying the locale semantics ('English is official source text; Chinese is translated'), which adds authority nuance beyond the schema's URL-prefix explanation.

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 with scope: 'Get complete Markdown descriptions for one four-digit visa condition number.' The 'one four-digit' phrasing implicitly separates it from a search, but it never names the obvious sibling search_visa_conditions, so an agent must infer the exact-lookup vs search distinction.

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?

Adds a real usage constraint ('Do not select or merge variants') and scope exclusions ('not a personal visa record or eligibility assessment'), which steers the agent away from misuse. However, it never names an alternative tool or states the condition under which a sibling (e.g., search_visa_conditions) should be chosen instead.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real value beyond them: the provenance ('current visa pricing' official table), the currency (AUD), the output surface (English natural-language text preserving sources and conditions), and the existence of pagination.

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?

Front-loaded: the fee components an agent needs to know are in the opening sentence, followed by source/currency and then return-format notes. It is dense and slightly run-on, but every clause (stream list, AUD, plain-text output, pagination) carries information rather than filler.

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 correctly carries the burden of describing the return shape: it enumerates the fee components returned, states the format is natural-language English text, the source, the currency, and that pagination applies. It stops short of covering failure modes (invalid or non-existent subclass) or data-freshness caveats, but is otherwise sufficient to call the tool correctly.

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 the schema already explains both `locale` (enum + default + URL-prefix effect) and `visaSubclass` (pattern, accepted forms, '491F' normalisation). The description adds nothing per-parameter, so the baseline of 3 applies.

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 names a very specific resource — Department of Home Affairs visa application charges for one visa subclass, broken into stream-level components (main applicant, additional applicant 18+/under 18, non-internet charge, second instalment, STAC) — which leaves no ambiguity about what is returned. It never explicitly names or contrasts a sibling (e.g. get_visa_processing_times or get_agent_pricing), so differentiation is inferential rather than stated.

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 implied by the resource name and the note that it is a public endpoint, so an agent can reasonably tell this is a read-only fee lookup. However, there is no explicit when-to-use guidance, no statement of preconditions (e.g. subclass must exist), and no pointer to the sibling tools an agent might confuse this with.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds real behavior beyond them: zh-CN/zh-TW return Chinese names alongside official English in nameEn/streamEn, Home Affairs notes stay in English, and the endpoint preserves sources, conditions and pagination. It stops short of describing rate limits or result sizes.

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?

Three dense sentences that are front-loaded with the core purpose, then the parameter, then the locale/output behavior. Every sentence carries information, though the closing sentence about 'English natural-language text, preserving sources, conditions and pagination' is slightly loose.

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 carries the return-value burden and does so: percentiles, per-subclass/stream breakdown, publication date, and localized name fields. Annotations cover the safety profile, so the definition is nearly complete for a two-parameter read 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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not spell out — that omitting visaSubclass lists every subclass and includes Home Affairs notes, and that locale governs name language plus the URL prefix. That is genuine added meaning over the enum and pattern.

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 precise verb+resource: Home Affairs global visa processing times broken down into 25/50/75/90% finalisation day counts per visa subclass and stream, plus the Home Affairs publication date. This is unmistakably distinct from siblings like get_visa_fees or get_visa_condition, so an agent can route without opening any 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?

Explicitly describes both invocation modes: pass visaSubclass for a single visa (returned with Home Affairs notes), or omit it to list every subclass. That is clear operational context, though it does not name any alternative tool or state when a different tool should be preferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description still adds real context beyond that: it is a public endpoint, the output is English natural-language text, and sources, conditions, and pagination are preserved. It does not say whether an empty result is possible or how many advisors are typically returned, keeping it below 5.

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?

Front-loaded with the resource and the site-panel analogy, with the trigger condition and parameter hint following in logical order. The parenthetical enumerating returned fields and contact channels makes the middle clause dense but it is informative rather than filler.

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 carries the return-value burden and does so adequately: it names the fields returned, the contact channel per language (WeChat Work for Chinese, WhatsApp for English), the topic-based 'recommended' ordering, and pagination/source preservation. Combined with the fully documented schema, an agent has what it needs to call and interpret this 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?

Schema description coverage is 100% and all four enums are documented in the schema, so baseline is 3. The description's only parameter-level addition is that passing topic and studentLocation surfaces site-recommended advisors first, which the schema's topic property already states in nearly identical words. No new syntax, format, or default semantics are contributed.

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+resource ('One U Education's advisors') and anchors identity to a concrete artifact the user knows (the 'talk to an advisor' panel on www.oneuedu.com). It also enumerates what each record carries (name, office, organisation, QEAC number, focus, contact channel), which cleanly separates it from the data-lookup siblings like get_rto or search_courses.

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?

'Use it when the user wants to talk to a person, a consultant or a specialist' gives a clear trigger condition, and 'Pass topic, and studentLocation for study topics' gives routing guidance. It stops short of naming any sibling or stating when NOT to use it (e.g. for course/visa data lookups), so it is clear context rather than full when/when-not coverage.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only has to add what they don't. "A failed lookup must not be treated as an empty list" is a genuine failure-mode warning not present in the annotations, but it is left cryptic — no indication of how a failure surfaces or what ordering/pagination to expect.

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?

Three short sentences with no filler, and the workflow cue is front-loaded. Slightly telegraphic in places, but nothing is padding.

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?

It is a one-parameter read-only tool with an output schema, so the bar is low and the failure-mode caution covers the riskiest inference. Still, the description never explains what status selects, whether results are scoped to the current user, or how multiple results are ordered.

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 single required parameter status (enum: collecting/completed/abandoned) is never mentioned in the description. The only hint is "saved applications," which is ambiguous about whether abandoned or completed applications are included — the enum values do not resolve that on their own.

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?

"Recover your saved applications" names a resource and an action, but the verb is metaphorical where the tool is really a filtered list. Nothing distinguishes it from the sibling get_application, and the required status filter that defines the query is never mentioned.

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?

"Before starting or resuming work" implies the surrounding workflow (open_application_form, restart_application), which is useful context. But no alternative is named and no when-not condition is given, so the agent must infer that get_application is the single-record counterpart.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld=false), but the description adds real value beyond them: no upstream dependency, safe to call once per conversation, a public endpoint, and that output is English natural-language text that preserves sources, conditions and pagination. Return-format disclosure is genuinely useful given there is no output schema.

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 is front-loaded in the opening clause and the remaining sentences cover usage and output without repetition. It is somewhat list-dense in the first sentence, but every item (category names, call cadence, output nature) earns its place.

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 parameters and no output schema, the description carries the return-value burden and does so reasonably, sketching the output as natural-language English text with preserved sources/conditions/pagination. The exact shape of the returned vocabulary is only loosely described, but for a static reference tool this is nearly 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool is 4. The description correctly adds no parameter detail, which is appropriate here.

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 role: a vocabulary/lookup that supplies valid filter values for search_courses, then enumerates the exact categories (states, cities, qualification groups, AQF level names, FOE codes, provider/education types, sort values, studentLocation). An agent can immediately tell this is a reference tool rather than a search tool, and it names the sibling it feeds.

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 upstream call; safe to call once per conversation" gives clear usage cadence and dependency guidance, and the phrase "Vocabulary for search_courses" implies calling it before search_courses. It stops short of an explicit when-to-use/when-not statement or naming an alternative, so it does not reach 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful behavioral context the annotations cannot: that this is a public endpoint, that results are natural-language labels rather than codes, and that sources/conditions/pagination are preserved. The phrase 'returns English natural-language text' sits awkwardly against the locale parameter, which offers zh-CN as the default, so the output-language claim is not entirely consistent.

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?

Three front-loaded sentences: what it returns, how to use the values, and the empty-list rule. Efficient, but the closing sentence is a residual clause mixing endpoint visibility, output format and pagination, which is slightly under-explained rather than wasteful.

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 carries the burden of characterizing the return value, and it largely does: filter categories, natural-language text, sources, conditions and pagination. It stops short of naming the exact response shape (e.g., how options are keyed or how pages are traversed), which is the only real gap for a read-only lookup 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?

Schema description coverage is 100% and both parameters are enums with their own detailed descriptions, including the locale side effect on returned URL prefixes. The description repeats the valid visaType values and adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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 ('Get available schools, advisors, subjects and age ranges'), scoped to one visa subclass with the valid subclasses enumerated inline. Nothing here overlaps with search_visa_cases or the other list_* siblings, so an agent can route correctly 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?

Explicitly directs the agent to feed the returned values into search_visa_cases 'rather than guessing IDs', which is a concrete precondition for the downstream call. It also supplies an interpretation rule for the edge case where a filter list is empty, so the agent knows what an empty result means rather than treating it as an error.

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

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

Beyond the annotations, it discloses important hosting constraints, hidden UI delivery requirements, credential-handling rules, and fallback behavior when the card is unavailable. It does not explain the implications of readOnlyHint=false or idempotentHint=false, such as whether opening the card changes saved state.

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 action and primary purpose distinction are front-loaded, and the security constraint is clearly stated. It is compact overall, though the specialized terms reduce immediate clarity and could be tightened.

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?

For a 3-parameter tool with an output schema, it covers the critical usage and security caveats an agent needs before invocation. The main gap is that the required taskId parameter is left unexplained and sibling-tool routing is not addressed.

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 description reinforces the purpose enum semantics and adds the 'specifically requested' constraint for contact, but it does not explain taskId at all. Schema coverage is 67%, and the locale parameter is described only in the schema, so the description only partially compensates for the remaining 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?

It states a specific verb (open) and resource (secure card / saved application form), and separates the two supported purposes. However, 'secure card' and 'hidden UI delivery' are jargon, and the description does not distinguish this tool from close siblings such as get_application or update_application.

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 explicitly covers when to use purpose=documents versus purpose=contact, including the stricter 'only when specifically requested' condition for contact. It does not name alternative sibling tools or give exclusions for the documents purpose, so a little routing guidance is missing.

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

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

The description says "Preparation changes nothing," which directly contradicts annotations declaring readOnlyHint=false. Although it adds useful details about no file copying and confirmation-card expiry, the contradiction with structured safety metadata is serious.

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 compact and front-loads the key precondition before explaining consequences. Each sentence adds relevant constraint or behavior, though some phrasing is terse and the title is not well aligned with the tool name.

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?

It provides useful behavioral context and an output schema exists, but it leaves all four input parameters undocumented and contradicts the readOnlyHint annotation. For a preparation/confirmation tool with expectedRevision concurrency semantics, this is incomplete.

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%, so the description must explain the four parameters, but it does not. It only refers conceptually to a "new intent" and does not clarify taskId, expectedRevision, locale, or initialIntent semantics.

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 specific action: binding a new application intent to a five-minute confirmation card after an explicit request to abandon the draft. It is fairly clear and distinguishable from a real restart, though it does not name the sibling restart_application explicitly.

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 gives an explicit precondition: use only after an explicit request to abandon the current draft and start an independent application. It also notes that changing the intent requires a new card, but it does not explicitly route the agent to restart_application or other alternatives.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false; the description adds genuinely new behavioral context — execution is deferred to the applicant clicking the card, and the state must be re-read after edits or revision conflicts. The unexplained 'hidden action' phrasing and the lack of detail on what state is persisted keep it from a 5, but it does not contradict the 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?

Four short sentences with no filler, and the critical 'This does not submit' safety point is front-loaded after the opening line. Density is good, though 'confirmation card' and 'hidden action' consume space without clarifying meaning.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. But for a state-changing handoff tool with 0% parameter coverage and opaque jargon, the description leaves how taskId/expectedRevision combine with the 'latest saved version' and what happens on revision conflict unresolved.

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% for both required parameters (taskId UUID, expectedRevision integer), so the description must carry the burden — but it only alludes obliquely to 'the latest saved version' and never explains that expectedRevision is a revision guard or how a mismatch should be handled. This is a meaningful gap for a 2-parameter tool with no schema documentation.

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 action (prepare a five-minute confirmation card for the latest saved version) and immediately distinguishes it from submission ('This does not submit'), which separates it from the submit_application sibling. However, jargon like 'confirmation card' and 'hidden action' is left undefined, so the exact artifact produced is not fully concrete.

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?

Gives situational guidance: re-read after Forms edits or conflicts, and clarifies the handoff target is an application specialist rather than a school application or acceptance. It does not explicitly name submit_application or restart_application as the alternatives, but the negative framing ('does not submit') effectively routes the agent away from them.

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

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

Annotations already declare destructive, idempotent, non-readonly and closed-world behavior, so the description adds real value by disclosing channel restriction (UI-only), account scoping, credential immutability, and the unknown-outcome retry protocol. It stops short of describing what exactly is discarded or what the response confirms, but the annotation coverage lowers the bar.

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?

Three short sentences with no filler, and the execution constraints are front-loaded. The telegraphic 'bound restart' phrasing costs some clarity, but every sentence 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?

Output schema and rich annotations cover returns and safety, but the description leaves three required parameters opaque and does not link to the apparent prerequisite tool that issues the action credential. For a destructive, credential-gated mutation, that is a material gap.

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%, so the description must explain all three required pattern-constrained strings. It clarifies only the credential ('unchanged action credential') and its retry behavior; taskId and actionId remain unexplained beyond their UUID patterns and the vague phrase 'bound restart'.

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 says it is a 'UI-only execution of a bound restart', which gives a verb and resource, but 'bound restart' is undefined jargon and the real effect ('abandon draft and start new application') only appears in the title. It never names the sibling prepare_application_restart that evidently produces the bound action, leaving the agent to infer the relationship.

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 supplies one concrete usage rule – retry the same credential after an unknown outcome – and restricts execution to UI-only and the current account, which implies a prerequisite bound action. However, it never states when to call this versus prepare_application_restart or open_application_form, nor any exclusions.

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

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

Annotations only declare non-read-only, idempotent, non-destructive; the description adds real operational context: retry behavior ('Reuse operationId after an unknown result'), consent rules, the account-email already initialized by authorization, and the client-UI precondition. Notably it clarifies that messages containing identity/contact info should not be rejected, which the annotations cannot express.

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 purpose is front-loaded, but the body is a dense run-on of policy sentences, several of which are conversational policy rather than invocation guidance (e.g. 'Do not ask again for an account email already initialized by authorization', 'Documents use Forms'). Each rule has intent, but the sentence 'Documents use Forms' is cryptic and several clauses could be tightened or moved to sibling tools.

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 an output schema present, return values need not be explained, and the description covers consent, retry semantics, and the web-entry precondition. The remaining gaps are the locale parameter and the precise content constraints on initialIntent.

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%, so the description carries the burden. It gives operationId real meaning ('Reuse operationId after an unknown result') and implies what initialIntent may contain ('supported basic text', tolerance for identity/contact information), but locale is never mentioned and content limits on initialIntent are only hinted at.

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 first sentence names a specific verb and resource ('Save ... course application intent') and is front-loaded before any policy text. It also distinguishes itself from the sibling update_application ('save it with update_application after creation') and from ordinary consultation. The phrase 'personal course application intent' is slightly abstract, which keeps it short of a 5.

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?

Explicit exclusions are stated: 'Never create during ordinary consultation' and 'Do not proactively solicit private details.' It also gives the alternative path (use update_application after creation) and the prerequisite for web entry ('requires a verified secure client UI; explain this limitation before saving').

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds genuinely new behavior: totalResults vs totalCapped vs reachableResults limits and the workaround, that results are English natural-language text preserving sources and conditions, that tuition is keyed to studentLocation, and the account requirement for evidenceLevel. This is behavioral context the annotations cannot convey.

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?

Front-loaded with the core verb and filter list, then pagination caveat, then alternatives. It is dense and one long paragraph with several semicolon-chained clauses, so a little more structure would help, but every sentence carries information an agent needs.

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?

For a 25-parameter, no-required-argument search tool with no output schema, the description explains the return shape (compact summaries, tuition, provider, page url, webUrl, totalResults), the pagination ceiling, the auth boundary, and the handoff to get_course. Nothing essential to correct invocation 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 the baseline is 3, but the description adds real meaning beyond it: minFee/maxFee are per-academic-year and compared against the same basis as fee_asc/fee_desc, studentLocation changes which tuition figure is authoritative, and evidenceLevel result handling (providerEvidenceLevel, evidenceLevelCheck) is described. Minor gaps remain (e.g., no guidance on combining degreeLevel and degree, which lives only in 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 (search CRICOS-registered Australian courses) plus the full filter vocabulary and what a result page contains. It clearly separates this from sibling get_course ('use get_course with explicit sections afterwards') and from option-discovery via list_search_options, so an agent can distinguish it without opening the 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?

Gives concrete routing: use this for keyword/filter discovery, then call get_course for the topics of a specific course, and split the search (by state, subject, schoolCode or fee range) when totalCapped is true. It also names a prerequisite condition for evidenceLevel (requires an account on the public endpoint) and states which filters are public.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety burden is light. The description adds real value beyond that: it discloses the return shape (occupationCode, shared anzsco, optional name, list membership, shortage flag, page URL), pagination behavior, and that this is a public endpoint returning English natural-language text with sources and conditions preserved.

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?

Front-loaded with purpose, then query modes, then the sibling-routing block. Efficient overall, though the long enumeration of alternative tools and the list/visa-subclass restatement make it denser than strictly needed given the schema already carries those enumerations.

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 compensates by naming the returned fields and pagination. Combined with the fully documented parameters and the annotations' safety profile, an agent has everything needed to call and interpret this tool correctly.

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 page, locale, keyword, visaSubclass and occupationList are already fully documented with examples and enum meanings. The description only restates the filter concepts (lists, visa subclasses) and adds no syntax or format detail beyond the schema; baseline 3 is correct.

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 (Search) plus resource (Australian skilled occupation database / ANZSCO codes) and enumerates the query vectors (name keyword or code) and filters. It also names the sibling tools it is not (get_base_occupation, get_occupation_visas, get_occupation, etc.), so an agent can distinguish it without opening any 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?

Explicit routing: 'Use get_base_occupation for basic facts; get_occupation_visas, get_skill_assessment_rules, get_189_invitations, get_eoi or get_state_nomination for a specific topic' and 'get_occupation requires explicit sections for multi-topic queries.' When-to-use and alternatives are both stated, leaving nothing to inference.

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

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

Annotations already cover readOnly/idempotent/openWorld/non-destructive, but the description adds real behavioral context: Delivery Area localities only, postcode/name ordering, multiple localities per postcode, and that the public endpoint returns English natural-language text with pagination preserved. The phrase 'preserving sources, conditions and pagination' is vague enough to leave some ambiguity.

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?

Front-loaded with purpose and searchable keys, then routing, then return characteristics. All sentences earn their place, though the closing clause about 'sources, conditions and pagination' is compressed to the point of being cryptic.

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 and 4 parameters, the description supplies what matters most: what is returned (Delivery Area localities, ordering, multiple per postcode), pagination existence, locale effects, and sibling routing. It does not describe page/pageSize limits or empty-result behavior, leaving a small gap.

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 50%: query and locale are documented in-schema, while page and pageSize have no descriptions in either place. The description reinforces query (postcode/locality name) and implies paging behavior, but adds little that the schema does not already say, so 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?

States a specific verb (Search) and resource (website postcode directory) plus the searchable keys (postcode, English/Chinese locality name). It explicitly distinguishes itself from two near neighbors: get_postcode and the course-campus postcode filter, so the agent can select it without opening the 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?

Gives clear routing: use get_postcode for regional classification and associated schools, and explicitly notes this is not the course-campus postcode filter. No explicit statement of when-not to use this tool beyond that negative, so it falls short of a full alternative map.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs to add context, which it does: it discloses that this is a public endpoint returning English natural-language text, that sources/conditions/pagination are preserved, and that gap/online prices require detail checks. It stops short of describing result shape or pagination mechanics.

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?

Four compact sentences, front-loaded with the action and immediately followed by usage routing and output caveats. Dense but nearly every clause carries a distinct instruction; slightly compressed wording costs it nothing significant.

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?

For an 8-parameter, zero-required search tool with no output schema, the description supplies the missing pieces an agent needs: result nature (candidates not verdicts), language of results, source/condition preservation, and pagination. Minor gap is no mention of how page/pageSize interact or a default result size.

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 50%: locale, hasPrice, industry and residency are documented in-schema, while page, pageSize, keyword and pathway are not. The description adds useful semantics for pathway options (RPL/gap/online) and the residency labelling of prices, but does not clarify the paging or keyword parameters.

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 candidate qualifications') and enumerates the searchable axes (code/name, industry, pathway). It explicitly distinguishes its output from an eligibility assessment and names the sibling it complements, get_rpl_qualification.

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?

Gives explicit ordering advice ('Search before asking for missing personal details') and a clear handoff rule ('Use get_rpl_qualification to explain requirements and calculate conditional quotes'). It also sets a boundary ('Returns candidates, not an eligibility assessment'), so the agent knows when this tool is the wrong choice.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds value beyond them by disclosing that this is a public endpoint (no auth implied), that output is English natural-language text preserving sources/conditions/pagination, and enumerating what each result contains (registration period, regulator, decision counts, linked CRICOS schools, external links). No contradictions with 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?

Front-loaded with verb+resource, then searchable fields, then result contents, then the get_rto hand-off. Dense but essentially every clause carries information; the parenthetical explanation of VET qualifications is the only slightly expendable segment.

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 carries the return-value burden and does so by naming the result fields and links. Combined with annotations covering safety and 78% schema coverage on 9 parameters, an agent has enough to call it correctly; only per-parameter format nuances (e.g., 'all' status behavior, sort defaults) are left to the schema.

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 78%, so the schema already documents most parameters (query, status, locale, sort, withOneuCourses, withCurrentRegulatoryDecisions). The description's listing of searchable fields and filter dimensions mostly restates those same parameters, adding a coherent summary but little syntax or format detail beyond the schema. Baseline 3 applies.

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+resource (search the register of Australian RTOs) and immediately disambiguates scope by naming the sibling it is not: 'Use get_rto for one RTO in full.' It also spells out what can be matched on (name, trading name, RTO code, ABN, linked school name) so an agent can tell it apart from get_rto and get_rto_regulatory_actions without opening schemas.

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 gives clear operational context: name/ABN/code lookup plus filters, and an explicit alternative ('Use get_rto for one RTO in full'). It does not, however, mention the other closely related sibling get_rto_regulatory_actions, nor state when this search would be the wrong choice beyond the single-RTO case.

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

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

Annotations already cover readOnly/idempotent/destructive=false, so the description's added value is the endpoint character: public (no auth), English natural-language results, and preservation of sources, conditions and pagination. That is genuine disclosure beyond the annotations, though pagination mechanics and rate/limit behavior remain unstated.

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?

Four sentences, purpose front-loaded, and each sentence carries a distinct fact (scope, default inclusiveness, detail routing, endpoint character). The final sentence stacks three ideas (language, sources, pagination) but is still readable.

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 supplies the return-shape essentials: class summaries are discovery-only, results are English natural-language text preserving sources and pagination. Combined with the detail-tool routing, an agent has enough to call and interpret this correctly, missing only parameter-level detail.

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 only 33% (locale and hasUpcomingClasses are documented in-schema; page, pageSize, keyword, state are not). The description ties keyword and state to the search behavior, but adds no format, default, or range guidance for page/pageSize, so it only partially compensates for the coverage 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?

States a specific verb (Search) plus a precise resource (published short courses/work certificates) and the two primary dimensions (keyword, state). It also names the complementary sibling, get_short_course, so an agent can tell discovery from detail lookup 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?

Explicitly routes detail-level questions ('recommending a specific date or fee') to get_short_course, and notes the default inclusion of courses without providers/upcoming classes unless filtered. It stops short of stating when-not to use it relative to the other search siblings (search_courses, get_similar_courses).

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds meaningful context on top: it is a public endpoint (no auth implied), returns English natural-language text with sources, conditions and pagination preserved, and it warns that cases are examples rather than approval probabilities or processing-time forecasts. That expectation-setting caveat is exactly the kind of behavioral disclosure annotations cannot carry.

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?

Front-loaded with the core action and scope, then alternatives and exclusions, then return shape. Efficient overall, though the trailing sentence stacks several unrelated caveats (endpoint type, language, pagination) into one dense run-on that could be split for faster scanning.

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?

For a 9-parameter, no-output-schema tool, the description covers the required selector, the optional filter families, where to get valid values, what a call returns (compact page, public IDs, website links), and where to go for full records. Nothing an agent needs to invoke it correctly 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?

With 56% schema coverage, the description contributes real meaning: it maps the tool to school, advisor, subject and 'inclusive' age filters, clarifying that minAge/maxAge bounds are inclusive — a detail the schema does not state. It does not elaborate on page/pageSize/locale, but those are documented in-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 ('Find') and resource ('published successful visa cases') with hard scope: exactly one subclass from 500/600/485/820, optional school/advisor/subject/age filters. It also clearly separates itself from the two nearest siblings by naming list_visa_case_filters for valid values and get_visa_case for detail lookups.

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?

Explicit about prerequisites ('Call list_visa_case_filters for valid values') and the follow-up step ('call get_visa_case for details'). It also enumerates what this tool does NOT do — no keyword search, no courseCode filter, no similarity ranking, no cross-subclass search — so an agent can rule out misuse before opening the schema.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds real behavioral context beyond them: results are grouped by condition number, English is the official source text while Chinese is translated, and the response preserves sources, conditions and pagination. It does not contradict any annotation.

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?

Four compact sentences, with the core search purpose and modes front-loaded before the sibling reference and caveats. Dense but no filler; each sentence carries information about behavior or scope.

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 cover returns, and it does: grouping by condition number, language provenance (English official, Chinese translated), preserved sources, and pagination. The only real gap is parameter-level detail for page/pageSize, which is minor for a simple search 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?

Schema coverage is only 25% (only locale is documented), so the description carries more burden. It usefully clarifies keyword semantics ('by number or keyword, or omit keyword to browse') and gestures at pagination, but page and pageSize are never explained in either schema or description, leaving two parameters under-documented.

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 specific verb+resource ('Search public Home Affairs visa condition descriptions') and immediately clarifies the search modes ('by number or keyword, or omit keyword to browse'). It names the sibling get_visa_condition and explains how the two differ (grouped-by-number here vs. all source records there), so an agent can choose without opening schemas.

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 gives clear when-to-use context ('by number or keyword, or omit keyword to browse') and an explicit when-not ('Does not determine conditions attached to a personal visa'), plus names the alternative get_visa_condition. It stops short of fully spelling out the routing rule between this tool and get_visa_condition, but the distinction is stated.

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

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

Annotations already declare destructive=true and idempotent=true; the description adds real context beyond them by explaining that retries must reuse the identical credential (the practical meaning of that idempotency) and that execution is UI-only with no model confirmation accepted. That is meaningful behavioral disclosure for an irreversible action, though it never says what state results from success.

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?

Three tight sentences with the most load-bearing constraint (UI-only execution) front-loaded. It is appropriately short for a single-purpose tool, though the density of undefined terms slightly undercuts readability.

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 output schema covers return values and annotations cover the safety profile, so those gaps are acceptable. But for a destructive, irreversible submission, the definition omits the expected preconditions (where taskId/actionId come from) and any statement of what committing actually does.

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%, so the description carries the full burden, yet taskId and actionId are never mentioned. Only 'credential' is indirectly explained ('same action credential'), and 'No extra parameters are accepted' merely restates additionalProperties:false.

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 frames the tool as 'UI-only execution of the applicant's bound confirmation,' which implies a final submission step but never states plainly that it submits an application, nor does it name prepare_application_submission as the sibling it follows. The jargon ('bound confirmation') leaves the actual effect to inference.

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 provides a genuine operational rule: retry with the exact same action credential after an unknown outcome. However, it gives no guidance on when this should be called versus prepare_application_submission or update_application, and no stated prerequisites for obtaining taskId/actionId.

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

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

Annotations already mark this as a non-read-only, non-idempotent, non-destructive, open-world write. The description adds important context: feedback is recorded but does not edit official data, a receipt means received for review rather than accepted or corrected, and submissions are associated with the verified account when signed in.

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 dense but front-loads the core purpose and call condition before moving into reporting expectations and receipt semantics. It is somewhat long for a single paragraph, but every sentence adds useful behavioral or usage context.

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?

For a complex 8-parameter submission tool with no output schema and partial schema coverage, the description gives substantial guidance on intent, privacy, evidence handling, account association and receipt meaning. It still leaves some secondary parameter semantics, especially issue_type and year/page_url/source_urls, to the schema.

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?

With only 38% schema description coverage, the description compensates well for the most important reporting parameters by explaining stand-alone content requirements, distinguishing user claims from verified facts, requiring a code or name for school/course reports, and warning not to guess a match. However, parameters such as year, page_url, source_urls and issue_type are not further clarified in the description.

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 specific verb and resource: submitting plain-text feedback to One U Education for internal review. It clearly distinguishes this from sibling lookup/search tools by stating it records feedback only and does not edit official data.

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 explicitly says to call only when the user wants to submit feedback, notes that an account is optional, and explains that signed-in submissions are linked to the verified account. It also clarifies that incomplete but useful leads are accepted, which prevents unnecessary hesitation.

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

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

The description adds substantial behavior beyond the annotations: updates may replace or clear existing values, ambiguous or third-party data should be clarified, unsupported fields must not be invented, conflicts require a re-read, and timeouts require preserving operationId. This is consistent with destructiveHint and idempotentHint and gives an agent practical mutation-safety 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 compact and mostly front-loads the key scope and consent rule. Some sentences, such as 'Documents use Forms' and 'Existing private values remain hidden in safe reads,' feel abrupt, but there is little empty filler.

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?

For a complex nested mutation with an output schema, the description covers consent, revision handling, idempotency, conflict recovery, and high-level parameter placement. It is not fully complete because most nested field semantics are left to a schema with low description coverage.

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 only 20%, so the description must carry more parameter meaning. It helpfully says to use taskId, operationId, expectedRevision with basicChanges or typeChanges, routes study preferences under typeChanges.preferences, and warns against patch/typeData wrappers and revision key confusion. However, many nested fields and null-clearing semantics remain undocumented.

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 clearly states a specific action and resource: saving supported application details, including identity and contact fields, while indicating corrections and voluntary updates. It does not directly name competing siblings such as save_application_intent or submit_application, but the scope is still distinguishable.

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 gives clear usage conditions: only save data the applicant voluntarily provides or asks to correct, do not proactively solicit private details, re-read before writing, and clarify ambiguous intent. It lacks explicit routing to alternative tools, but the when/when-not guidance is strong.

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