H1R3: Australian job board for bots

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

With no annotations, the description carries the full behavioral burden. It does disclose one non-obvious trait: that the document is represented only by a SHA-256 hash and no file is transmitted. Beyond that it says nothing about permissions, whether the entry is verified or pending, or what happens to the record afterward.

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?

A single front-loaded sentence with no redundant restatement of the tool name. It is tight and every clause carries information, though for an 8-parameter mutation it is arguably too terse to be fully useful.

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?

Eight parameters at 0% schema coverage, no annotations, and no output schema leave the agent guessing about parameter formats, permission needs, and result shape. The description covers only one of eight fields and one behavioral constraint, which is insufficient for a mutation tool of this complexity.

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% across 8 parameters, so the description must compensate and largely does not. Only doc_sha256 receives semantic grounding ('SHA-256; no file upload'); type, state, issuer, number, issue_date, and expiry_date are left entirely undefined, including expected formats and whether 'state' means region or status.

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 ('Add a cert/licence') plus the scope of what is being added (metadata + optional document hash). A sibling like list_cert_types is clearly the lookup counterpart, though the description never names it. It is specific but does not explicitly differentiate from other mutation siblings such as add_referee or add_role.

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 parenthetical 'no file upload' implicitly tells the agent when not to attempt document attachment, which is useful. However, there is no guidance on prerequisites (e.g., a valid cert type from list_cert_types) or on when to prefer request_issuer_confirmation for a verified certificate. 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?

With no annotations, the description carries the full burden, and it does disclose two valuable traits: the link is unique/single-use and expires in 30 days. It is silent on permission requirements, whether the referee is emailed automatically, and whether re-nominating the same email creates a duplicate or replaces the prior link.

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?

One sentence, zero waste, with the action front-loaded and the side effect (link generation) trailing. Slightly dense for a single clause 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?

For a 5-parameter mutation tool with no annotations and no output schema, the description usefully covers the return value but leaves the parameters and the operational prerequisites undocumented. It is minimally adequate rather than 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 0% and the description names none of the five parameters. Required fields (role_id, name, email) are inferable from their names, but 'relationship' and 'phone' are left entirely undefined — relationship in particular is ambiguous (to the candidate? to the role?).

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 (nominate) and resource (referee) scoped to a role, and even names the artifact produced: a single-use 30-day referee link. No sibling tool in the list touches referees, so an agent can place it immediately 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?

The phrase 'for a role' implies the context, but there is no guidance on when this is appropriate versus alternatives, no prerequisites (e.g. must own/have applied to the role), and no note on what happens if a referee is nominated twice.

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 no annotations, the description carries the full behavioral burden. It does disclose one genuinely useful business rule — roles current or ended within 24 months are reference-eligible — which is non-obvious domain context. However, it says nothing about permissions, duplicate handling, validation failures, or what the mutation returns.

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 compact sentences, front-loaded with the core action, with the eligibility rule following. No filler, though the parenthetical task-format note is slightly terse relative to how much parameter ground it is covering.

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?

No output schema and no annotations, with 7 undocumented parameters. The description covers one domain rule and one parameter's format but omits return behavior, validation expectations, and most field semantics — insufficient for a mutation tool of this shape.

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% across 7 parameters, so the description must compensate and largely does not. It clarifies the format of the tasks array ('taxonomy codes or {custom}'), but leaves title, start_date, end_date, employer_name, employer_abn, and employer_domain entirely undocumented (e.g., date format, ABN expectations).

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 verb+resource: 'Add an employment-history role', which is clearly distinct from siblings like add_cert and add_referee. It doesn't explicitly name alternatives, but the resource is unambiguous.

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 when-to-use guidance, no prerequisites, and no mention of how this differs from related tools such as add_cert, add_referee, or update_profile. The 24-month eligibility note hints at a constraint but is not framed as usage direction.

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 no annotations, the description must carry the full behavioral burden. It usefully discloses the authorization gate (verification tier, and the A$3/yr cost for ID verification), but says nothing about what happens on success, idempotency, whether applying consumes credits/limits, or what happens if the required verification is missing.

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 clauses, verb front-loaded, and the verification prerequisite follows immediately. Dense and waste-free, though the parenthetical cost/definition inserts add minor noise.

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 mutation tool with no annotations and no output schema, the key gate (verification requirement) is covered, but the cover_note parameter and the post-apply outcome are entirely absent. Adequate but incomplete for the tool's complexity.

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 should compensate. It only indirectly implies job_id ("a job") and never explains the cover_note parameter at all, nor the format of job_id. It leaves half the parameters 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?

States a specific verb (Apply) and resource (a job), and clarifies the actor is the seeker. It does not explicitly name a sibling it should be chosen over (e.g., update_application vs apply), but the action is unambiguous enough to distinguish from list_applications/update_application by context.

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 a concrete precondition for use: you need Basic verified or higher, and ID-only jobs require ID verified. That is real when-you-can-use-this guidance, though it never names an alternative tool or states when NOT to apply (e.g., already-applied cases).

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 no annotations, the description carries the burden and does disclose meaningful behavior: an eligibility prerequisite (verified ABN), a cost (1 credit), and a state transition (listing becomes an H1R3 job). It stops short of stating irreversibility, failure behavior, or whether the credit is refunded on failure.

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?

A single dense sentence with no filler; the key facts (who, what, cost) are front-loaded. Slightly compressed wording ('claims a sourced listing for their company') costs a little 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 one-parameter mutation tool with no output schema and no annotations, the description covers the actor, the action, and the credit cost, but omits where listing_id comes from and what happens on failure. 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 0% for the single required listing_id, so the schema contributes nothing. The description hints that the id refers to a 'sourced listing' but never states the format, provenance, or how to obtain it, leaving the one parameter effectively 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?

States a specific verb (claims) and resource (a sourced listing) and adds the downstream effect (converts to an H1R3 job). It implicitly distinguishes itself from post_job/apply by acting on a pre-existing sourced listing, though no sibling is named 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?

The precondition 'verified (ABN) employer' implies who should call it, but there is no explicit when-not guidance or pointer to an alternative such as post_job for employers who have no sourced listing. Usage is implied rather than 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?

With no annotations, the description carries the full burden and does well: it discloses the link is single-use, expires in 24h, is sent to the account email, and has a side effect of +15 identity score. It omits failure cases (already-confirmed accounts) and any auth/rate-limit notes, but the core behavior is clearly conveyed.

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?

A single front-loaded sentence with no waste. The action, the mechanism, the expiry, and the reward are all packed in without 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 0-param, no-output-schema tool, the description covers the essential behavior: what is sent, its lifetime, and its side effect. Only edge cases (already-confirmed state, resend behavior) are missing, which is a minor gap at this complexity level.

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, which per the rubric sets a baseline of 4. There are no parameter semantics to document, and the description correctly focuses on inputs that are implicit (the account from context) rather than inventing schema detail.

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 (email) plus resource (single-use 24h confirmation link) and the delivery target (account email). It is clearly distinct from read tools like get_verification, though it does not explicitly name which sibling handles the alternative confirmation paths.

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 explicit when-to-use or when-not-to-use guidance. An agent cannot tell from the text whether this is a prerequisite for claim_listing, share_passport, or follow-up tools, nor what to do if the account is already confirmed.

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 no annotations, the description carries the full burden and does well: it discloses the recurring side effect (daily/weekly emails of NEW matching jobs to the account email), an unsubscribe link, the 5-alert cap, and the important caveat that sending may not yet be switched on ('sending_enabled in the reply'). It omits failure behavior when the cap is hit or whether an alert can be edited later, which keeps it from 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?

Four tight sentences: identity first, then prerequisites, then the delivery behavior, then the filter list. The parentheticals are compressed but each carries load (A$/yr, ANZSCO, 'advertised pay'); 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?

No output schema, no annotations, nine params, and the description still covers prerequisites, limits, side effects, and the one return field worth knowing (sending_enabled). What's missing is only edge behavior: what happens at the 5-alert cap, whether duplicates are rejected, and how to reference the created alert later.

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 33%, but the description names all nine parameters plus semantics for the tricky ones: min_pay is annual advertised A$ pay, occupation is an ANZSCO prefix, frequency is daily or weekly, and the filter set mirrors search_jobs so the agent knows the matching semantics. That transparently compensates for the thin schema, though it gives no format hints for q/near/work_type.

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 ('Save a job search as an email alert') with clear scope, and implicitly separates it from search_jobs (the search it snapshots), list_job_alerts and delete_job_alert by describing the delivery mechanism. An agent can identify this as the create/alert-subscription tool 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?

Discloses prerequisites ('seeker key, Basic verified') and a hard constraint ('Max 5 alerts') that determine whether the call will succeed, and ties the filters to search_jobs so the agent knows to mirror a search. It does not explicitly say when to prefer this over, say, re-running search_jobs or when to use list_job_alerts first, so it stops short of 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?

With no annotations, the description carries the full behavioral burden but only says "delete." It does not state that the operation is irreversible, whether confirmation is required, what permissions/ownership checks apply, or what is returned on 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?

A single short sentence with the key information front-loaded and no filler. The ownership qualifier earns its place; nothing is bloated.

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 destructive mutation with no annotations, no output schema, and zero parameter documentation, the description is thin. An agent lacks irreversibility warnings, auth expectations, and any hint about obtaining a valid alert id.

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 0% for the single parameter, so the description must compensate. It does add meaning by identifying the id as the seeker key, but gives no format, source (e.g., from list_job_alerts), or validation details.

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 (delete) and resource (job alert) with a scoping qualifier ("one of your"), which cleanly distinguishes it from siblings like create_job_alert and list_job_alerts. It does not explicitly name those siblings, but the verb+resource pair is unambiguous.

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?

"One of your job alerts" implies the caller must own the alert, which is light usage context. There is no explicit when/when-not guidance or reference to alternatives such as listing alerts first to find the id.

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 no annotations and no output schema, the description carries the full burden and does meaningfully disclose behavior: it names the scoring basis (shared skills from JSA ASC), the live job-count enrichment, and that results include a 'why' explanation plus candidate-have/missing task breakdown. It omits any statement about read-only safety, rate limits, or data freshness caveats, 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?

A single dense sentence, front-loaded with the required input and followed by the return payload, so nothing is wasted. It is a run-on with many comma-separated clauses that would read better as two sentences.

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 enumerates what is returned (score, shared tasks, have/missing tasks, live job counts, sample jobs), which is the key missing structured information. The unexplained 'limit' parameter is the main residual 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 only 33%: only 'role' is documented in the schema. The description compensates for 'verified_tasks' by explaining the accepted formats (free text or H1R3 task codes like admin.payroll), but 'limit' is never explained anywhere. Partial compensation warrants a baseline 3.

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 (return most adjacent occupations) plus the exact resource and matching basis (shared skills via JSA Australian Skills Classification). No sibling tool does adjacency matching, so an agent can distinguish it immediately from list_task_taxonomy or search_jobs.

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 implies when it applies ('given a role title or ANZSCO code, optionally with verified tasks') but never names an alternative tool or a when-not condition. An agent must infer that this is for career-adjacency exploration rather than job search.

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?

No annotations are provided, so the description carries full behavioral burden. 'Read' implies a non-mutating operation, but there is no disclosure of required permissions, token validation behavior, error handling, or rate limits.

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?

A single front-loaded sentence with no wasted words. However, it is so terse that it may leave the agent wanting more context, which is reflected in other dimensions.

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 simple read tool with no output schema and no annotations, the description should at least briefly indicate what is returned or how to obtain the token. It does neither, leaving the agent with an incomplete picture of the call's outcome.

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 0% schema description coverage, the description must compensate. It adds that the token is the identifier for the shared passport, which gives some meaning beyond the schema's bare string type, but does not describe format, source, or validity rules.

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 ('Read') and resource ('shared passport') with the lookup key ('by its token'). It implicitly distinguishes from the sibling share_passport, but does not name alternatives 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives like share_passport. The context is only implied by the resource name.

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 no annotations, the description carries the full burden and does so well: one-time use, 30-minute expiry, client-side processing (MediaPipe), and no upload. These are exactly the behavioral traits an agent needs to avoid misusing the tool or leaking data.

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, each load-bearing, with the core constraint and the lifecycle/expiry front-loaded and the follow-up action last.

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?

Despite having no annotations and no output schema, the description covers what is returned, its lifetime, where the check runs, the privacy posture, and how to retrieve the outcome — complete for a zero-param tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. The description adds no parameter meaning, but none is needed.

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 ('returns a one-time 30-minute link') and clarifies the intended actor (your human, on a phone with a camera). It is instantly distinguishable from siblings like get_verification and get_verification_status.

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?

Sets the routing condition explicitly ('Bots cannot do the selfie check') and names the follow-up tool ('Poll get_verification_status for the result'), so an agent knows both when this applies and what to do next.

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?

No annotations are provided, so the description carries the full burden, yet it only enumerates return contents. It says nothing about read-only nature, auth/permission requirements, privacy implications (despite a set_privacy sibling), or behavior when verification is incomplete.

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?

It is compact and front-loads the headline (portable verified passport with three scores), but the tail is a dense comma-run of contents that reads like a data dump rather than structured guidance. No wasted prose, but little organization.

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 the return payload, and it does list the main components. However it omits the relationship to get_passport, privacy/permission context, and any failure modes, leaving an agent short of what it needs to choose and invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 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 conveys what is returned (three 0-100 scores with level/breakdown, certs, roles, per-task matrix) but is a noun-phrase fragment rather than a stated verb+resource, so the action is only implied by the name. It does not distinguish itself from the sibling get_passport, which sounds like the same resource.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. Given siblings like get_passport and share_passport, an agent cannot tell from the description which one to call for which need.

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?

No annotations exist, so the description carries the full burden. It adds genuine domain context (the three tiers, that Basic is free and selfie-based, that ID costs A$3/yr), but never states that this is a read-only lookup, whether authentication is required, or what the caller's own verification state is scoped to.

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?

A single front-loaded sentence leads with the resource, then adds tier detail in compact parentheticals. It is dense but every clause conveys real tier information and 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?

With no output schema, the description usefully enumerates the response contents (the three verification levels and their requirements). Given zero parameters and no annotations, the only remaining gap is auth/scope behavior, which is minor for a simple status lookup.

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 the baseline is 4; there is nothing for the description to disambiguate. Schema coverage is reported at 100%.

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 the resource (seeker verification level and steps) and enumerates the exact states it reports, so an agent knows what it will receive. It does not, however, distinguish this tool from the sibling 'get_verification', which is a real ambiguity for selection.

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: 'Shows what is missing to apply' suggests calling it before pursuing an application or upgrade. There is no explicit when-to-use statement, no prerequisites, and no contrast with the similar get_verification tool.

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 no annotations, the description carries the full burden of behavioral disclosure and delivers almost none. It does not say whether this creates an account, sends a confirmation email, is idempotent, or what happens after joining — all material for a 4-required-param write-shaped call.

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?

One short sentence is front-loaded and waste-free, but for a tool with four required parameters this is under-specification rather than conciseness. There is no second sentence earning its place because no useful content was written at all.

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?

Four required parameters, no schema descriptions, no annotations, and no output schema, leaving the description as the only source of meaning — and it provides none. An agent cannot call this tool correctly on the strength of the definition alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description adds nothing about any of the four required parameters. Non-obvious fields such as 'has_bot' and 'postcode' are left entirely unexplained, and the 'role' enum (seeker/employer) is never tied to waitlist behavior in the text.

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 has a verb and a resource ('Join' + 'pre-launch waitlist'), so an agent knows the general action. However, 'pre-launch waitlist' is essentially a restatement of the tool name join_waitlist, and it never distinguishes this from look-alike siblings such as apply, claim_listing, or add_role, which a caller could easily confuse with it.

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 use this tool, no prerequisites, and no mention of alternatives. An agent must guess whether joining a waitlist is the right path versus apply or claim_listing, and whether an existing confirmed email (see confirm_email) matters.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that results carry skill badges and a verification_level with its two possible values, but says nothing about permissions, pagination, ordering, or result volume for what is presumably a multi-record list.

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?

One front-loaded sentence that earns its place by conveying scope, ownership constraint, and return fields. No filler, though the parenthetical verification_level detail slightly crowds the core statement.

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 low-complexity, single-parameter read tool with no output schema, the description is largely sufficient, and it helpfully names return fields in lieu of an output schema. It omits pagination/ordering behavior and job_id format, minor but real 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?

The single job_id parameter has 0% schema description coverage, so the description must compensate. It references an 'employer key' and a job you own but never defines the job_id format, source, or constraints, leaving the one required parameter effectively 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?

States a specific verb+resource ('List applicants for a job') and adds the employer-side ownership constraint, which an agent can use to distinguish it from seeker-side tools like apply or update_application. It does not explicitly contrast with a closer sibling such as search_seekers, 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?

Usage is implied by the qualifier 'for a job you own (employer key)', signaling this is an employer-scoped lookup. There is no explicit when-to-use, no when-not-to, and no named alternative against siblings like search_seekers or list_bot_applicable_jobs.

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 no annotations, the description carries the full burden, and it does disclose a meaningful trait: results are restricted to fully automatable jobs and each carries an apply block {method, endpoint, required_fields, auth}. However, it does not state that this is a read-only operation, nor does it cover pagination or ordering behavior.

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, front-loaded with the tool's defining scope. Nothing is wasted, though the second sentence describes return shape rather than helping the agent parameterize the call.

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 list tool with no annotations and no output schema, the description is too thin: it never explains filters, pagination via cursor/limit, or the semantics of fields like state, requires_task, or updated_since, so an agent cannot confidently invoke it.

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?

Ten parameters (q, limit, state, cursor, skills, min_pay, location, work_type, requires_task, updated_since) have 0% schema description coverage, and the description mentions none of them. It provides no meaning for any filter, cursor, or limit parameter.

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 clear resource and scope: the canonical index of jobs a bot can apply to end-to-end, with the qualifier 'no human form/captcha'. This distinguishes it conceptually from a general listing, but it never names siblings like search_jobs or apply, leaving the agent to infer 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives among siblings such as search_jobs or list_applications. The bot-applicable filter implies a context, but the agent must infer it.

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?

No annotations, so description carries full burden. It implies a read/enumeration (listing types and verification methods) but does not state read-only nature, whether results are static, or how verification methods are expressed. Minimal behavioral 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?

Single tight sentence, front-loaded with the resource, with the verification-method scope added compactly. No 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?

For a no-param reference lookup with no output schema, the description is adequate but thin. It could clarify that this is a static enum/reference list and what the verification methods look like, since there is no output schema to lean on.

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?

Zero parameters, so baseline 4 applies. Nothing to document, and the description correctly indicates no inputs are needed.

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?

Clear noun-based resource ('cert/licence types') with scope narrowing to how each is verified. Not a tautology. No sibling differentiation, though few siblings overlap.

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 when-to-use guidance, no mention of alternatives. Agent must infer this is a reference/lookup enumeration from the name 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?

With no annotations, the description does carry some weight: 'your active' signals identity-scoped results and filtering out inactive alerts, and '(seeker key)' hints at the auth requirement. It says nothing about ordering, pagination, or result shape, so the safety and behavior profile is only partially disclosed.

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?

A single short sentence with the resource and scope front-loaded, which is appropriate for a trivial read. The '(seeker key)' parenthetical is slightly cryptic terminology that a reader may not decode without prior 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?

The tool is simple and parameterless, but with no output schema the description should say what a job alert record contains or at least whether the list is bounded. That return-value gap is the main missing piece for an otherwise low-complexity tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The parenthetical '(seeker key)' arguably touches the implicit identity input, but the tool is genuinely parameterless.

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 pairs a specific verb ('List') with a specific resource ('your active job alerts'), and 'active' adds a real scope qualifier. It does not differentiate itself from siblings like create_job_alert or delete_job_alert, but the resource is unambiguous.

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 call this versus create_job_alert, delete_job_alert, or any other listing tool. The agent must infer from the name alone that this is a read of existing alerts, with no exclusions or prerequisites 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?

With no annotations, the description carries the full burden. It says nothing about whether the list is filtered, paginated, scoped to a user, or what the entries contain – for a discovery tool that an agent would call before start_test, that context matters.

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?

A single efficient sentence with no filler, front-loaded with the verb. It is underspecified rather than verbose, so the issue is completeness, not conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No parameters, no annotations, and no output schema, so the description is the only source of information – and it gives nothing about scope, filtering, or what the returned skill tests can be used for. Inadequate for a tool whose results feed start_test.

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; per the baseline for 0 params this scores 4. No parameter claims are made that could mislead.

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 verb (List) and resource (skills tests), which identifies the operation, but it is nearly a restatement of the tool name list_skill_tests. It does not distinguish itself from siblings like list_cert_types or list_task_taxonomy beyond the resource noun.

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 indication of when to use this versus alternatives, no mention of prerequisite context, and no relationship drawn to siblings like start_test or submit_test that would make the listing actionable.

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?

No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral: no indication that it is a safe read, whether the taxonomy is static or per-role, pagination, or the shape of results. It is evidently a lookup, but that is inferred from the name, not stated.

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?

A single tight fragment with no filler, and the key concept (task taxonomy for roles) is front-loaded. Its brevity shades into under-specification rather than true economy, but nothing is wasted.

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 stand in for the return shape, and it only partially does — it says results tie task codes to roles and corroborating certs/badges, but not the structure, volume, or whether filtering is possible. Adequate but with clear gaps for a tool whose output contract is otherwise undocumented.

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 schema has zero parameters, so per the rubric the baseline is 4. There is nothing parameter-wise for the description to clarify or omit.

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 — a task taxonomy of codes keyed to roles, plus the certs/badges that corroborate each task. But it is a bare noun phrase with no verb, so it never states that the tool lists/returns this data, and it draws no line against siblings like list_cert_types or list_skill_tests.

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 call this versus alternatives, nor any prerequisite or context. The agent must infer usage purely from the name and the surrounding sibling set.

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 no annotations, the description carries the burden and does well: it discloses the deterministic no-AI ANZSCO extraction, the ranking order (best first), the broadening-to-related-occupations fallback, and the privacy guarantee ('Nothing is stored'). It stops short of describing result size, pagination, or rate limits, which matters for an 8-parameter query tool.

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, then the input contract, then the pipeline behaviour, then the LinkedIn URL prohibition. Dense but nearly every clause carries information; the ANZSCO/no-AI parenthetical is the only slightly expendable detail.

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 tool with zero annotations and no output schema, the description covers inputs and ranking behavior but omits how results are shaped or bounded (count, pagination, what a returned job includes) and how the optional filters interact. Adequate to invoke, not 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 only 13% (only 'text' is documented), so the description must compensate and largely does not. It clarifies the text-vs-signals input modes but leaves 'limit', 'min_pay', 'location' and 'work_type' unexplained — the phrase 'likely pay band and work type' describes extracted signals, not these filter parameters, which risks confusion about what they do.

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 live Australian jobs that match a resume or LinkedIn profile') and explains the matching mechanism (ANZSCO extraction plus overlap ranking). It is distinguishable from search_jobs by being a profile-driven match rather than a keyword search, though that contrast is implied 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?

Gives real input guidance: supply either 'text' or derived signals, and 'Never send LinkedIn URLs: paste text or a Save-to-PDF export.' However, it never says when to prefer this over search_jobs or find_adjacent_roles, nor what happens if both text and signals are supplied.

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 no annotations, the description carries the full burden and does well on several axes: it discloses cost (1 credit), an auth prerequisite (employer key, ABN-verified), and a side effect (Fair Work/moderation warnings returned). It stops short of describing reversibility, posting visibility, or failure behavior, so it is not fully complete.

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 action first, prerequisites second, and return/parameter behavior last — no filler. Slightly telegraphic, but every clause 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?

For a 9-parameter write tool with no annotations, no output schema, and 0% schema coverage, the description covers preconditions, cost, returned warnings, and one parameter default, but leaves the majority of input parameters unaddressed. Adequate but noticeably incomplete for this complexity.

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% across 9 parameters, so the description must compensate. It only explains id_verified_only's semantics (default Basic verified or higher) and says nothing about title, location, work_type, pay_min/pay_max/pay_unit, skills, or description, leaving most parameters undocumented in both schema and 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?

The description opens with a specific verb+resource ('Post a job') and adds the employer-key/ABN/credit preconditions, so the action and its context are unambiguous. It does not explicitly differentiate itself from siblings, but no sibling competes for the same write action (search_jobs, apply are clearly different), so this is a minor gap.

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 implies the conditions for use (needs an employer key, ABN verification, 1 credit) but never states when to choose this tool over any alternative or what the exclusions are. The eligible-verification-tier note for id_verified_only gives useful context but is parameter-level, not tool-selection 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?

With no annotations, the description carries the full burden and does well: it discloses that the link is single-use, expires in 30 days, and that no email side effect occurs. It omits the auth/role requirements and whether issuing a new link invalidates prior ones, but the core behavioral traits are covered.

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 compact sentences with zero filler, and the key constraint (single-use, 30-day) plus the manual-sharing caveat are front-loaded. Nothing 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?

For a single-parameter tool with no output schema and no annotations, the description covers the essential behaviors: what is returned (a link), its lifetime, its single-use nature, and the absence of automated delivery. Only the auth prerequisites and link retrieval details are unstated.

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?

One parameter at 0% schema coverage, so the description must compensate and only partially does: 'cert issuer' implies cert_id identifies the certificate to confirm. It adds no format, provenance, or validation detail for cert_id beyond that inference.

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: obtaining a single-use confirmation link for a cert issuer, with the yes/no purpose made explicit. It is clear what the tool produces, though it does not name or contrast itself against any sibling (e.g. confirm_email or add_cert).

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 phrase 'Share it yourself (no email is sent)' implicitly tells the agent this tool only mints the link and delivery is manual, which is meaningful usage context. However, there is no explicit when-to-use trigger or statement of when another confirmation path 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?

With zero annotations, the description carries the full burden and does substantial work: it defines the pay_type provenance taxonomy, discloses the 200-match result window, source ranking, and the direct_to/apply_mode fields returned for every result. It also notes no key or verification is needed. It stops short of describing error behavior or rate limits for the undocumented filter parameters.

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 correctly front-loaded, and most clauses carry real information (defaults, ranking, result fields). But it is one dense pipe-and-semicolon run-on paragraph, which makes the pay taxonomy and the source semantics hard to parse for an agent scanning it.

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 18-parameter tool with no annotations and no output schema, it covers the highest-value filters and the shape of returned pay/job fields well. It is still incomplete: four parameters remain undefined, duplicate-looking parameters are not disambiguated, and there is no guidance on pagination interplay despite the cap note living only in 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?

The description explains the meaning and defaults of pay, include_estimates, min_pay, source, and the Seek-style filters beyond what the schema states. But several of the 18 parameters — notably near, pay_min, pay_shown, and skills — are undocumented in both the description and the schema, and near/pay_min appear to duplicate suburb/min_pay without any disambiguation.

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: 'Search live Australian jobs', which is clearly distinct from siblings like search_seekers or list_bot_applicable_jobs. It never explicitly says it is not for those other resources, but the domain is unambiguous from the first clause.

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 filtering guidance ('include_estimates=false for stated pay only', 'pay=verified|advertised|estimate|any', 'source=all default; verified ranked first'), which implies when to pick each mode. However, there is no explicit statement of when to use this tool versus list_bot_applicable_jobs or search_seekers, and no prerequisites are 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?

With no annotations, the description carries the full burden. It usefully discloses the result shape ('Each result has verification_level (Basic verified | ID verified)') and the range of min_references (0-100), which is real behavioral value. It says nothing about pagination, result caps, privacy constraints, or permissions, which is a notable gap for a people-search tool.

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 a compact filter list; little wasted text. The filter enumeration reads as a run-on sentence and would benefit from structure, but it is appropriately sized for a 12-parameter tool.

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 12-parameter search with no annotations and no output schema, the description is too thin: three parameters are unexplained, and pagination/result-size behavior and the caller's authorization model are absent. The one genuinely helpful addition, the verification_level result field, does not offset these 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 coverage is 0% across 12 parameters, so the description must compensate, and it does partially: it names nine filters and clarifies min_level's enum values and min_references' 0-100 range, matching the schema enum. However, skills, postcode, and work_rights are undocumented anywhere, and the 'code/type/badge' hints for verified_* are cryptic.

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 (seekers), and adds the scope qualifier 'ABN-verified employer key' plus the fact that results carry verification_level. 'Search searchable seekers' is mildly tautological, and it never explicitly distinguishes itself from sibling search_jobs, but the employer-facing seeker search is clear enough to act on.

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 use this versus search_jobs or other list_* siblings, and no prerequisites beyond the parenthetical 'ABN-verified employer key'. The enumerated filters imply the use case but leave the agent to infer the calling context entirely.

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?

No annotations are provided, so the description carries the full burden. It discloses the prerequisite relationship but not whether the update is idempotent, whether omitting a parameter leaves it unchanged, permission requirements, or any reversibility of consent. Significant behavioral gaps remain.

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 short, front-loaded sentences with zero filler; the consent prerequisite is foregrounded and the enum values are listed efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool is and one workflow prerequisite, which is the minimum an agent needs to order this call correctly. But with no annotations, no output schema, and an enum whose values are undefined, a mutation tool with a consent gate should disclose more about state-change behavior.

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%, but the description enumerates the visibility enum values and links consent to the cert/role workflow, adding meaning beyond the bare schema. However, it does not explain the semantics of each visibility level (private vs applied vs searchable) or whether consent is replaceable, leaving the highest-value ambiguity unexplained.

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 (set) and resource (privacy: consent + visibility) and names the three visibility values, making the purpose clear. It is not fully differentiated from siblings like add_cert or add_role, but the scope is narrow and identifiable.

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 states the ordering prerequisite: consent must be set before adding certs/roles, which tells the agent when this tool is needed. It does not name an alternative tool or cover when not to use it, but the prerequisite is the key routing signal.

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 no annotations, the description carries the full burden, and it does disclose two real behavioral traits: the link is read-only and creating it revokes the previous link (a destructive side effect on prior shares). It omits auth requirements, link expiry, and what is returned, so the disclosure is useful but incomplete for a no-annotation mutation.

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?

A single front-loaded sentence that states the action, the access scope, the audience, and the side effect with no wasted words.

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 zero-parameter tool with no output schema, the description covers purpose, scope, and the revocation side effect, which is nearly everything an agent needs. Minor gaps remain around auth/permission requirements and link lifetime.

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, which is the baseline 4 case; the description correctly implies a parameterless action with no input arguments to document.

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 (Create) and resource (read-only passport link) with the target audience (any employer or bot), which cleanly separates it from get_passport. It stops short of explicitly naming or contrasting with a sibling tool, so it is clear but not sibling-routing.

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?

'For any employer or bot' gives audience context and '(revokes previous)' signals a precondition, implying this is the way to grant external access. There is no explicit when-to-use vs when-not-to-use guidance or named alternative (e.g., get_passport for self-retrieval), 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?

With no annotations, the description carries the full burden, and it does disclose two non-obvious traits: the test is timed and the human account owner (not the agent) must be the taker, which is a genuine actor/auth constraint. It omits whether starting is idempotent, what happens if a test is already in progress, and any rate or state limits.

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 short sentences, front-loaded with the action and its timing constraint. Nothing is padded, though the parenthetical '(seeker key)' is ambiguous enough that it costs clarity rather than earning 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?

For a state-changing tool with no annotations, no output schema, and an undocumented parameter, the description covers the most important behavioral fact (a human must take the test) but not the surrounding flow: what 'start' produces, how the skill is chosen, or how this connects to submit_test. Adequate but with visible 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?

There is a single required 'skill' parameter at 0% schema description coverage, so the description must compensate and largely does not. '(seeker key)' is cryptic and appears to describe a credential context rather than the 'skill' argument itself; the description never explains what value 'skill' accepts (ID, name, enum from list_skill_tests).

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 ('Start a timed skills test') and adds a scope qualifier ('seeker key'), which distinguishes it from submit_test and list_skill_tests by implying initiation rather than submission or listing. It stops short of naming a sibling explicitly, so differentiation is inferable 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?

The line 'The human account owner must take it' gives a real applicability condition — this is not an agent-executable step but one requiring the human account holder — which is meaningful routing guidance. However, it never says when to call this versus submit_test, or what must precede it (e.g., whether a test must be selected from list_skill_tests 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?

No annotations are provided, so the description carries the full behavioral burden, and it does not say whether submission is final, whether resubmission is allowed, whether answers are graded immediately, or whether this consumes/closes the attempt. Only the answer encoding is disclosed.

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?

A single front-loaded sentence with no filler, and the parenthetical encoding detail is placed where it matters. It is efficient, though the brevity contributes to the gaps in the other dimensions.

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 terminal, likely irreversible submission with two required parameters, no output schema, and no annotations, the description is too thin. It omits the attempt_id lifecycle, submission finality, and any indication of what a caller gets back (e.g., score or pass/fail).

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 two required parameters. The description usefully explains that answers are 0-based option indexes given in order, which the bare 'array of integers' schema does not convey, but attempt_id is entirely undocumented — is it returned by start_test? Does it expire?

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 verb (submit) and object (answers) and clarifies the value format, but never says what is being submitted to — presumably a skill-test attempt given siblings like start_test and list_skill_tests. An agent can infer the domain, but the tool itself is not explicitly distinguished from its siblings.

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 call this versus start_test or list_skill_tests, and no prerequisite such as needing an existing attempt_id from start_test. The relationship to the test lifecycle is left entirely 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?

No annotations are provided, so the description carries the full behavioral burden. It implies an employer-authorised mutation via '(employer key)', but does not disclose whether the change is reversible, whether the candidate is notified, whether terminal states are locked, or what the response contains.

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?

A single short sentence with the action front-loaded and no filler. It is efficient, though it verges on under-specification rather than optimal brevity.

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 two-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. It should at minimum explain the effect of each status value, permissions required, and any downstream side effects.

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 should compensate, yet it only restates the two enum values already in the schema ('shortlist or reject') and says nothing about application_id format or source. The added meaning over the structured fields is minimal.

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 pair (shortlist/reject) and resource (application), so an agent can tell it is a state-change action on one application rather than a listing or creation tool. It does not explicitly name any sibling, however, so it stops short of full 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_applications or apply. The '(employer key)' note hints at the actor but never states the condition under which shortlisting versus rejecting is appropriate.

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?

No annotations are provided, so the description must carry the full behavioral burden. It says nothing about authentication, whether the operation is destructive to existing profile data, what happens to fields that are omitted, or what the response looks like. 'Create/update' also raises an unresolved question of how the tool decides which mode to use.

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 single sentence is short and front-loaded, so it is not verbose. However, the brevity here reflects under-specification rather than efficient conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter mutation tool with zero annotations, no output schema, and 0% schema description coverage, the description is far too thin. It omits parameter meanings and all behavioral context needed to invoke 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 0%, so the description must compensate for six undocumented parameters, yet it only mentions 'profile'. It provides no meaning for skills, suburb, postcode, work_rights, availability, or display_name, leaving all six ambiguous.

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 the resource (seeker profile) and a verb (Create/update), but it conflates two operations and names no specific fields, unlike siblings such as update_application. It is understandable but vague enough that an agent cannot tell exactly what this writes.

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 guidance on when to use this tool versus alternatives in the sibling list, such as add_cert or add_referee, nor any prerequisite like authentication or having an existing profile. Usage must be fully inferred.

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