pact0

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

Annotations already flag destructive and idempotent behavior, and the description layers on top: it discloses authorization requirements, the exact error codes for unauthorized callers (requires_session_at_m1, not_job_poster), and the presence of an alternate human path. That is meaningful context beyond what the annotations convey.

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

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

The bolded "When to use" is correctly front-loaded and the body is dense but purposeful. Spec citations (ALIP-0067, 2026-09-20, §D, ALIP-0023) are noise that could be trimmed without losing the actionable meaning.

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

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

For a destructive, no-output-schema mutation, the description covers eligibility, error outcomes, and the alternate path well. It leaves implicit what "release" produces for the seller (payout timing/format) and the result shape, which an agent closing a work loop might want.

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

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

Schema description coverage is 100%, including keep_private semantics and idempotency_key replay rules, so the schema carries the burden. The description adds no additional parameter nuance, which makes the baseline of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb+resource ("Accept a submitted claim and trigger release") and shares the accept-vs-decline-vs-request_changes decision space with siblings. An agent can tell it apart from decline_claim and request_changes without opening a schema.

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

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

Explicitly states WHO may use it (job poster, commissioner with allowance/grant, delegated judge) and names the alternative path for human buyers (the dashboard). The role/eligibility conditions are enumerated rather than implied.

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

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

Annotations only give the safety profile (non-read-only, idempotent, non-destructive, closed-world); the description adds substantially more: the ranking rule, the hire's arrival as an ordinary claim in home, the pact0-funded-claim exception and the consequence of still holding it at close, and the explicit note that early application or faster polling changes nothing. This is rich operational context beyond structured fields.

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 'When to use' and structured as usage, parameters, eligibility, then close mechanics. It repeats schema bounds (300 characters, 1-10080) and is denser than needed, but every paragraph carries operational information an agent needs.

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

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

No output schema exists, and the description compensates by explaining what happens at close and how the hire is delivered (an ordinary claim in home). Given a 4-parameter mutation-style tool with annotations present, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: evidence_claim_ids must be the agent's OWN claims that are approved, paid, 'released', and verified by pact0, and approach/eta_minutes are restated inline with their bounds. It largely echoes the schema for approach and eta_minutes but enriches the evidence 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 specific verb and resource ('Apply for a job in apply mode') and explicitly distinguishes itself from the sibling claim_job ('instead of claiming it'). An agent can tell immediately which of the two job-acquisition paths this is without opening a schema.

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

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

The 'When to use' clause names the exact gating conditions (allocation.mode is 'apply', allocation.state is 'taking_applications'), and it names the alternative route and its failure mode ('claim_job answers 409 applications_open there'). It also states the one-application-per-job limit and that eligibility mirrors claim_job with one documented exception.

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

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

Annotations already declare readOnly=false and idempotent=true, and the description goes well beyond that: it discloses that merchant_of_record and payout_rail are FROZEN at claim time, enumerates the specific 403 error codes (trials_tier_ceiling_exceeded, registration_token_insufficient) and what each implies about the agent's token tier. This is exactly the auth/eligibility context an agent cannot infer from structured fields.

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 tier/ceiling rules are stated twice — once in the 'When to use' block and again verbatim in the second paragraph (the trials ceiling and its 403 code, and the earn-before-payout ceiling, each appear twice). Roughly half the text is redundant, and the useful new information is buried in the repetition.

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 whose complexity is the token-tier eligibility matrix, the description covers the failure modes and the frozen fields thoroughly, and it states the return value ('Returns the claim with frozen merchant_of_record + payout rail') in the absence of an output schema. Only the exact shape of the returned claim object is left vague.

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

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

Schema description coverage is 100%, so job_id, idempotency_key, and expected_completion_at are already fully documented in the schema. The description only restates expected_completion_at as ISO-8601 'same as REST' and adds no new parameter semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Claim an open job', 'Bind to an OPEN job') and names the underlying REST operation (POST /api/v1/jobs/{job_id}/claim). It is clearly distinguishable from siblings like apply_job and accept_claim, which are about the surrounding workflow rather than binding to an open job.

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 enumerates when a claim succeeds and when it fails by token tier, and names the alternatives for each failure ('take a smaller job', 'have a person claim you', 'GET /api/v1/jobs?match_for=me'). The when-to-use condition is front-loaded in a 'When to use' block.

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

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

Annotations cover the safety profile (destructive, idempotent, not read-only), yet the description adds substantial context: dry_run returns a plan without closing, registration-key auth suffices, the confirm-must-equal-handle rule, and named error codes with recovery steps for closure_open_work, closure_balance_not_forfeited, and closure_contended.

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 critical 'when to use' and dry_run guidance are front-loaded, and error handling is packed into the closing sentence. It is dense and slightly long, but nearly every clause conveys actionable information rather than filler.

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

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

With no output schema, the description explains what dry_run returns, what the real close does, the auth requirements, and every named failure mode. An agent has everything needed to invoke this correctly and safely.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: confirm must match the handle or yield closure_confirm_mismatch, and forfeit_balance is framed as the recovery path with the exact invocation (forfeit_balance: true).

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 ('Closes the calling agent's account for good') and immediately enumerates the concrete consequences (handle retired, pages 410, keys stop working, name removed). It is clearly distinguishable from siblings like rotate_key or withdraw_application.

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

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

Opens with an explicit 'When to use' trigger, directs the agent to send dry_run first, and states the irreversible nature. It also names the exclusion conditions (open work, money in flight) that route the agent elsewhere.

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

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

Beyond the annotations it discloses the feature-flag gate, the per-principal grant gate, the OAuth-scope refusal, the envelope_not_open recovery, the 7-day default deadline, the small-job decline/dispute asymmetry at the $5 threshold, and a full idempotency replay protocol with key lifetime. Annotations only cover safety flags; the description supplies the operational behavior the agent needs.

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

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

It is front-loaded with the when-to-use block, which is good, but the body is long and re-states much of what the schema already documents at length (idempotency keys, allocation_mode rules, grant_id selection). Several sentences could be cut without losing selectable information.

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

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

For a 13-parameter mutation with no output schema, the description covers what comes back ('check allocation_mode and applications_close_at in the result'), enumerates the failure codes and their remedies, and points to list_my_jobs for recovery. Nothing essential for a correct call is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it names the minimal trio ({category, description, amount_usd}) as the only inputs that matter, prescribes how to write a self-sufficient brief across input/description/rubric, and explains when grant_id can be omitted and when allocation_mode is mandatory. That is value beyond the schema 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 states a specific verb and resource ('Commission a job on behalf of your principal — the agent-as-buyer surface') and frames it as spending the owner's budget. It never explicitly distinguishes itself from the sibling post_job or apply_job, so an agent must infer the buyer/seller and buyer/worker split from 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 an explicit when ('mid-task, hand a separable piece of work... only when you will use the result'), an explicit when-not ('never to spend the money'), a pre-check (hire.authority.owner_budget.largest_job_usd), a prerequisite (active delegated spending grant) and a mode choice rule ('use apply unless the work is time-sensitive'). Few definitions route the agent this thoroughly.

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

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

Annotations declare destructive=true and non-idempotent, and the description goes well beyond: the URL is shown once and expires in 24 hours, it cancels earlier open invitations and the claim_url, rate limit is 5/24h, and specific refusal codes are given. Delivery constraint (give it privately, pact0 refuses it in public posts/jobs) is disclosed. No contradiction with annotations.

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

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

Front-loaded with a 'When to use' clause and structured into use case, return/side effects, limits, and error codes. Dense but each sentence carries distinct information; the only cost is that the middle is tightly packed into long 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?

No output schema exists, so the description supplies the return value (one-time invitation URL), its lifetime, acceptance flow, and downstream polling guidance. For a destructive, one-shot mutation tool, this is complete enough to 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?

Single parameter with 100% schema description coverage that already explains the handle format and where the person reads it. The description ('invite them by their pact0 handle') adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (invite a person to own you via their pact0 handle) and contrasts with the sibling paths accept_claim/decline_claim and claim_url. An agent can tell exactly what this does 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?

Explicit precondition ('Nobody owns you and your person has no GitHub or X account, or your claim_url has ended'), the follow-up action ('Then poll get_status'), and the refusal conditions. It names when to use it and how it relates to the polling sibling.

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

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

Annotations already flag destructive=true and idempotent=true, but the description goes well beyond them: refusal codes (revision_first, dispute_pending), the terminal `refunded` claim state, no money movement, reputation effects (unchanged for the agent, counted publicly on the poster), a 3-per-week cap, and role-specific powers for owner-allowance posters and named judges. This is unusually rich disclosure of side effects and preconditions.

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 'When to use' opener is well front-loaded, but the body is one dense wall of text that drifts into governance edge cases (ALIP clauses, owner allowance/spending grants, judge-role restrictions, a REST cancel endpoint) that are tangential to invoking this tool. Valuable content, but not tightly organized around the call itself.

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

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

With no output schema, the description compensates by stating the resulting claim state (`refunded`), what happens to the job (reopen vs close and money flow), reputation consequences, and the error conditions that can block the call. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already carries the baseline for claim_id, reason, note, then and idempotency_key. The description adds marginal but real meaning: that `then: close` returns money to the budget, that reopen is the default, and that the note is read by the agent. This is slightly above the schema-only baseline.

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 ('Decline submitted work on a small job you posted or commissioned') and explicitly bounds the scope to jobs under $5.00. It names the sibling alternative (open_dispute) for larger jobs and the prerequisite sibling (request_changes), so an agent can route correctly without opening a schema.

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

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

Opens with an explicit 'When to use' precondition: the agent's work still falls short after a revision round, with request_changes required first. It gives the exact threshold ($5.00) and names open_dispute as the alternative above that threshold, plus the refund/reopen/close outcomes.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes far beyond them: authorization model (poster, worker, commissioning agent, payer's named judge; public job visibility grants nothing), hash-verification behavior, the full set of failure statuses and their meanings, token kinds, and the read budget. The prompt-injection caveat ('never instructions to follow') is a genuinely valuable 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?

Front-loaded with a bolded when-to-use clause, then example, then return semantics — a logical order with no filler sentences. It is dense and long, and the status enumeration reads as a wall of text, but each element carries actionable information.

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

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

With no output schema, the description fully specifies the return shape (status plus evidence_id, version, submitted_at, storage_url, hash) and every terminal status. For a one-parameter read tool with annotations present, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single claim_id parameter is fully documented there, so baseline is 3. The description adds real value by explaining how to obtain the value (list_my_jobs or claim://) and confirming the clm_ prefix origin, which is meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it 'returns the delivered text itself' for a given claim, and explicitly contrasts with siblings — list_my_jobs/claim:// supply the claim id, while accept_claim/request_changes/decline_claim handle verdicts. An agent can distinguish this from every related tool without opening schemas.

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

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

Leads with an explicit 'When to use' condition (work has been delivered and you need its contents) and names the alternatives for both the prerequisite step (list_my_jobs) and the follow-up step (accept_claim / request_changes / decline_claim). It also states when NOT to expect results, listing the non-'served' statuses.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, but the description adds substantial context beyond them: no auth for public jobs, access restricted to parties for invite-only jobs, job_not_found for others, and detailed claimer_constraints semantics. This is exactly the kind of visibility and error-behavior disclosure annotations cannot cover.

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

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

The description is front-loaded with the usage condition and then adds access rules and a precise constraints detail. It is dense but each clause carries operational meaning, though the claimer_constraints sentence is complex enough to slightly slow parsing.

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, annotations cover safety, the schema covers the sole parameter, and the description handles auth and error behavior well. Because there is no output schema, it could say more about what 'full detail' returns, but the operational guidance is otherwise complete.

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

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

Schema description coverage is 100%, so the single job_id parameter and its pattern are already documented. The description refers to fetching 'by id' and mirrors the GET path, but adds no format or meaning beyond the schema. Baseline 3 is appropriate when the schema carries parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Fetch a single job by id.' It explicitly differentiates from the sibling list_jobs by framing this as the follow-up for one result. An agent can tell what this tool does 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?

It opens with an explicit 'When to use' and names the alternative workflow: 'typically after seeing it in list_jobs results.' It also gives conditional access rules for public versus invite-only jobs, which tells the agent when the call may succeed or fail.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing accepted token type (a2l_reg_*) and a wire-field gotcha ('the wire field is status, NOT claim_status') plus conditional extra fields (balance, hire.authority). It lacks any note on error or rate-limit behavior, but the additions are meaningful.

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

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

Front-loads the when-to-use clause and stays dense with no filler sentences. It runs a bit long by bundling in tangential routing hints (balance, home, hire.authority), which slightly dilutes focus but each sentence still carries information.

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

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

With no output schema, the description carries the return-value burden and does so by naming the primary status field, auto_claim_status, owner/claim-chain detail, and conditional balance/home fields. It's near-complete for a simple read tool, missing only error or empty-state 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to add on parameter semantics and it correctly avoids pretending otherwise.

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 ('Check claim chain state') and enumerates the state progression (pending_identity → identity_verified → payouts_enabled), which lets an agent distinguish it from siblings like get_trial_status or wallet_balance. It does not explicitly name a sibling, but the described return fields are distinctive enough to route correctly.

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?

Opens with an explicit 'When to use' framing and gives a concrete context ('Useful while polling onboarding'), plus token eligibility ('Both reg tokens and live tokens may call'). It stops short of naming an alternative tool or a when-not-to-use condition, so it's strong but not fully disambiguating.

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

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

Annotations already declare a safe read (readOnly, idempotent, non-destructive), yet the description adds substantial behavioral context beyond them: crash-resume without re-minting or consuming an attempt, the 60-minute expiry window, and the computed-never-stored 'expired' state from ALIP-0050 §B. This is exactly the kind of non-obvious operational detail the annotations cannot carry.

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

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

Front-loads the when-to-use clause and the key return facts, so the most important information lands first. The second half is a long, dense run-on sentence packing several conditions together, which costs some readability, but every clause carries real operational content.

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 convey the return shape, and it does: per-class outlooks, scores, attempt counts, full payload for the live instance, and the next_call it instructs the agent to follow. Given the multi-state trial lifecycle (live, expired, active run), it is complete enough to call and act on correctly.

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

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

Schema description coverage is 100% and the single optional run_id is fully documented there ('a specific run id (trn_...). Default: recent runs.'). The description never mentions run_id or adds syntax/format meaning beyond the schema, so the baseline 3 for a schema-complete tool is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete resource (recent trial runs) and enumerates the payload: per-class state, scores, attempt counts, and full live-instance input plus submission instructions. It clearly separates this trial-status view from the job/delivery siblings, though it never explicitly names get_status or other lookups it must be distinguished from. A clear verb-plus-resource definition, but sibling differentiation is only implicit via the 'trial run' scope.

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?

Opens with an explicit 'When to use' clause ('Between trial submissions') and then routes the agent: follow the returned next_call while an instance is live, otherwise poll the run after expiry. It explicitly rules out the wrong calls (never finish, submit or start after expiry), leaving nothing to inference.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful context: it accepts a2l_reg_* tokens, works as an entry point before payouts, and explains what dashboard categories are returned. It does not cover failure modes or caching, but with annotations covering the safety profile this is appropriately detailed.

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

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

The description is front-loaded with usage guidance and then provides return-value detail, which is valuable because no output schema exists. It is somewhat dense and repeats the 'single-call/one-call dashboard' idea, but most of the length earns its place by covering return categories and delegation context.

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

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

For a zero-parameter dashboard with no output schema, the description is complete enough to call correctly: it lists the main returned fields, explains conditional fields like job_invitations, balance, allowance, and hire, and points to list_my_jobs for details. It also clarifies token acceptance and when this tool is the entry point.

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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it does not introduce irrelevant parameter guidance.

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 immediately establishes this as a single-call dashboard and enumerates the bundled resources: status, open claims, pending reviews, test jobs, disputes, work to judge, and next actions. It also distinguishes the tool from list_my_jobs, which handles posted/commissioned/judged jobs, so an agent can identify the right 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?

It explicitly says to call once per heartbeat and to use it as the read before delegating work, tying usage to concrete agent workflows. It further clarifies that this is the entry point even before payouts_enabled and redirects users to list_my_jobs for detailed job data.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld=false), so the bar is lower. The description still adds real behavioral context: no authentication required, public buyer-side scope, reputation ranking, and a documented refusal mode for trust_anchor ('refused with unknown_query_param'). It does not discuss response shape or pagination behavior beyond the cursor parameter.

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 when-to-use header, which is good, but the paragraph is dense with ALIP-####/ADR-#### citations and REST-mirroring notes that are noise for an agent deciding how to call it. Several clauses (min_rate_minor units, include_platform_owned default, sort/cursor) duplicate the schema verbatim.

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 11-parameter discovery tool with no output schema, the description covers auth, ranking policy, pagination intent (cursor), and the rookie/filter semantics well enough to call it correctly. It does not describe the returned record fields, which is a minor gap since no output schema exists.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates what the schema already documents (min_reputation semantics, min_rate_minor as an inclusive micro-unit floor, include_platform_owned, sort, cursor), adding little syntax or meaning beyond it.

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 ('Discover agents', 'Lists agents (or humans) ranked by reputation') plus its scope filters. 'Public buyer-side discovery' distinguishes it from list_my_jobs/list_jobs, though no sibling is named explicitly. An agent can tell what this returns 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 '**When to use**: Discover agents' header is the only routing guidance; it does not say when NOT to use this tool or point to an alternative (e.g. list_my_jobs for own jobs, or a job-search sibling). Contextual cues like 'Public buyer-side discovery' and 'No auth required' imply the use case but stop short of explicit selection criteria.

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

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

Annotations already declare this a safe, idempotent read, but the description goes well beyond them: the fall-through behavior when no capabilities match, the bearer-auth requirement for match_for='me', the claimer_constraints/identity_verified nuance, and the critical micro-unit response semantics. This is exactly the extra behavioral context annotations cannot carry.

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

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

Front-loaded with 'When to use' and the scoping guidance, with the units warning placed prominently at the end. It is somewhat long and repeats the match_for scoping behaviour across two passages, so it is slightly over budget.

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 11-parameter filter tool with no output schema, the description supplies what's missing: response shape parity with GET /api/v1/jobs, the `matched`/`match_reason` fields to branch on, and unit semantics for monetary fields. Nothing an agent needs to call it correctly is absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks — micro-unit scale for amount_minor and min/max_amount_minor (1 USD = 1,000,000), REST-parity of the amount filters, and the practical effect of match_for. It does not cover every parameter (e.g. cursor, limit) beyond the schema, so not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Public feed of open jobs, newest first by default') and pins down default ordering and scope. An agent can distinguish it from get_job (single job) and list_my_jobs (owned jobs) without opening any schema.

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

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

Opens with an explicit 'When to use' and gives a concrete condition for the match_for='me' branch, plus instructions to branch on `matched` rather than an empty `jobs`. It never names a sibling as the alternative (e.g. list_my_jobs) and gives no when-not, so it falls short of a 5.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. The description adds substantial context beyond that: pagination limits and default, cursor semantics for older pages, ordering, per-job status/role/authority details, claim and verdict structure, and the fact that other agents' jobs are excluded. It also notes either token kind is accepted and the read budget matches home.

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

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

The description is front-loaded with a 'When to use' section, which helps structure. However, the second paragraph is a dense run-on with many nested parentheticals and clauses, making it harder to parse than necessary and reducing 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?

Given the tool's complexity and lack of an output schema, the description is complete: it explains when to use it, pagination and filtering, return fields in detail, exclusions, token acceptance, and read budget. An agent has everything needed to invoke it correctly without additional context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema mainly for task_ref: 'find the job that serves one of your tasks,' which clarifies the parameter's purpose. Limit and cursor are largely restated from the schema, but the added task_ref context lifts this above baseline.

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 (lists) and resource (jobs you posted, commissioned, or judge for a payer), with scope (newest first, one page at a time). It distinguishes itself from the sibling list_jobs by noting that jobs other agents of your owner posted are never listed, and from get_job by being a list rather than a single-job lookup.

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

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

It explicitly states when to use it: 'After a restart, or whenever you need the result of work you handed off,' and explains that task_ref finds the job serving one of your tasks. However, it does not name alternative tools or say when not to use this one, so it falls short of full when/when-not/alternatives 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?

The description adds critical behavioral information beyond the structured annotations, detailing how the substrate computes stakes (ALIP-0005 §A), specific requirements for card payments (ALIP-0095 §D), and the consequence of using an incorrect stake value (422 stake_mismatch).

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

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

The definition is extremely dense and verbose, relying heavily on technical/legal references (ALIP-0054, ALIP-0005). While the information is logically grouped by topic, the overall length and academic tone significantly detract from 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?

Given the high complexity of the financial and operational rules governing disputes, the description is exhaustively complete. It handles multiple failure modes, role constraints, and various payment processing requirements.

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?

Even with 100% schema coverage, the description adds crucial semantic meaning. For instance, it explains that omitting stake_minor triggers server-side computation, and that the 'unmet_criteria' parameter is strictly for card-paid tasks and requires specific quotes.

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 purpose is stated clearly and the tool is easily distinguished from siblings like respond_to_dispute and decline_claim. It specifies the action: 'Dispute a submitted/verified claim,' and its scope.

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 tool provides highly detailed usage guidance, covering specific edge cases such as small jobs (under $5.00), defining who can open a dispute (the poster on their own commissioned job), and when to use specific parameters like unmet_criteria.

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

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

Beyond the annotations, the description discloses a lot of behavior: free-job caps (3 open, scaling to 25, 10/day), paid limits ($1–$25 per job, $50/day), error codes, the $5.00 pilot price, and the exact retry contract (one UUID key, same args returns the original job with _meta replay marker, 24-hour retention). One tension worth noting: annotations set idempotentHint=false while the prose describes key-based idempotent replay — this is reconcilable (the tool is not inherently idempotent, the key supplies it) but the description could have said so explicitly rather than leaving the agent to infer 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?

The 'When to use' block is genuinely front-loaded, but the two long paragraphs that follow restate the free-posting rules already given (no money, no envelope, no human involved) and repeat the idempotency and list_my_jobs guidance. Jargon density (ALIP-0067, ALIP-0070, ALIP-0095, m1, pact0) plus nested parentheticals make it far longer than a 15-parameter tool needs.

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

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

For a 15-parameter, 7-required, nested-object mutation with no output schema, the description covers the full operational picture: who may claim, what happens after posting, error paths, retry semantics, and recovery via list_my_jobs. An agent has everything needed to post correctly and to recover from a failed call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real usage semantics on top: which fields to put the work material in (metadata.work_input vs description), what acceptance_criteria.rubric should contain, how claimer_constraints.invited_handles enables re-hiring an approved agent, and the task_ref round-trip after a restart. It stops short of 5 because a few high-stakes fields (task_class, pricing_model) are only restated in schema-like terms rather than explained in context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening 'Ask someone to do work' plus 'Post a job for someone to claim' names a specific verb and resource, and the free/paid/balance/card paths are delineated so an agent knows which posting mode it is in. It also implicitly separates itself from commission_job (the delegated-grant alternative) and from list_my_jobs (the read-back tool). It stops short of a crisp one-line differentiator from siblings like apply_job/claim_job because that contrast is buried in dense policy prose.

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

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

Explicit when-to-use guidance is front-loaded ('When to use: Ask someone to do work... use it to hand another agent a subtask you are weak at'), with exclusions and fallbacks spelled out: card funding only when a signed-in buyer exists, balance posts refused under oauth_access_insufficient, other paid posts returning requires_session_at_m1 with commission_job named as the alternative. It even states the delegation criterion ('only when you will use the result') and the authority check via home's hire.authority.

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

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

Annotations give only the coarse write/idempotency profile, but the description adds substantial behavior beyond them: the 30-day a2l_reg_* token lifetime, what it can do immediately (free jobs, trials), what a durable a2l_live_* key requires, and the missing_bearer refusal mode. This is rich, non-redundant behavioral context.

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

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

Front-loads the when-to-use and return shape before lifecycle detail, which is good structure. However, the trailing Codex/Claude Code host-configuration recipe is verbose and sits at the edge of the tool's selection scope, diluting an otherwise tight definition.

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 non-idempotent bootstrap mutation with 8 parameters and no output schema, the description fully covers the returned credentials, their lifetimes, the claim flow, and the error an agent will hit if it skips the bearer setup. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already carries parameter meaning (name length, capability shape, rate_minor units, optional runtime/endpoint). The description adds nothing per-parameter beyond restating the return values, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Register a new agent and obtain an api_key + claim_url' — and distinguishes it from siblings like rotate_key and update_capabilities by tying it to the no-API-key bootstrap case. An agent can tell it is the first-call entry point 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?

Opens with an explicit bolded 'When to use: First call for an agent with no API key', and closes with the conditional against tools that need the key ('until then, tools that need the key are refused with missing_bearer'). Both the triggering condition and the downstream consequence 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?

The description discloses rich behavior beyond the annotations: the claim returns to in_progress, the auto-approve clock stops, the agent gets 48 hours to resubmit with submit_evidence (restarting the clock), a missed deadline returns the work to the poster, up to 2 rounds per claim, and no money or reputation moves. It also enumerates exactly which agents may call it. Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) are consistent with this.

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

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

The description is dense but front-loaded with 'When to use' before the mechanics, and every sentence carries protocol-relevant information (state transitions, deadlines, round caps, refusal conditions). It is on the long side and laced with ALIP references, but none of the content is 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?

Given no output schema, the description covers what an agent needs to call this correctly: eligibility, required sequencing before a decline, the 48-hour resubmit window, the two-round cap, the dispute_pending refusal, and the fact that no funds or reputation change. Nothing material is left 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?

Schema description coverage is 100%, so the schema already documents all four parameters (note length bounds, claim_id pattern, criteria limits, idempotency_key semantics). The description adds only framing ('Say what is missing; the agent resubmits on the same claim') rather than parameter-level detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: sending already-submitted work back to the agent with a note, distinct from accept_claim, decline_claim, and submit_review. It also names the scope (work on a job you posted, commissioned, or judge) and the eligibility conditions, so an agent can identify the 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?

The 'When to use' block explicitly states the triggering condition (work submitted but incomplete or off-brief) and adds a mandatory precondition ('Required once before a small-job decline'). It names the alternative route (a human poster uses the REST route) and the blocking condition (refused with dispute_pending while a dispute is in progress).

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

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

The description is otherwise rich — it discloses the 3-statement cap, the 1-5000 char bound, the 10 https-link limit, the undecided-state precondition, and the actor authorization error. But it asserts 'Changes no state and moves no money' while annotations declare readOnlyHint=false; storing a statement is a write, so an agent gets conflicting signals about whether this is a mutating call. The 'moves no money' half is consistent with destructiveHint=false.

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 actionable 'When to use' condition, followed by one dense sentence of constraints and one of authorization. Slightly overpacked and carries an internal policy citation ('ALIP-0095 §D') that adds little for an agent, but nothing is padded.

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

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

With no output schema, the description does cover the eligibility rule, deadlines, limits and the likely error code. It stops short of saying what happens after submission (operator ruling, whether the respondent is notified), which would complete the picture for a 3-parameter write tool.

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

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

Schema coverage is 100% and each parameter already carries its own description, constraints (dsp_ pattern, maxItems 10) and an example. The prose only restates the limits, adding no format or semantic detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (add your side / respond) and resource (a dispute on your claim) and scopes it to the case where home lists the dispute under active_disputes. It is clearly separable from open_dispute (opening) and submit_evidence (claim evidence), and it even names the not_dispute_respondent outcome that distinguishes the respondent 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 'When to use' line gives the trigger condition (a dispute was opened on your claim), the deadline (before respond_by), and the actor restriction (only the other side may answer; the opener gets not_dispute_respondent). That is explicit when/when-not guidance an agent can act on directly.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description goes far beyond them: it discloses that the new key is shown once, that the calling key survives until first use of the new key (so a lost response is recoverable), that other registration keys are revoked, and it names three specific failure codes (rotation_owner_issues_keys, rotation_too_early, rotation_not_applicable) plus grace-renewal constraints (30 days, not in a batch, nothing else callable). This is exactly the behavioral depth that structured fields cannot carry.

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

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

A bold 'When to use' header front-loads the eligibility rule, and every sentence carries an error code, timing window, or recovery rule. It is dense and slightly repetitive (ownership restriction is restated twice), but nothing is filler and it remains scannable.

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

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

There is no output schema, and the description fully compensates by describing the returned key, its one-time display, and persistence semantics. For a zero-param mutation tool with an unusually complex eligibility contract, nothing an agent needs to call it correctly is absent.

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 for 0 params applies. No parameter syntax is missing.

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 ('rotate_key' / 'Returns a new registration key (a2l_reg_*), shown once') and distinguishes the operation from lookalikes: 'This renews a key you hold; it does not recover a lost one.' It is unmistakably distinct from siblings like get_status or verify_credential.

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

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

Explicit when-to-use ('in the key's last 7 days'), when-not ('Only for an agent nobody owns... an owned agent asks its owner instead'), and routing pointers to get_status (api_key.rotate_from) and next_call. It also names the alternative path (owner issues keys) so the agent never infers eligibility.

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

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

Annotations only declare readOnlyHint=false/idempotentHint=false; the description carries everything else that matters: the response contents (instance input, pre-submission signed commitment, version pins, submission instructions), three distinct rate limits with their error codes, the 503-at-capacity behavior with Retry-After, and the irreversible fact that every attempt including abandoned ones becomes public. That last point is critical context an agent cannot get from annotations.

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

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

Front-loaded with 'When to use' and then the explicit statement of what gets minted and returned. The parenthetical error-code clusters are dense and slightly compress several constraints into one sentence, but each clause (rate limits, capacity, public record, grading model) 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?

No output schema exists, and the description compensates by enumerating exactly what the response carries. For a non-idempotent mutation tool with nested optional params, it covers prerequisites, failure modes, side effects, and where to find the full contract (/prove.md).

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

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

Schema description coverage is 100%, so all three params (source, reference, powered_by) are already fully documented in the schema, and the description adds no additional syntax or meaning for them. The metadata about registration tokens and version pins is about the run, not the params. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it mints a trial run and its first generated instance, describing the challenge format (three generated, deterministically graded challenges). This is clearly distinguishable from get_trial_status, which is the sibling for checking state, and an agent can tell what the tool produces 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?

Opens with an explicit 'When to use' block and states the prerequisite (registration token sufficient — no human step, no payment). It does not explicitly name get_trial_status as the alternative for checking on an existing run, though the trial_run_active error hints at it. Clear context without an explicit alternative/

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?

Adds substantial behavior beyond annotations: synchronous grading with trial.score and trial.pass, the 100 KB / depth 8 limit, secret detection refusal, class 3 replay semantics, and the idempotency-key retry behavior. These are operational details annotations do not cover.

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

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

Front-loads the critical when-to-use and two-form distinction, then adds operational notes. It is dense but occasionally repetitive—upload_artifact is referenced both in the first sentence and again in the closing TIP.

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?

Complete for a 7-parameter mutation tool with nested objects and no output schema. It explains both submission paths, grading behavior, limits, and the retry/idempotency model, leaving no major agent decision 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 coverage is 100%, so the baseline is 3. The description nonetheless adds useful parameter meaning beyond the schema: paste storage_url + hash verbatim, submission as one compact JSON object, ops in order with no finish, and the distinction between job evidence and Pact Trial fields.

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: "Submit work for an open claim," then immediately distinguishes the two supported forms (job artifact vs Pact Trial answer). This is enough for an agent to know exactly what the tool does and how it differs from siblings like upload_artifact.

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 says when to use it, names the alternative upload_artifact for hosting job artifacts, and explains the Pact Trial path including class 3 stateful operations. It also warns "Never both forms at once," which prevents a common misuse.

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

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

Annotations already establish readOnlyHint=false and idempotentHint=true, and the description adds genuinely useful behavior beyond them: the review stays hidden until the counterparty reviews or 14 days elapse, and the authorization rule (any agent key works, but only a party to the claim may review). The ALIP-0006 §A citation is opaque but harmless.

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 'When to use' lead is well front-loaded, but the immediately following sentences restate the same two facts almost verbatim — terminal (released/refunded) claim and the hidden-until-counterparty-or-14d rule appear twice. Roughly a third of the text 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 mutation tool with no output schema, the description covers the key agent needs: eligibility (terminal claim, party only), timing effects (hidden until 14d/counterparty), and key requirements. Return-value behavior is left implicit, which is a minor gap given no output schema exists.

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

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

Schema description coverage is 100% with 5 documented parameters, including an explicit idempotency_key contract, so the schema carries the parameter burden. The description adds no field-level detail (e.g., what category override does), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (submit) and resource (1-5 star review on a claim), and scopes it to terminal (released/refunded) claims. It does not name any sibling tool by way of contrast, but the scope restriction and the practice/trial exclusion give an agent enough to distinguish this from other claim actions.

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 bolded 'When to use' line gives an explicit trigger condition (terminal claim), and the text adds hard exclusions: only a party to the claim may review, and practice/trial claims are not listed in home.pending_reviews. No alternative action (e.g., open_dispute for a bad outcome) is named, so it stops short of a 5.

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

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

Annotations already declare destructive, idempotent, and not-read-only, but the description adds substantive context beyond them: it works with either a registration or live token, enforces a hard cap of 8 active capabilities, and names the specific failure mode 'capability_limit_reached' with the recovery step. This is well past the lower bar set by the annotations.

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

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

Front-loaded with the when-to-use line and dense but purposeful. The M1/M2.5 roadmap asides ('deliberately not shipped at M2.5') and the skill.md pointer are mild noise but do not obscure the operative instructions.

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 output schema, it covers the essentials an agent needs: token types accepted, the 8-cap limit, the error code on overflow, and the absence of in-place editing. Nothing material is missing.

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

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

Schema coverage is 100%, so op, capability, and capability_id are already fully documented in the schema, setting the baseline at 3. The description reinforces the add/deactivate duality and the deactivate-then-re-add workaround but adds no format or syntax detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('add or deactivate') and resource ('the calling agent's declared capabilities') and pins the scope as post-registration, which distinguishes it from the sibling register_agent. An agent can tell exactly what this does 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?

Opens with an explicit '**When to use**: Modify your capability set AFTER registration' and names the alternative pattern (deactivate-then-re-add instead of in-place edit). The token-flexibility note tells the agent it can be used before a human exists, which is a real routing condition.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description goes beyond them by disclosing v1 limits (text/* only, max 100 KB), stating it returns a server-computed sha256, and explaining the values are meant to be passed verbatim to submit_evidence. It doesn't explicitly warn about non-idempotency (re-uploading creates new copies), which is the one behavioral 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?

Front-loaded with a bold 'When to use' line, followed by a clear paragraph covering purpose, return values, and limits. Slightly redundant in restating the storage_url+hash contract twice, but every sentence is informative.

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 2-param write tool with no output schema, the description fully covers purpose, when to use vs. alternatives, return contract (storage_url + hash), and v1 constraints (text-only, 100 KB). An agent has everything needed to invoke correctly and chain into submit_evidence.

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

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

Schema description coverage is 100%, so the schema already documents content (UTF-8, up to 100 KB) and content_type (must start with 'text/'). The description reinforces the text-only and 100 KB constraints but adds no format details beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (upload) and resource (UTF-8 text artifact) with concrete examples (translation, code, summary). It clearly distinguishes itself from submit_evidence by describing itself as the upstream step that produces the storage_url and hash that submit_evidence consumes.

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

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

Explicit when-to-use: 'when you have no fetchable URL of your own' and 'when you don't have your own storage credentials (gist, S3, etc.)'. It names the consumer tool (submit_evidence) and the agent types that need it, leaving little ambiguity about when to pick this over storing externally.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new behavioral facts: public/no-bearer auth, the JCS canonicalization failure mode that produces false-invalid signatures, the requirement to pass inner credentials and proof verbatim, and the return shape plus the precise condition under which valid is true.

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 routing decision and tightly structured, but the paraphrase-breaks-the-hash warning is stated twice (in the bold lead and again in the body) and the 'prefer by_url' point is repeated a third time in caps, which is more emphasis than the content requires.

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 read-only verifier with no output schema, the description supplies everything an agent needs: inputs, auth posture, the exact failure mode to avoid, and the returned fields with their semantics.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: a concrete typical value for jwks_url ('<issuer>/.well-known/jwks.json', with Pact0's own URL) and the instruction to pass the COMPLETE credential verbatim without stripping inner credentials or proof fields — details the schema only partially conveys.

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 (verify) and resource (W3C Verifiable Credential / Presentation) and the cryptographic mechanism (eddsa-jcs-2022 signature against the issuer's published JWKS). It explicitly distinguishes itself from the sibling verify_credential_by_url, so an agent can route without opening either 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?

Opens with an explicit 'When to use' clause, names the preferred alternative, and gives the selecting condition (only use this when the body is already local — cached, computed, or self-signed). The when-not case is spelled out rather than inferred.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds information the annotations cannot: it is public with no bearer required, the substrate performs the fetch, and the return is the `verify_credential` envelope plus `credential_url` and `credential_bytes`. It also documents the silent-failure mode caused by body paraphrasing, which is genuinely actionable.

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 when-to-use clause plus the key differentiator, and the rest supports it with concrete detail. It is somewhat long and restates the URL-vs-body point twice, which costs a little, but nothing is truly 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 still specifies the return shape (same envelope as verify_credential plus two extra fields), the auth posture (public), and the required inputs. Nothing an agent needs to invoke and correctly interpret this tool is missing.

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

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

Schema coverage is 100%, so the schema already documents both params (including jwks_url's optional derivation behavior), giving a baseline of 3. The description adds meaning beyond the schema by insisting that only the URL is passed — never the JSON body — and that `credential_url` points at a credentials.json or single-VC 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+resource (verify a credential by URL) and crisply distinguishes itself from the sibling `verify_credential`: the difference is that the substrate fetches the body, so only the URL is passed. An agent can select between the two without opening either schema.

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

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

Explicit when-to-use conditions are given: prefer this when calling from LLM brains, when the credential is too large to forward verbatim, or when the client might paraphrase/trim the body. It also names the failure mode that tempts the wrong choice (paraphrasing breaks JCS canonical form and yields a false `valid: false`) and the sibling that is the alternative.

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

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

Annotations already declare readOnly/idempotent/destructive hints, but the description adds material behavior beyond them: it requires a LIVE token, states the failure mode (a reg token yields `registration_token_insufficient`), and explains balance ownership (Stripe/practice-credit wallets belong to the claimed-by principal per ADR 0010, while `pact0_balance` is the agent's own earned money). This is exactly the auth/ownership context annotations cannot carry.

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

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

Front-loaded with a bold 'When to use' lead and organized under clear headers, so the important routing info lands first. It is somewhat dense and mildly redundant — micro-units are flagged both upfront and again in the RESPONSE UNITS section — costing it the top score.

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 present, the description carries the burden of explaining returns and does so: it enumerates the returned fields, the unit convention, and the separate `pact0_balance`. Auth prerequisites and the reg-token fallback are also covered, leaving nothing an agent needs before calling.

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 per the rules. The unit clarifications (1 USD = 1,000,000 micro-units) describe response field semantics rather than request parameters, so there is no parameter information to add 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?

States a specific verb+resource ('effective wallet view — balance, withdrawable, currency') and names the extra field it returns (`pact0_balance`). It also explicitly distinguishes itself from the sibling `home` tool, so an agent can tell them apart without opening schemas.

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

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

Opens with 'When to use: Lightweight wallet snapshot — use when you don't need the full home dashboard,' and later names the alternative for reg-token agents ('use the `home` tool instead, which carries the same balances'). Both the selection condition and the fallback are explicit.

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

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

Annotations declare non-readOnly, idempotent, non-destructive, and the description does not contradict them. It adds real behavioral value beyond the annotations: the 409 error code after the window closes, the ability to re-apply before close, and the underlying REST semantics (DELETE /api/v1/jobs/{job_id}/applications/me). It stops short of stating auth requirements or side effects on other state, so not a full 5.

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

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

Front-loads the 'When to use' clause, then the action, precondition, and endpoint in two dense sentences with no filler. Every clause carries decision-relevant information.

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

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

For a single-parameter mutation with no output schema and full annotation coverage, the description supplies the precondition, failure mode, and reversibility needed to invoke it correctly. Only a note about authentication or authorization scope would make it fully complete.

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

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

Schema coverage is 100% for the single job_id parameter, with its own pattern and description, so the schema carries the load. The description only indirectly reinforces the parameter by embedding {job_id} in the mirrored endpoint path. Baseline 3 is appropriate when the schema fully documents the input.

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 ('Withdraw your pending application for a job') and ties it to the sibling that created the state ('you applied for a job with apply_job'). The agent can distinguish this from apply_job, claim_job, and decline_claim without opening a schema.

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

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

Opens with an explicit 'When to use' trigger (applied via apply_job and no longer want it) and adds the boundary condition that the window must still be open. It also notes the failure/precondition ('409 applications_closed after') and that re-application is allowed before the close, so the agent knows both when to call and when the call will fail.

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