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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about idempotency, duplicate-application behavior, auth requirements, or what the call returns. Only the implicit 'apply' verb signals this is a mutation, and the '(seeker key)' fragment hints at an identity requirement without explaining it.

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 padding, which is structurally sound. However, it is under-specified rather than genuinely concise, and the parenthetical adds ambiguity instead of information.

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

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

A two-parameter mutation tool with no annotations, no output schema, 0% parameter coverage, and no explanation of side effects or return value is left almost entirely undocumented. An agent cannot call this confidently.

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 neither parameter is documented. Worse, the description references a 'seeker key' that is not a parameter at all, while the actual optional 'cover_note' parameter goes entirely unmentioned.

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 verb+resource pair ('apply to a job') that is distinguishable from siblings like update_application and list_applications. The parenthetical '(seeker key)' is cryptic and muddies rather than sharpens the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to apply versus the adjacent lifecycle tools (update_application, list_applications, claim_listing), and no prerequisites such as having a completed profile or an existing application. The agent must infer all of this 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 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?

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?

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?

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?

With no annotations, the description carries the full burden. It discloses the authorization scope (must own the job) and that results carry verified badges, which is useful. It says nothing about pagination, ordering, or result limits for what is presumably a potentially long applicant 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 compact sentence with the resource and the ownership constraint front-loaded. No wasted words, though the parenthetical '(employer key)' is slightly cryptic.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, authorization scope, and a hint of return content (verified badges). It is adequate but leaves pagination and result-volume behavior unstated, which matters for an applicant-list endpoint.

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 job_id parameter, but the parameter is self-describing and the description ties it to 'a job you own'. No format, id source, or constraint detail is added beyond that.

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 (List) and resource (applicants) scoped to 'a job you own', which is more precise than a bare 'list applications'. It does not name a sibling such as search_seekers or list_bot_applicable_jobs, so the agent must infer the boundary itself.

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 'a job you own (employer key)' implies the caller must be the employer and supplies the usage precondition, but no explicit when-to-use/when-not or alternative tool is named. Usage is inferable 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 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 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 must carry the behavioral burden, and it does disclose useful traits: an auth prerequisite (employer key), a verified-ABN requirement, a credit cost, and that Fair Work/moderation warnings are returned. It omits the key outcome detail — whether warnings block the post, whether the listing goes live immediately, and whether the action is reversible — so it is helpful but incomplete for a mutation 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?

One compact sentence with the action front-loaded and supporting facts parenthesized — no filler. It is arguably too terse for an 8-parameter mutation, but the sentence itself is efficient and well-ordered.

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, no-annotation mutation tool with no output schema, the description is thin. It does cover the warning return (standing in for output info) and eligibility, but leaves parameter meaning, failure behavior, and the state change after posting entirely unexplained.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does not. It mentions an 'employer key' that is not even present in the schema, while title, location, description, skills, and the pay_min/pay_max/pay_unit fields get no explanation beyond their names; only the two enums are self-documenting.

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 ('Post a job'), which clearly distinguishes it from read-oriented siblings such as search_jobs and list_bot_applicable_jobs. It also notes the return content (warnings). It stops short of naming an alternative or contrasting with a sibling explicitly, so it lands at 4 rather than 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?

The parenthetical gives real preconditions — an employer key, ABN verification, and a 1-credit cost — which tells the agent whether it is eligible to call the tool. However, it never says when to prefer this over related tools or what to do if preconditions fail; 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 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 no annotations provided, the description carries the full burden of behavioral disclosure but falls short. It hints at behavioral aspects by mentioning 'login_required' and 'anti_bot_seen' for sourced jobs, and 'apply_mode' values that indicate automation compatibility (e.g., candidate_bot_ok). However, it does not explain the implications for authentication, rate limits, or what happens when searching with different source parameters. For a tool with no annotations, this is insufficient to inform the agent about critical behaviors like whether it requires login or has usage restrictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single long sentence that is dense and front-loaded with technical terms, which hinders readability. It efficiently covers many concepts in minimal space, but the lack of structure (e.g., breaking into bullet points or shorter sentences) makes it less accessible. While every part seems intended to earn its place by conveying specific details, the overall density reduces clarity and could benefit from better organization to highlight key points.

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

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

Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It focuses heavily on the 'source' parameter and return-related fields like 'direct_to' and 'apply_mode', but neglects to explain the other parameters or provide basic usage context. There is no mention of what the tool returns (e.g., list of jobs), error handling, or pagination, leaving the agent without a full understanding of how to invoke it correctly. The lack of output schema means the description should compensate, but it does not adequately do so.

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%, meaning the input schema provides no semantic descriptions for any of the 6 parameters (q, near, skills, source, pay_min, work_type). The description only briefly touches on the 'source' parameter by defining its enum values and ranking behavior, but completely omits explanations for the other 5 parameters. It does not clarify what 'q' stands for (likely query or keywords), what format 'near' expects (e.g., suburb or postcode), how 'skills' should be structured, or what 'pay_min' and 'work_type' represent. This leaves significant gaps in parameter understanding, requiring the agent to guess their purposes.

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 implies search functionality through the name 'search_jobs' and usage of the word 'Search' at the start, but it fails to clearly state the primary purpose in a straightforward manner. It jumps into technical details about sourced results and apply modes without first establishing what the tool fundamentally does, such as 'Search for job listings based on various criteria like keywords and location.' The initial phrase 'Search live Australian jobs' is promising but is immediately overshadowed by complex jargon, making the core purpose vague and difficult to parse quickly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when or why to use this tool compared to alternatives. It mentions source parameters but doesn't explain scenarios such as 'Use this tool to find jobs matching your skills' or 'For job applications, use the apply tool instead.' There is no mention of prerequisites, exclusions, or alternative tools like 'apply' or 'list_bot_applicable_jobs' from the sibling list, leaving the agent without direction on appropriate usage contexts.

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 and delivers very little. The parenthetical "ABN-verified employer key" hints at an authorization prerequisite, which is useful, but there is no disclosure of pagination, result caps, default ordering, or whether the call is a safe read. For a 10-parameter search endpoint this is a substantial gap.

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 the resource stated first and the filter inventory following, which is well front-loaded. It is compact rather than padded, though the terse comma-list format sacrifices readability for 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 tool with 10 parameters, 0% schema description coverage, no annotations, and no output schema, the description is not complete enough. Undocumented parameters, absent usage guidance, and no statement of result behavior leave an agent guessing at defaults and constraints.

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 is the only source of parameter meaning, and it does add real value by typing several filters (verified_task is a code, verified_cert a type, verified_skill a badge, min_references is 0-100). However, three parameters (skills, postcode, work_rights) are never mentioned, and the ranges of min_score, min_identity, and min_skills are left unstated.

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 verb ("Search") and a specific resource ("searchable seekers"), with a parenthetical identifying the caller's standing as an ABN-verified employer. It is distinguishable in spirit from search_jobs by the resource noun, but the description never explicitly contrasts the two or defines what a "seeker" is in this domain.

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 or when-not-to-use guidance is given, and no alternative is named. An agent must infer that this is the candidate-facing counterpart to search_jobs purely from the tool name. Nothing is said about required caller state beyond the parenthetical ABN note.

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.