keywordise

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

Annotations already mark this as destructive and non-read-only. The description goes further by revealing concrete side effects: the answer is saved in the person's name, the same question is never asked again, and if it is the last required answer the application is submitted. This gives the agent meaningful expectations beyond the annotations.

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

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

Three dense sentences with no filler. The core action and scope are front-loaded, and the critical constraint 'Only give an answer the person actually stated' is preserved as a clear final warning. Every sentence contributes necessary 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 three-parameter mutation tool with no output schema, the description covers what the tool does, its side effects, and a key safety constraint. It does not explain return values or errors, but that is less critical given the simple shape and the strong behavioral warnings already present.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It maps application_id to 'one application,' question_id to 'one screening question,' and answer to the person's actual stated answer, adding semantic meaning. It does not describe ID formats or origin, but the domain mapping is sufficient for a simple tool.

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 ('Record'), a specific resource (one screening question on one application), and the unusual scope: the answer is written in the person's name and saved to their answer book. It also distinguishes itself from generic save/answer tools by noting that the question is never asked again and that completing the last required answer submits the 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?

The description conveys a clear context—answering a screening question on a specific application—and includes an important constraint: 'Only give an answer the person actually stated.' However, it does not explicitly name or contrast alternatives like save_answer, so an agent must infer when to use this tool versus a 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 declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered; the description adds real context beyond them: it SUBMITS in the person's name, lists prerequisites (saved CV, confirmed email, active plan), and explains that dry_run=true 'prepares and sends nothing'. It stops short of failure/retry behavior, which keeps it from a 5.

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

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

Front-loads the usage trigger, then the sibling comparison, then behavior and prerequisites. Every clause carries information; no filler or restatement of the name.

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

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

For a destructive, non-idempotent mutation with no output schema and half-documented parameters, the description covers trigger, prerequisites, submission semantics and dry-run behavior. It omits what happens on failure or whether an application can be withdrawn, a minor residual gap.

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

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

Schema coverage is only 50% — pool_job_id is documented in the schema, but dry_run has just a default and no description. The description compensates by defining dry_run's semantics ('prepares and sends nothing') and clarifying the single-job scope tied to pool_job_id.

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

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

States a specific verb (apply) and resource (live job), and scopes it precisely to a single result from search_live_jobs. It also explicitly differentiates itself from the sibling apply_to_public_job by naming the parameter that distinguishes them (pool_job_id).

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 the triggering condition ('Use after search_live_jobs when the person picks one of the results'), names the sibling alternative, and adds a required human-in-the-loop step ('Confirm with the person first'). Nothing about when to pick this tool is left 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 signal destructive/non-idempotent/open-world, and the description adds the concrete effects: tailors CV and cover letter, answers employer questions, and SUBMITS in the person's name. It also discloses preconditions (saved CV, confirmed email, active plan), plan accounting, dry_run behavior, and the need to poll status.

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 trigger and packs prerequisites, effects, dry-run behavior, and follow-up into five sentences with no filler. The dense phrasing is appropriate for a destructive action tool.

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

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

Complete for a no-output-schema action tool: it names the preparatory get_public_job call, confirmation requirement, preconditions, dry-run mode, and the polling sibling. 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 coverage is 50%; public_id's format is already documented in the schema, while dry_run has no schema description. The description compensates for dry_run by explaining dry_run=true prepares everything and sends nothing, which is material for correct invocation.

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

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

States a specific action (apply) and target (Keywordise public job by id), with concrete triggers and scope ('that ONE job'). It distinguishes the public-job path from other apply siblings by naming keywordise.com/jobs and get_public_job, though it does not explicitly call out apply_to_live_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?

Gives literal trigger phrases and context ('when the person asks to apply to a job from keywordise.com/jobs'), plus prerequisites and confirmation flow. It does not state when not to use this versus apply_to_live_job or start_apply_run, so it is clear but lacks explicit exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real behavioral context: the submission happens in the person's name, edits persist to the answer book (a side effect beyond the submission itself), and explicit human consent is required. It does not state whether the submission is revertible or what the caller gets back.

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

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

Three tight sentences, front-loaded with the Send-button framing and the core action before the edits mechanics and the consent caveat. The UI analogy costs a few words but earns its place by making the trigger condition concrete.

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, non-idempotent mutation with no output schema, the description covers the trigger condition, the consent requirement, and the persistence of edits. Only the post-call outcome and reversibility are left unaddressed, which is a minor gap given the annotation profile.

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

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

Schema coverage is only 50% (application_id is undocumented), so the description has to carry weight, and it does: edits is defined as a label-to-new-answer map whose keys must match labels exactly as get_application_review renders them, plus the persistent effect on the answer book. application_id is left implicit but is unambiguous by name.

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 (submits an application waiting for review) and anchors it to a concrete UI element (the review screen's Send button). An agent can distinguish it from write-adjacent siblings like update_application_details or apply_to_live_job without opening any schema.

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

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

Gives a clear precondition (get_application_review must report editable) and a hard constraint (only with the person's approval of the answers). It points at get_application_review as a gate rather than spelling out when-not-to-use versus the update/apply siblings, so it stops just short of full alternative routing.

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

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

Beyond the destructiveHint annotation, the description adds valuable behavioral context: access remains until the billing period ends, the action is irreversible from this tool, and the user can resubscribe later. This meaningfully clarifies the consequences of invocation.

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

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

Three short sentences deliver all essential information with no filler. The most important fact (cancellation at period end) is front-loaded, and each subsequent sentence adds distinct value.

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 parameterless destructive action with no output schema, the description fully covers what happens, when it happens, what the user retains until then, and the post-cancellation possibility. Nothing critical 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?

The tool has zero parameters and the schema is empty, so there is no parameter meaning to add. The description correctly avoids inventing parameter-related details, matching the baseline for a zero-parameter tool.

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

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

The description clearly states the action ('Cancel'), the specific resource ('the Pro subscription'), and the timing ('at the end of the current billing period'). It also distinguishes itself from billing-related siblings like get_billing_portal_link by making the cancellation semantics explicit.

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

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

The description provides clear contextual guidance: cancellation happens at period end and access persists until then. It does not explicitly name alternatives or when-not-to-use, but the context is strong enough for an agent to select this over read-only billing tools.

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 disclose this is a non-read-only, non-idempotent mutation, and the description reinforces that with 'Allowed once,' adding a hard business precondition (before first payment) and error behavior ('fails with the app's own sentence'). It does not describe permissions or the return payload, but coverage of behavior beyond the annotations is solid.

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

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

Two tight sentences, front-loaded with the action and benefit, followed by the constraint. No filler. The 'fails with the app's own sentence' phrasing is slightly vague but earns its place by signaling error surfacing.

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 annotations and no output schema, the description covers purpose, effect, precondition, and failure mode. Only the parameter format and the exact failure surface are left thin, which is a minor gap at this complexity level.

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

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

Schema coverage is 0% for the single 'code' parameter, so the description carries the burden, yet it only gestures at meaning via 'the owner of a referral code' and gives no format, length, or validation hints (schema imposes 3-40 chars). Adequate but incomplete compensation for the coverage gap.

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

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

The description states a specific verb ('Record') and resource ('referred by the owner of a referral code') and clarifies the downstream effect (discount plus friend's credit). It implicitly distinguishes itself from the sibling set_referral_code (recording someone else's code vs. setting your own), but never names the sibling explicitly.

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

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

States a clear precondition and exclusion: 'Allowed once, before the first payment; fails ... otherwise.' This tells the agent when the call will succeed and when it won't. It stops short of naming an alternative tool or recovery path when the precondition fails.

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 the operation is not read-only and not idempotent; the description goes well beyond by disclosing side effects (a confirmation email is sent), a gated capability (applying blocked until confirmation), and commercial terms (7-day/5-application trial, then Starter/Pro pricing). That is exactly the extra 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 the action and outcome, with prerequisites and post-conditions following logically. The pricing/tier sentence is the longest and least essential for invoking the tool, though it does inform downstream expectations.

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 covers the return value (an API key), the confirmation-email flow, and usage limits — everything an agent needs to call this correctly and set expectations.

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

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

Schema coverage is 0%, so the description must compensate; it gives real meaning to accept_terms (acceptance of Terms/Privacy plus authorization to apply on the user's behalf) and implies email is where confirmation is sent. The password parameter is left entirely to the schema, so it does not fully close the coverage gap.

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

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

States a specific verb and resource ('Register a new Keywordise account') and adds the concrete outcome ('receive an API key for it'), which cleanly separates it from the sibling login tool.

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

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

Conveys when this applies (new account registration, requires accept_terms=true) and what follows (confirmation email, applying opens after confirmation). It does not explicitly say 'use login instead if you already have an account', so sibling routing is implied rather than stated.

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

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

Annotations already mark this as non-readonly and non-idempotent; description adds crucial behavioral details: the key is shown only once and can't be retrieved later, and there is a quota of five active keys. These are not inferable from schema or annotation.

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

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

Three short sentences with the primary action first, followed by two high-value constraints. No filler or 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 one-optional-parameter create tool with no output schema, the description covers purpose, quota, and the one-time visibility of the key. It doesn't spell out that the label is optional or what happens when the five-key cap is reached, but these are minor given the low complexity.

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

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

Schema coverage is 0% and the description never explains the 'label' parameter or how it relates to the 'machine or assistant' framing. The param name and maxLength in schema are the only signals, so the description adds no semantic value for the one 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?

Description identifies the operation with the verb 'Mint' and the resource 'API key', and qualifies it as an additional key for another machine or assistant. This clearly differentiates it from siblings like list_api_keys and revoke_api_key.

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?

States the intended context: create an extra key for another machine or assistant, and warns that five active keys is the maximum. It does not explicitly name when not to use list/revoke siblings, but the context is clear enough.

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 include destructiveHint=true, and the description adds important behavioral detail: the operation is irreversible, it destroys specific categories of data, and it requires confirm_email to match the account address. There is no contradiction with 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?

Two sentences, front-loaded with the action and scope. The data enumeration is necessary for transparency and the confirmation requirement is stated directly. No filler or redundancy.

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 one parameter, destructive annotations, and no output schema, the description covers action, scope, irreversibility, and the prerequisite for invocation. Nothing needed to call the tool 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?

The schema only defines confirm_email with an email format; the description supplies the essential semantic requirement that it must equal the account's email address. This fully compensates for the 0% schema description coverage.

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 uses a specific verb ('Erase') and precisely identifies the resource ('the account') and everything it contains. The enumerated data types make it easy to distinguish from sibling tools like delete_saved_answer or cancel_subscription.

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

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

The description makes the context clear: this is for permanent, whole-account deletion, not a partial operation. It does not explicitly name alternatives such as cancel_subscription or export_my_data, but the scope is explicit enough for an agent to infer when this tool is appropriate.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the description doesn't need to restate that this is a destructive action. It adds a small amount of behavioral context by requiring the answer_id to come from list_saved_answers, but it doesn't describe what happens if the ID is invalid or already deleted.

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

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

A single sentence delivers the action, the object, and the source of the parameter without any fluff. The parenthetical is efficient and front-loaded information placement is excellent.

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

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

For a one-parameter delete tool with annotations covering destructiveness and idempotency, the description is largely complete. It references the correct sibling for obtaining IDs and gives a clear mental model of the 'answer book.' Lack of output-schema or error-handling detail is a minor gap for such a simple operation.

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

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

With 0% schema description coverage, the description compensates by explaining that answer_id identifies an existing answer from list_saved_answers. This adds meaning beyond the bare string type in the schema, though it could go further by specifying format or validation behavior.

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 uses the specific verb 'Remove' and identifies the resource as 'one answer from the answer book,' making the tool's function unambiguous. The parenthetical reference to list_saved_answers also helps distinguish it from save_answer and other answer-related tools.

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

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

It clearly implies the correct workflow: call list_saved_answers to obtain a valid answer_id, then pass it here. It doesn't explicitly say when not to use this tool or name alternatives, but the intended usage context is clear enough for a simple delete operation.

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

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

With no meaningful annotations, the description carries the behavioral burden. It discloses that the saved CV is used, that inference results are returned for confirmation, and that apply=true saves the rules and re-matches the feed. This gives a clear picture of side effects without contradicting the annotations.

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

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

Three sentences with no filler, front-loaded with the usage trigger and followed by behavior and preset options. Every sentence adds useful 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?

The description covers the main workflow, return value, and conditional persistence. It lacks detail on preset semantics and failure behavior when a sentence cannot be parsed, but for a 3-parameter tool with no output schema it is reasonably complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains sentence with concrete examples and apply with its side effect, but preset is only listed as 'balanced | broad | focused' without explaining what each preset means or how it changes inference. This leaves a meaningful parameter gap.

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

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

The description states a specific action: turning a plain-language sentence plus the saved CV into concrete targeting rules. It also clarifies the output (inferred rules and confirmation chips) and the optional apply behavior, making the tool's role clear even against siblings like update_targeting.

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

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

The description explicitly says 'Use when the person says what they are looking for in their own words,' which is a clear trigger condition. It does not name alternative tools or state when not to use it, but the context is strong enough for an agent to route to it appropriately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds contextual behavior beyond these: the narrative=true option incurs a paid model call and is limited to 60 per hour, plus it clarifies the output contents. This cost/rate-limit information is valuable for an agent to know before invoking the tool.

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

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

The description is three sentences, each earning its place: the first states the use cases, the second describes the core output, and the third explains the optional narrative with its cost and limit. It is front-loaded with the most important information and contains no filler.

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

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

Given the simple two-parameter tool, no output schema, and strong annotations, the description covers the essential return values (match percentage, covered/missing requirements, optional narrative assessment) and the cost implication of narrative. It could be more explicit about whether the output is structured or free-text for the narrative, but the tool is simple enough that this is a minor gap.

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

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

Schema coverage is 50%: job_id is well documented (source from list_matching_jobs or list_my_applications), while narrative is only typed as a boolean with default false. The description compensates for narrative by explaining that true adds a short written assessment with strengths and gaps and that it is a paid, rate-limited call. This adds meaning beyond the schema, though job_id needs no further explanation.

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

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

The description states a specific verb ('explain'), the resource ('job match' for one vacancy), and the exact outputs (match percentage, covered and missing requirements). It also lists three natural-language triggers ('is this job a good fit', 'why this match', 'what am I missing for this role') that help an agent recognize when this tool is relevant, distinguishing it from sibling tools like get_match_status or list_matching_jobs.

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

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

Explicitly begins with 'Use for ...' and gives three user-intent phrases, which is strong when-to-use guidance. It also scopes to 'one vacancy' and notes the paid, rate-limited nature of narrative=true. It lacks an explicit when-not-to-use or alternative tool mention, but the use-case phrasing is clear enough for proper routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those: the result is delivered as a file, and large accounts receive different handling. 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?

Two sentences with no filler. The first sentence front-loads the core purpose and data categories; the second adds a concise caveat about large accounts. Every word earns its place.

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

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

For a zero-parameter export tool, the description covers what is exported, the output format (one JSON file), and the large-account exception. Since there is no output schema, the description reasonably explains the return shape. It could be slightly clearer about how the file is delivered, but it is sufficiently 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?

There are zero parameters and schema description coverage is 100%, so the schema leaves nothing for the description to clarify. The description appropriately focuses on the output contents rather than parameters, and the 0-parameter baseline of 4 applies.

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

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

The description clearly states the tool exports 'the account's complete data as one JSON file' and enumerates the included categories (profile, targeting, matched jobs, applications, etc.). This specific verb+resource framing distinguishes it from the many list_* and granular siblings, which only return subsets.

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

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

The description implies this is the tool to use when a complete account export is needed, and it gives a when-not by noting that large accounts are directed to download the data in the app instead. It does not name sibling alternatives explicitly, but the exclusion is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful scoping context: the data belongs to the account behind the calling key, which clarifies the operation's anchor and why zero parameters suffice. 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?

A single dense sentence that front-loads the scope ('The account behind this key') before a compact colon-list of return contents. Every clause carries distinct information — identity, verification, plan details, key count — with no filler or redundancy.

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 read-only getter with no output schema, the description carries the return-value burden well, enumerating fields in commendable detail. Minor gaps remain: terms like 'applications used' and the exact shape of subscription state are slightly ambiguous, and error behavior is unmentioned, but nothing needed to invoke the tool 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?

The tool takes zero parameters and the input schema has 100% coverage, so the baseline-4 rule applies. The description's scoping phrase ('behind this key') implicitly confirms the account is resolved from the caller's credentials rather than from any 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 resource ('the account behind this key') and enumerates exactly what it returns: email, confirmation status, plan state (trial days, applications used/remaining, subscription), and active API key count. The scope is precise and informative, though it does not explicitly differentiate from overlapping siblings like get_my_profile or list_api_keys.

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

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

Provides no when-to-use guidance, exclusions, or references to alternatives. With 47 siblings including get_my_profile, list_api_keys, and get_billing_portal_link, the agent must infer purely from the field list when to select this tool; the description never addresses the choice among similar getters.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: some of these facts may not be filled in ("which of them are still missing"), warning the agent that responses can be partial and that it should not assume complete data.

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

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

A single dense enumeration followed by one short redirecting sentence, with the "read before..." guidance placed at the end. The field list is long but earns its place because no output schema exists; the phrasing "The facts application forms ask beyond the CV" is slightly indirect but compact.

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

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

With no output schema and no parameters, the description carries the burden of telling the agent what comes back, and it does so field by field, including the missing-values nuance. It omits any indication of how these facts relate to or are updated alongside the CV/profile, but for a read-only getter it is largely sufficient.

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 no parameters, so there is nothing for the description to disambiguate and the baseline is 4. The field list it provides is about return content rather than inputs, so it neither helps nor hurts parameter understanding.

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 concretely enumerates what the tool returns (address, postcode, phone type, work authorisation, sponsorship, salary expectation, screening answers, plus which are missing), which for a zero-parameter getter effectively states the resource. It stops short of distinguishing itself from closely named siblings such as list_facts_to_provide, get_profile_gaps, and get_my_profile, which an agent could easily confuse it with.

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?

"Read before telling the person what an application may be waiting for" implies a use context (answering questions about pending application data), so guidance is present but only implied. No alternatives are named and no exclusion is given, even though update_application_details and list_facts_to_provide are near-neighbours that an agent should be routed away from or towards.

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, idempotentHint and non-destructive, so the safety profile is covered. The description adds real context beyond that: the provenance taxonomy of returned values and the fact that an `editable` application's answers are the ones about to be sent. It does not mention auth or pagination, but for a simple read that is acceptable.

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

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

Two sentences, front-loaded with the core payload description, no filler. The parenthetical provenance list and the `editable` note both carry information an agent needs, so nothing is wasted.

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

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

Since there is no output schema, the description must carry the return semantics, and it does describe the shape of the response (fields, values, provenance) plus the `editable` interpretation. It is complete enough to call correctly, with only the parameter's identity left unspecified.

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

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

Schema description coverage is 0% for the single application_id parameter, so the description must compensate. Its opening phrase 'For one application' conveys that the call is scoped to a single application, which lightly implies the parameter's role, but it never explains the identifier itself or its format.

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

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

The description gives a specific verb+resource+payload: for one application it returns every form field with its value and provenance (CV, saved answer, person, or model). That is far more specific than the name alone and implicitly separates it from get_application_details. It stops short of naming or contrasting any sibling, so it lands at 4 rather than 5.

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

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

There is no when-to-use statement, no prerequisite, and no guidance about alternatives such as get_application_details or list_my_applications. The second sentence describes a state condition (`editable`) but never says when an agent should prefer this call.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the heartbeat detail, 'from a heartbeat, not a status claim', which is a meaningful behavioral disclosure beyond what annotations state. No contradiction.

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

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

One compact sentence that front-loads the main purpose, then lists the exact status data included. Every part earns its place and there is no filler.

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

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

Given there is no output schema and no parameters, the description covers the main expected signals: running status, processed counts, current job, and result states. It does not specify exact response formatting or behavior when no latest run exists, but this is a low-complexity status tool so the description is largely sufficient.

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 and the schema covers everything needed, so there is nothing for the description to add. This matches the baseline for no-parameter tools.

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: it gets the apply run status. The description enumerates concrete data it returns (processed of total, current job, confirmed, needs review, skipped, closed), which clearly separates it from siblings like list_run_history.

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?

Clearly implies the use case is checking the live status of the latest apply run. However, it never explicitly says when to prefer list_run_history or other siblings, nor does it state any exclusions.

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

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

With readOnlyHint, idempotentHint, and destructiveHint already present, the description adds useful context: the result is an external portal link, it is account-scoped, and it exposes billing capabilities. It omits secondary details like link expiration or auth prerequisites, but those are not critical for a simple read-only link generator.

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

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

The description is a single concise sentence with no waste. The core object (customer portal link), the scope (this account's subscription), and the purpose (invoices, payment method, cancellation) are all stated economically.

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, read-only, no-output-schema tool, this description is complete: it states what is returned (a link) and what that link provides. Sibling tools and annotations cover the remaining routing and safety 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?

There are zero parameters and the schema fully reflects that, so no parameter documentation is needed. The baseline for a parameterless tool applies, and the description appropriately avoids inventing parameter detail.

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

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

The description clearly identifies the delivered resource as a link to the payment provider's customer portal, scoped to the current account's subscription. It differentiates from siblings like cancel_subscription, where cancellation lives inside the portal rather than being performed by this tool, and from get_upgrade_link by the billing/financial focus.

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

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

The description gives clear context: this tool is for surfacing billing management (invoices, payment method, cancellation) rather than performing those actions. It does not explicitly name alternatives or exclusions, but the intended use is evident from 'where invoices, the payment method and cancellation live'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that the result is 'returned as a file', but says nothing about format, size, or whether a job_id with no prepared pack errors out.

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

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

A single front-loaded sentence with no filler; the resource and its origin are stated immediately and every clause earns its place.

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

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

With no output schema, the description should explain the return shape, and 'returned as a file' is only partial — it does not say whether that is a URL, bytes, or an attachment. For a two-parameter read tool with annotations, this is adequate but leaves a real gap.

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

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

Schema description coverage is 0%, so the description must carry the burden. It loosely maps both parameters ('for one job' implies job_id, 'CV or cover letter' implies the document enum) but omits the enum values, the cv default, and the required/optional distinction.

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

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

States a specific resource (the tailored CV or cover letter PDF) and names the producing tool, prepare_external_application, which separates it from get_my_cv_pdf and get_sent_cv_pdf. It stops short of explicitly contrasting those siblings, so it falls just short of a 5.

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

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

Usage is only implied via the reference to prepare_external_application, suggesting this fetches that tool's output. There is no explicit when-to-use, no when-not guidance, and no naming of the sibling PDF tools the agent might otherwise pick.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful method-level transparency by explaining that every number comes from re-asking the feed's own predicate with one control relaxed, which tells the agent this is a computation over current state, not a guess or a static report.

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

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

Two sentences carry the entire meaning with no redundancy. The first sentence fronts the results the agent can expect, and the second explains the methodology. Every word earns its place.

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

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

For a zero-parameter, read-only analytic tool, the description is complete: it lists the returned insights, explains how they are derived, and is supported by annotations confirming safety. No output schema exists, but the description sufficiently characterizes the result payload for an agent to invoke and interpret the tool.

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

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

The tool has zero parameters, so the baseline is 4. The description needs to add no parameter-level meaning, and the input schema fully documents the empty parameter set. The description instead usefully explains what the output represents.

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 analytical purpose: count jobs shown by current targeting, count how many each rule hides, and identify the single change that would widen the feed most. This clearly distinguishes it from sibling tools like get_targeting, which would return targeting settings, and list_matching_jobs, which would return the jobs themselves.

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

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

The description makes the use case clear: you call this when you want to understand what current targeting costs in feed reach and what one change would improve it. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5, but the context is strong enough to route an agent correctly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds content-level context by naming the three settings returned, but does not describe the response shape or format for a tool that has no output schema.

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

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

It is a single sentence, so it is short, but it is a grammatically awkward run-on with a parenthetical aside inserted mid-clause, which makes the three returned items harder to parse at a glance. The most important item (the address) is at least front-loaded.

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 read tool with no output schema, the description conveys what information comes back but not how it is structured or returned. It is adequate but leaves the return shape to inference when there is no output schema to fall back on.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is 100% and no arguments exist to document.

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

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

It names a specific resource (the Keywordise application email address) and enumerates the three pieces of configuration it returns: the address, forwarding status, and whether email applying is active. This is distinguishable from generic siblings like get_account or get_my_profile, though the noun-phrase phrasing never uses a clear retrieval verb.

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

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

There is no when-to-use guidance, no mention of when-not to use it, and no reference to any sibling as an alternative. An agent must infer from the resource name alone that this is the tool for inspecting the application-email configuration.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the operational safety is covered. The description adds value by disclosing the response contents (full description, summary, highlights, link), which is particularly useful given there is no output schema.

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

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

One clean sentence that front-loads the core purpose and lists the included elements. No filler, repetition, or ambiguity.

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

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

For a simple read-one operation with a single required parameter, rich safety annotations, and a description that enumerates the returned fields, the definition is complete. The source of job_id is provided in the schema, so an agent has everything needed to call it correctly.

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

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

The single parameter job_id is fully documented in the schema with a helpful provenance note ('A job_id from list_matching_jobs or list_my_applications'). Schema coverage is 100%, so the description does not need to add parameter semantics; it correctly stays silent.

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 title 'Read one job posting' and description 'The full description of one matched vacancy' clearly identify a read operation for a single job posting. It is distinguishable from list_matching_jobs (which lists jobs) and explain_job_match (which explains matches), though sibling differentiation is not explicit.

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

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

Usage is implied through the parameter description, which states the job_id must come from list_matching_jobs or list_my_applications. However, the description does not explicitly state when to use this tool rather than alternatives like explain_job_match or get_match_status, nor does it mention exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by enumerating the returned content, which matters since there is no output schema. It stops short of noting what happens for a stale or missing pool_job_id.

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

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

Two tight sentences with zero filler; the payload description is front-loaded and the routing hint follows. Every clause earns its place.

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

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

With no output schema, the description compensates by listing the returned fields, and the single required parameter is fully covered. Only the failure mode for an unknown pool_job_id is unaddressed, a minor gap for a read-only lookup.

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

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

Schema coverage is 100% and the single parameter is already documented as coming from search_live_jobs. The description repeats that provenance rather than adding format or validity 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?

States a specific verb+resource ('full posting text of one live job') and enumerates exactly what comes back (title, employer, place, date, description). It explicitly distinguishes itself from the sibling get_job_posting by routing own-matches lookups elsewhere.

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

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

Names the alternative tool (get_job_posting) and the condition that selects it ('a job in the person's own matches'), plus ties the required id back to search_live_jobs. The when-to-use-this-vs-sibling decision is fully specified.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is disclosing the four return metrics and the fact that the numbers mirror the keywordise.com homepage measurement. That is meaningful return-shape context, particularly since there is no output schema, though nothing is said about freshness beyond the 30-day window or rate considerations.

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

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

The first sentence is well front-loaded and earns its place. The second sentence, however, is a long clause-chained run-on ('...how many of them Keywordise applies to start to finish without the person doing anything') that is harder to parse than the payload warrants.

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

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

With no parameters, no output schema, and simple read annotations, the description supplies the missing piece - what the returned counts actually are. It is largely complete for an agent deciding whether to call this before quoting a number, though the enumerated metrics could be presented more crisply.

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 a no-param tool applies. The description correctly does not invent parameter behavior.

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 exactly what the tool returns: aggregate counts of the live job pool (total live jobs, last-30-day finds, employer count, auto-applyable count). This clearly separates it from sibling list/search tools like search_live_jobs and list_matching_jobs, which return job entities rather than counts.

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 names the trigger scenario ('how many jobs are there', 'before quoting a number'), which tells the agent when to call it. It stops short of naming a when-not condition or pointing to an alternative tool for counts vs. listings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: it is only for already-running operations, it reports feed build states (queued, building, ready, failed), and it clarifies when the feed is final. There is 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?

The description is compact but information-dense. Every sentence earns its place: the first scopes the tool and names alternatives, the second details return fields and the completion condition. It is front-loaded and not 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?

For a zero-parameter read-only status tool with no output schema, this description is complete: it states what is returned, when to poll, the state values, the finality condition, and the relevant sibling alternative. No critical context is missing for an agent to call it correctly.

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

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

The tool has zero parameters, so there is no parameter burden for the description to carry. Schema coverage is effectively 100%, and the description appropriately avoids adding irrelevant parameter details.

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

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

The description opens with a specific verb and resource: 'Only for checking on a match or feed rebuild that is already running.' It clearly states what the tool returns—live run status, feed counts, and feed_build state—and distinguishes itself from list_matching_jobs.

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

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

The description gives explicit context for when to use the tool: after upload_cv, update_targeting, or refresh_matches. It also names the alternative list_matching_jobs for finding or showing jobs, and explains the polling condition until feed_build.feed_state.state is ready.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds useful behavior beyond annotations: the result is returned as a file and no model call is made. No contradiction with annotations is present.

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 entire description is one efficient sentence that front-loads the primary purpose and adds only relevant differentiating details. Every clause contributes: untailored base CV, PDF rendering, file return, and no model call. There is no redundancy or filler.

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

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

For a simple read-only tool with one optional parameter, the description is complete: it specifies the resource, output format, file return behavior, and model-call behavior. The absence of an output schema is not a gap because the returned artifact is described as a file.

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 'design' parameter is already documented with its default behavior. The description only references 'the chosen design' without adding new parameter meaning. Baseline 3 is appropriate because the schema handles 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 resource, 'the account's base CV', and a clear action, 'rendered as a PDF ... returned as a file.' The parenthetical '(the saved profile, untailored)' distinguishes this from tailored CV variants like get_sent_cv_pdf or preview_tailored_cv. There is no ambiguity about what the tool does.

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

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

The description gives clear context: use this when you need the saved, untailored base CV as a PDF, and the 'No model call' note signals a low-cost retrieval. It does not explicitly name sibling tools or exclusion conditions, so it falls just short of fully explicit usage guidance.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable context by enumerating exactly what data the profile holds: contact info, skills, roles, education, targeting rules, and plan status. This goes beyond the annotations and helps set expectations for the response content.

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

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

Three sentences, each earning its place: the trigger condition, the exclusion context, and the content breakdown. It is front-loaded and efficient, though the phrase 'The CV profile Keywordise holds for this account' is slightly awkward and could be clearer.

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 read-only tool, the description covers purpose, contents, and usage boundaries well. There is no output schema, so the description's enumeration of returned data partially compensates, though it stops short of describing the exact response structure or field formats.

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 and schema coverage is 100%, so there is no parameter documentation burden. The description appropriately focuses on what the tool returns rather than inputs, which is the only meaningful semantic contribution possible here.

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

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

The description clearly states the tool returns the user's profile/CV data, targeting rules, and plan status. It distinguishes itself from search/apply tools by noting they read the saved CV themselves, though it does not explicitly differentiate from sibling tools like get_targeting or get_account.

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

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

Provides explicit when-to-use guidance ('Use when the person asks what is on their profile or CV'), an explicit exclusion ('Not needed before searching or applying'), and a call to action ('Call this first'). This leaves little ambiguity for an agent deciding whether to invoke it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond that: what kinds of gaps are detected and that each gap is accompanied by a severity, which helps the agent interpret the response. No contradictions or hidden side effects.

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

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

A single, front-loaded sentence covers what the tool does, gives concrete examples, mentions the severity output, and names the natural next action. Every phrase earns its place with no filler.

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

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

For a read-only, zero-input tool, the description is complete: it states what is returned (gaps with severity), why the gaps matter, and how to act on them via update_profile. No parameter schema or output schema is needed to invoke it correctly.

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

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

There are zero parameters and schema description coverage is 100%, so the description need not explain parameter meanings. Its examples align with a no-input analysis tool, and the baseline for zero-parameter tools is appropriately met.

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

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

The description names a specific verb and resource ('gaps in the saved profile') and clarifies the purpose: gaps that weaken applications. Concrete examples (missing dates, no contact phone, empty summary) make the tool's scope unmistakable and distinguish it from getting the full profile (get_my_profile).

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

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

The description clearly signals when this tool is relevant — when you need to identify profile weaknesses — and explicitly points to update_profile as the follow-up fix. It does not list exclusions or contrast with alternative read tools, so it is strong but not maximally explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds real behavioral value by enumerating the returned fields and handling the edge case that a closed job reports itself as closed. It stops short of noting auth requirements or error behavior for an invalid id.

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

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

Four short sentences, front-loaded with the trigger condition, followed by return contents, edge case and next step. Only mild redundancy with the schema on the id format; 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?

For a one-parameter read tool with rich annotations and no output schema, the description supplies the trigger, the returned fields and the closed-job edge case. An agent has what it needs to call it correctly; only failure modes for a malformed id are unaddressed.

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

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

Schema description coverage is 100% and the single parameter already documents the ten-character format and the keywordise.com/jobs derivation. The description restates the same format and link form rather than adding new syntax or validation detail, 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 (read a public job) plus the exact identifier form it consumes, so the agent can distinguish it from the many other job-related siblings. It also names the follow-up tool, apply_to_public_job, anchoring the tool in a workflow.

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 trigger is explicit and concrete: use when the person gives a ten-character Keywordise job id or a keywordise.com/jobs link, with a worked example. It routes forward to apply_to_public_job, but never says when NOT to use it (e.g. versus get_live_job or get_job_posting for non-public jobs).

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real behavioral value by enumerating the returned content (code, link, share/discount, stats breakdown, recent commissions and payouts, referrer status), which matters since no output schema exists.

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 usage triggers, then lists returned data in one dense but purposeful sentence; two sentences with no filler. The parenthetical stat list is heavy but each item is informative, so it stops short of a 5.

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

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

For a no-argument, read-only, closed-world tool with annotations covering safety and no output schema, the description exhaustively describes the returned fields so the agent knows what to expect. Nothing needed to invoke or interpret the 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?

The tool takes zero parameters, so there is no parameter surface to document; the baseline for a no-arg tool is 4. Nothing in the description could add parameter meaning.

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 (retrieve) and resource (referral code, link, earnings, stats, commissions, payouts, referrer) so an agent knows exactly what comes back. The example query 'what is my referral code' implicitly separates this read from the write siblings set_referral_code and claim_referral_code, though it never names them explicitly.

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

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

Opens with 'Use for ...' and three concrete user phrasings, giving clear when-to-use context. No when-not guidance or explicit alternative routing (e.g. pointing to set_referral_code for changes), which keeps it 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 establish that the operation is read-only, idempotent, and non-destructive. The description adds behavioral value by stating that the result is returned as a file rather than structured data, and that it is the exact artifact sent to the employer.

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

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

A single, efficient sentence conveys the resource, scope, and output format without redundancy. The title reinforces the key distinguishing idea: the exact CV that was sent.

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

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

For a one-parameter, read-only retrieval tool, the description adequately covers the input, scope, and output type. It does not mention edge cases like an application with no sent CV, but the tool's simplicity and annotations make the definition sufficient.

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

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

Schema coverage is 0% and the description only loosely connects application_id to 'one application.' It does not explain the expected ID format, where to obtain it, or behavior for invalid or missing applications.

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

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

The description clearly identifies the resource: the exact tailored CV PDF that was sent to an employer for one application, returned as a file. It distinguishes itself from siblings like preview_tailored_cv and upload_cv by emphasizing the sent, employer-bound 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?

The description scopes the tool to 'one application,' implying it should be used when the exact sent CV for a specific application is needed. However, it does not explicitly name alternatives or state when not to use it, such as when a preview is sufficient.

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 convey read-only, idempotent, non-destructive behavior. The description adds useful context about what the targeting rules govern (feed and apply runs), but it does not disclose return format, ordering, or how the settings are presented. This is a reasonable midpoint given annotation coverage.

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

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

The description is a single dense, comma-separated enumeration of many settings. It is information-packed and front-loads the key phrase 'Every targeting rule the feed and the apply run obey', but the long list is harder to scan than a structured or summarized version.

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 parameterless read-only getter, the description covers the substance of what will be returned: all targeting rule categories. Annotations cover the safety model, and there is no output schema or parameter complexity requiring further explanation. The main gap is that it never explicitly states it returns the current saved configuration.

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 and 100% schema coverage, so the description cannot meaningfully add parameter-level detail. The no-parameter baseline is 4, and the description appropriately focuses on clarifying the scope of the returned resource instead.

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 identifies the resource as 'every targeting rule the feed and the apply run obey' and enumerates concrete categories (geo, keywords, seniority, salary, etc.), which clearly distinguishes it from sibling update_targeting. However, it lacks an explicit retrieval verb like 'returns' or 'gets', so it leans on the tool name for the actual action.

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

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

The description gives no guidance on when to use this tool versus alternatives. It implies read access to current targeting settings but never states 'use this to inspect current targeting before changing anything' or names update_targeting as the write counterpart. Prerequisites and use cases are absent.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful return-structure context: the board is grouped by user-set stages and includes notes, which is meaningful beyond the annotations and helps the agent anticipate the output shape.

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

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

A single sentence efficiently captures the core concept, front-loads the resource name, and enumerates the grouping stages without wasted phrasing. Every part earns its place.

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

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

For a zero-parameter, read-only tool with rich annotations, the description is complete. It names the output concept (applications grouped by stage with notes), and no parameter details, return schemas, or prerequisites are missing for a correct invocation.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. Baseline 4 is appropriate because the parameter surface is empty and no undocumented inputs exist.

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

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

The description clearly defines the resource as a tracker board of applications grouped by stage (saved, applied, interview, offer, rejected) with notes. It distinguishes the content from similar application-related tools, though it lacks an explicit verb like 'get' or 'retrieve' and does not name sibling tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_my_applications, move_tracker_card, or set_tracker_note. It simply describes what the tracker board contains, leaving usage context entirely 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 declare the mutation-ish flags (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds genuinely new behavioral context: the upgrade is asynchronous and external, completed only once the payment lands in the browser — a side effect an agent cannot infer from the flags.

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

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

Two sentences, no filler, with the core deliverable front-loaded. The pricing detail is slightly heavy for a link tool but directly supports plan selection.

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 does explain what the caller gets (a checkout link) and what happens after payment. For a single-optional-param tool this is nearly complete; only explicit alternative-tool routing is missing.

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

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

Schema description coverage is 0%, so the description carries the burden. It documents the two enum values with prices and quotas and, importantly, states that Pro is the default, which the bare enum does not convey.

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

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

The description names a specific resource (checkout link) for a specific purpose (upgrading to a paid plan) and enumerates the two plans with prices, so an agent knows exactly what it returns. It does not explicitly distinguish itself from the sibling get_billing_portal_link, leaving that routing to inference.

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

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

It explains how the link is used ('The person opens it in a browser to pay; the account upgrades automatically when the payment lands'), which implies the appropriate context, but there is no explicit when-to-use guidance or comparison against get_billing_portal_link / cancel_subscription.

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 state the operation is read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those annotations: it explicitly assures the agent that the actual key value is never returned ('Never the key itself') and clarifies that only active keys are included.

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 entire description is one focused, front-loaded sentence. It states the resource, scope, returned fields, and a critical privacy guarantee with zero wasted words.

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

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

For a zero-parameter read-only list operation, the description is complete: it identifies the resource, scope, and output fields, while annotations cover safety. No output schema exists, but the listed fields sufficiently describe the return value. Nothing essential 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?

The tool takes zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies here; there is nothing missing because no parameters exist.

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 uses a specific verb ('list') and resource ('API keys'), and specifies scope ('active', 'on this account') and the exact output fields (prefix, label, created, last used). This clearly distinguishes it from sibling tools like create_api_key and revoke_api_key.

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

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

The description clearly implies this is the tool for viewing active API keys, while sibling tools like create_api_key and revoke_api_key cover other lifecycle actions. It does not explicitly say 'use this when you need to view keys rather than create or revoke them,' but the distinction is obvious from the verb and resource.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description correctly aligns with them. It adds meaningful behavioral detail beyond annotations: results are grouped by application, limited to blocking/stalled questions, and include suggested answers derived from prior responses.

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

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

One dense sentence with no wasted words, front-loading the core purpose and ending with a clear actionable pointer to the sibling tool. Every clause contributes to selection or invocation.

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

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

For a simple read-only list tool with one self-documenting optional parameter, the description fully covers what the agent needs: what is listed, how it is organized, what each item contains, and what to do next. No output schema exists, but the return semantics are sufficiently described.

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%: the only parameter, limit, has a clear description plus default/min/max. The description adds no parameter-specific meaning, which is acceptable since the schema already handles 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 ('list') and resource ('blocking questions'), and clarifies these are employer questions, grouped by application, with suggested answers. It also names the answering sibling, distinguishing this read/list tool from actions like answer_screening_question.

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

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

The description makes the applicability clear: questions stalled until this account answers them, with a routing instruction to answer using answer_screening_question. It does not explicitly enumerate when-not conditions, but the context is enough to select this over siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'live pool actually has inventory' nuance, which explains that results reflect current inventory rather than a static list. No further behavioral details are disclosed, but that is acceptable given the annotations.

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

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

The description is a single, well-structured sentence that front-loads the resource name, return fields, and use case. Every word contributes to understanding the tool.

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

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

With zero parameters and no output schema, the description still tells the agent exactly what data will be returned and how to use it. Nothing else is needed for correct tool selection and invocation.

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

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

The tool has no parameters, so the schema already fully documents the expected input. The description does not need to add parameter guidance and does not create confusion about any inputs.

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

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

The description clearly identifies the tool's purpose: returning countries where the live pool has inventory, including the specific fields (ISO-2, name, job count). It also connects this to the update_targeting workflow, which distinguishes it from other list_* tools in 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?

The description states the intended use case explicitly: choosing geo_countries in update_targeting. It does not mention when not to use it, but because the tool takes no parameters and is uniquely about country inventory, little ambiguity remains.

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=true, idempotent=true, destructive=false. The description adds the useful detail that the result includes the account's current pick, but it does not disclose output shape, ordering, or any list-level behavior beyond that. 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?

The description is a single concise sentence with no filler. It is slightly awkward and does not front-load an explicit verb, but every phrase earns its place and it is appropriately sized for a simple read-only listing tool.

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

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

For a zero-parameter, read-ony, idempotent listing tool with siblings in the same domain, the description is nearly complete: it states what is listed and that the current account pick is included. It does not enumerate output fields, but the absence of an output schema and the simplicity of the operation make this acceptable.

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

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

There are no parameters, so schema coverage is effectively 100% and there is no parameter ambiguity. The description's mention of 'current pick' clarifies what the empty-input call returns, satisfying the baseline for a zero-parameter tool.

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 identifies the resource ('CV designs a tailored CV can be rendered in') and adds the account's current pick, which separates this from simply listing templates. The purpose is clear, though the description relies on the tool name for the 'list' verb and does not explicitly compare itself with set_cv_design.

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

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

No guidance is given about when to choose this tool over siblings like set_cv_design or preview_tailored_cv. The description provides no when-to-use or when-not-to-use guidance, so an agent must infer the intended context from the tool name and sibling set.

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

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

Annotations already declare this a safe, idempotent read, so the extra credit comes from the description disclosing the domain model (multiple CVs per person, one default used by matches and applications) and the derived cv_state field including why no usable CV exists. No output schema exists, so this return-shape information is genuinely additive.

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 usage cue, then a compact explanation of the returned data. The parenthetical gloss on default CVs is a touch dense but each clause carries information an agent needs to interpret the response.

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 read tool with no output schema, the description covers both when to call it and what comes back, including the conditional cv_state semantics. Only minor gaps remain, such as ordering or what an empty list means.

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 and the baseline of 4 applies. It correctly does not waste space restating an empty 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?

Specific verb+resource (list the CVs on the account), scoped to a set of CV profiles rather than a single file. It distinguishes itself from siblings like get_my_cv_pdf and upload_cv by framing the tool as a roster view with labels and a state summary.

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 explicit triggering user phrasings ('which CVs do I have', 'is my CV uploaded'), which maps cleanly to the right node in the sibling tree. It stops short of naming the adjacent alternatives (upload_cv, get_my_cv_pdf) or stating exclusions, so it is clear context rather than a full when/when-not rule.

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

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

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds useful behavioral context: it returns unanswered facts for the current account and ranks them by unblocking impact. 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?

One sentence carries the resource, the scope, the ranking logic, examples, and the intended follow-up action. Nothing is wasted, and the key information is front-loaded.

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 zero parameters, rich annotations, and no output schema, the description is largely complete: it tells the agent what is listed, for which account, in what order, and what to do next. A small gap is that it does not describe the exact output shape needed for save_answer, but the guidance to 'Answer them with save_answer' implies interoperability.

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 and schema coverage is 100%, so the description does not need to explain parameters. The baseline of 4 for zero-parameter tools applies here.

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

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

The description states a specific resource ('universal screening facts this account has not answered yet'), a clear verb ('list'), and an ordering principle ('ranked by how many waiting applications each one unblocks'). It also clarifies the relation to the follow-up tool save_answer, so an agent can identify what this tool does.

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

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

The description implies when to use the tool: when the agent needs to find which unanswered screening facts would unblock waiting applications. It also names the natural next step ('Answer them with save_answer'), but it does not explicitly contrast with siblings like list_blocking_questions or get_profile_gaps.

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. The description adds meaningful behavior context beyond annotations: it discloses the data scope ('this account hid or disliked') and the ordering ('newest first'), and hints at the restore workflow. It does not contradict any annotation.

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

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

The description is a single concise sentence that front-loads the core resource and scope before adding ordering and purpose. Every word contributes to understanding, and there is no filler or repetition of the title.

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, read-only, idempotent list operation, the description is complete. An agent knows exactly what will be returned (hidden/disliked jobs), the order, and the motivating use case. The sibling unhide_job covers the restoration action, so no additional context 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?

This tool has zero parameters, so the description has no parameter burden. The baseline of 4 applies. The description does not need to explain parameter semantics because there are none to explain.

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

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

The description clearly identifies a specific resource — jobs this account hid or disliked — and specifies ordering (newest first). It also conveys the purpose of the operation, enabling a job to be put back, which distinguishes it from sibling tools like unhide_job and list_matching_jobs. The verb 'list' is carried by the tool name, and the description adds scoping detail beyond the title.

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

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

The phrase 'so one can be put back' clearly indicates the intended use case: reviewing hidden/disliked jobs in order to restore one. This implicitly routes an agent away from list_matching_jobs and toward unhide_job as the companion action. It does not explicitly state when not to use it, but with zero parameters and a clear purpose, the guidance is sufficient.

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, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: one thread per application, sort order (newest first), and that results and unread counts are included. It does not discuss pagination limits or result caps, which is a minor 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?

Two tight sentences with no filler, and the trigger phrases are front-loaded. The resource description follows immediately; only a slight ordering awkwardness (purpose stated after the usage cue) keeps it from a 5.

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

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

With no output schema, the description usefully summarizes what each thread contains and the ordering. Safety is covered by annotations. What an agent still cannot learn is how limit and unread_only shape the response, which is the one real omission.

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

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

Schema description coverage is 0% for two non-obvious parameters (limit, unread_only), so the description carries the burden. It never explains that limit caps the number of threads returned or that unread_only filters to unread threads; the mention of 'unread count' refers to a returned field, not the filter, so it does not compensate.

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?

Names the specific resource (the person's Inbox) and characterizes it precisely: one thread per application, containing employer results such as interview invitations and rejections, with unread counts, newest first. It also names the sibling read_inbox_message, so an agent can distinguish listing threads from reading one.

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

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

Gives explicit trigger phrases ('any replies?', 'did anyone get back to me?') for when to use it and explicitly routes to read_inbox_message for reading a single thread, so the choice between the two siblings is unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: ordering ('jobs that apply automatically come first'), the default scoping (fresh='new' means last two weeks, match default excludes weak matches), and the per-job payload contents. This is genuinely useful information an agent cannot derive from 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-loads the when-to-use triggers before the behavioral detail, which is the right order. The middle sentence listing what each job carries is somewhat run-on, but every clause carries information rather than filler.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (match percentage, recruiter-pass verdict, auto-apply status, awaiting-answer flag, already-applied flag) plus ordering and default filtering. For a 7-parameter, 0-required list tool, nothing essential 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 71% and four parameters have enums, so the schema already documents sort, fresh, match, applied, and auto_only. The description only restates the filter axes ('match tier, freshness and applies-automatically; page with offset') without adding syntax or edge-case 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?

States a specific verb and resource ('live vacancies matched to this account's CV, ranked') with the scope (uses the saved CV, no profile read needed). It is clearly distinguishable from siblings like refresh_matches, explain_job_match, and list_hidden_jobs, which all concern match data but do different things.

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

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

Gives concrete user-utterance triggers ('find me jobs', 'my top matches', 'remote marketing jobs that fit my resume') and explicitly removes a prerequisite ('no need to read the profile first'). It does not, however, name alternatives such as explain_job_match for drilling into a single match or refresh_matches for updating the list.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is known to be safe. The description adds transparency by enumerating exactly what data is returned (company, title, stage, outcome, when sent, number of pending screening questions, employer acknowledgement). This goes beyond the schema and gives the agent a clear picture of the response, though it doesn't discuss pagination or other edge behaviors.

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

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

The description is compact and front-loaded with usage triggers ('what did I apply to'), followed by a specific list of returned fields. Every sentence earns its place, with no filler or redundancy.

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 there is no output schema, the description does a good job enumerating the return fields. It covers the essential information an agent needs to understand what the tool returns. However, it does not mention how 'limit' or 'include_cover_letter' affect output, nor does it describe ordering or default behavior, leaving minor gaps in completeness.

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

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

Schema description coverage is only 33%, with only 'only_waiting_on_me' documented. The description does not mention 'limit' or 'include_cover_letter' at all, and provides no guidance on how these parameters affect results. With low schema coverage, the description should compensate, but it fails to do so, leaving the agent without semantic clarity for two of three params.

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 clear purpose: listing all applications sent for the account, with a specific resource (applications) and specific output fields (company, title, stage, outcome, etc.). It also gives example user queries that directly map to the tool, distinguishing it from siblings like get_tracker or explain_job_match.

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

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

The description provides explicit example use cases ('what did I apply to', 'any replies', 'status of my applications'), which clearly indicate when to use this tool. However, it does not explicitly mention when not to use it or name alternative siblings, so it lacks the 'when-not' component of a top score.

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 annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful behavioral context by disclosing the 'last five' limitation and that both match and application runs are included, along with counts and status.

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

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

The description is a single concise sentence that conveys the core information without fluff. It front-loads the main result and avoids repeating annotation-provided details.

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, read-only list operation with no output schema, the description sufficiently communicates what the agent will receive: the last five runs of each type with counts and status. It could be slightly more explicit about the return structure, but the absence of parameters makes this largely complete.

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

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

The tool has zero parameters, so there is no parameter burden for the description to carry. With no schema properties to document, the baseline is appropriately high and the description adds no unnecessary parameter details.

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

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

The description states exactly what the tool returns: the last five match runs and the last five application runs, including counts and status. It clearly distinguishes this from sibling tools that check a single run's status, such as get_match_status or get_apply_run_status.

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

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

The description and title imply this is for viewing recent run history, but it does not explicitly say when to use this tool instead of the status-focused siblings. There is no guidance about using get_match_status or get_apply_run_status for checking the status of a specific individual run.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructveHint, so safety is covered. The description adds useful account-scope context and the automatic-reuse behavior, but does not disclose output shape, ordering, or whether results are paginated. 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?

A single sentence carries the full description without repetition. The 'answer book' metaphor is immediately illustrative, and the automatic-reuse detail explains why the saved answers matter without adding fluff.

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, read-only list tool, the description is largely sufficient: it states the account scope and the purpose of the answers. Slight gaps are the lack of detail about the returned entry fields and pagination behavior, but these are minor given the tool's simplicity and the safety-related annotations.

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 and schema description coverage is 100%, so the description need not explain parameters. The phrase 'every screening answer' reinforces the unfiltered, account-wide scope, aligning with the empty input schema.

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

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

The description clearly identifies the resource: every screening answer this account has given or taught. The tool name and title reinforce the list operation, and the scope is account-specific, distinguishing it from sibling mutation tools like save_answer and delete_saved_answer.

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

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

The description gives helpful context about what the answer book is and how future applications reuse these answers, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Usage is implied from the list semantics rather than spelled out.

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

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

The description adds useful behavioral information beyond the annotations: the API key is shown only once, users must keep it, and up to five keys may be active per account. It does not describe what happens when the limit is reached, but the mention of revoke_api_key partially covers that 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?

The description is three short sentences with no filler. The core action is front-loaded, and each additional sentence provides essential operational context: one-time key visibility and the key limit with a revocation path.

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

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

For a simple authentication tool with no output schema, the description covers the main result (a new API key shown once) and important constraints (key limit, revocation). It could mention what happens on failure or at the limit, but the core knowledge needed to call the tool correctly is present.

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

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

Schema coverage is low (33%), with only label documented. The description helps by clarifying that email and password are the account's credentials and that they are exchanged for a new API key, but it adds little detail about password handling or the optional label. Some compensation is present, but not full.

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

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

The description clearly states the specific action: exchanging account credentials for a new API key, and names the purpose of allowing a terminal or assistant to act on the account. It is distinct from ambiguous siblings like create_api_key because it emphasizes email/password authentication, though it does not explicitly contrast itself with that sibling.

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

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

The description gives clear context for when to use the tool: when a terminal or assistant needs to act on the account, and it even warns about the five-key limit and points to revoke_api_key to free a slot. It lacks an explicit statement of when not to use it or how it differs from create_api_key, but the intended scenario is clear.

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?

While annotations already indicate this is a non-read-only operation, the description adds that it specifically modifies the tracker stage rather than other application data. It does not disclose side effects, reversibility, permissions, or response behavior, but the operation is simple.

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

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

A single sentence conveys the operation, resource, and valid values with no fluff. The key information is front-loaded.

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

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

For a simple two-parameter mutation, this description is adequate for basic invocation, especially with the stage enum in the schema. But it does not clarify whether the application must already exist, whether stages can be set in any order, or what happens after a successful 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?

With 0% schema description coverage, the description helps by contextualizing application_id as the target application and stage as one of five tracker stages. However, it mostly restates the enum from the schema and does not explain application_id format or any constraints.

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

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

The description clearly states the tool sets the tracker stage for one application and enumerates the exact allowed stages. This distinguishes it from siblings like get_tracker (read-only) and set_tracker_note (different resource).

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

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

The description implies the use case—updating an application's tracker stage—but gives no explicit guidance about when to prefer this over alternatives, nor any prerequisites such as the application already existing.

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

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

With annotations only covering the mutation safety profile, the description adds substantial behavior: it consumes no application credit, is a paid model call, is cached per job, and sends nothing to the employer. It also explains the output handling (returns cover letter text, PDFs via get_external_pack_pdf). This is well beyond what readOnlyHint/destructiveHint/idempotentHint convey.

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

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

Front-loaded with the condition that selects this tool, and every clause carries information (credit, cost, cache, output, no external send). It is somewhat dense with nested parentheticals, which slightly hurts readability but not content value.

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 describing the return value and how to get the PDFs. Combined with cost, caching, credit, and no-side-effect disclosure, an agent has everything needed to call this correctly and set user expectations.

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?

Only one parameter and schema coverage is 100%, so the schema already documents job_id and its provenance (list_matching_jobs or apply_to_public_job). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb pair (tailors the CV, writes the cover letter) and the exact resource (the external application pack for one job), and explicitly carves itself away from apply_to_public_job and start_apply_run. An agent can distinguish it from preview_tailored_cv and get_external_pack_pdf without opening any schema.

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

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

Gives the precise triggering condition — a job the app marks as applied on the employer's own site where apply_to_public_job/start_apply_run do not apply on the user's behalf — and names those alternatives. It also states 'on request', implying this is not automatic. Routing is unambiguous.

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

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

Annotations already mark it read-only, idempotent, and non-destructive, and the description adds valuable behavior beyond that: nothing is sent, it is a paid model call, it is limited to 20 per hour, and it shares the billing gate with applying. This meaningfully informs an agent's cost and side-effect expectations.

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

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

The description is compact and front-loaded with the triggering use cases, then the output composition, then key constraints. Every sentence earns its place and there is no redundant restating of the title or schema.

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, no-output-schema tool, the description is complete: it explains what the tool does, what the generated result contains, that it is preview-only, and the cost/rate-limit behavior. An agent has enough to select and invoke it correctly.

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

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

Schema covers job_id 100%, including its source, so the description does not need to add much. It reinforces that the parameter selects the one vacancy being tailored, but that is a minor addition rather than essential semantic clarification.

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: 'Rewrite this account's CV for one vacancy' with a clear list of output components. The 'preview only' framing and 'Nothing is sent' distinguish it from sending/apply tools like start_apply_run and get_sent_cv_pdf.

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 names user request phrasings that should trigger this tool: 'tailor my resume for this job' or 'what would you send for this one'. It gives clear context, though it does not explicitly name alternative tools or state when not to use it.

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

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

The description adds meaningful behavioral detail beyond annotations: hide or dislike removes the job from the feed and trains the matcher, interested is a positive signal, and the action can be undone via unhide_job. This gives the agent a clear picture of side effects and reversibility beyond the readOnly/destructive hints.

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

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

Two concise sentences cover the core action, behavioral consequences, and the undo path. It is front-loaded with the primary purpose and contains no filler or redundancy.

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

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

The description is complete enough for a simple feedback tool: it covers the action semantics, feed impact, matcher signal, and reversibility. The only notable gap is the undocumented reason parameter, but the tool is otherwise straightforward and no output schema adds complexity.

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

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

Schema description coverage is only 33%, so the description has to compensate for the action and reason parameters. It does explain the meaning of the action values (hide/dislike vs interested), which helps. However, it does not explain the optional reason parameter at all, leaving its purpose and formatting unclear.

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 identifies a specific operation (feedback on one job), defines what each action does, and names the related undo tool unhide_job. It clearly distinguishes this tool from siblings like list_hidden_jobs or unhide_job by describing the feedback mechanism rather than just restating the title.

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

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

The description states when to use the tool: when the user wants to give feedback on a single job, with hide/dislike for rejection and interested for positive signal. It also routes undo behavior to unhide_job. It does not explicitly list exclusions or alternatives beyond the undo case, but the context is clear enough for an agent to select it appropriately.

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 does add genuine behavioral context beyond the annotations by disclosing the side effect 'Reading marks the message as read' and by describing the returned payload. However, that stated state change directly conflicts with readOnlyHint=true (and sits awkwardly with idempotentHint=true), creating an inconsistency an agent could act on incorrectly if it trusts the structured hints.

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

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

Two tight sentences: the pay-off (what you receive) is front-loaded and the caveat (marks as read) follows. Every clause carries information, with no filler or restatement of the tool name.

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

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

For a one-parameter read tool with no output schema, the description covers what is returned and flags the read-state side effect, which is most of what an agent needs. It stops short on error/failure behavior for an invalid message_id and on the contradiction with its own read-only annotation.

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

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

Schema description coverage is 0% and the single required parameter (message_id) is never explained in the description. The '(from list_inbox)' parenthetical is the only clue about where the identifier comes from, which partially compensates but leaves format/validity expectations unstated.

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

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

The description names the specific resource ('one Inbox message') and enumerates exactly what the agent gets back: full text, the employer's reply thread, and any verification code or link. The parenthetical '(from list_inbox)' scopes it relative to the sibling that produces the message_id, so an agent can tell it apart from list_inbox and reply_to_inbox_message 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?

Usage is only implied: the '(from list_inbox)' note suggests the intended workflow of listing first, then opening a single message, but there is no explicit when-to-use statement, no exclusion, and no pointer to reply_to_inbox_message as the alternative when the goal is to respond rather than read.

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 reveals asynchronous background execution, conditionally idempotent/cheap behavior, the feed_build field on every answer, and the non-obvious warning that a feed still being built is not an empty feed. It does not contradict the annotations; it adds operational detail beyond the generic boolean hints.

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

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

Four sentences, each carrying distinct value: core behavior, conditional idempotence, parameter semantics, and required follow-up polling. It is front-loaded with the main operation and contains no filler or 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 background mutation with no output schema, the definition provides the essential operational contract: what runs, how force/rebuild change behavior, what to do after calling, and why waiting for ready matters. Nothing an agent needs to invoke it correctly is missing.

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

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

The input schema only provides two bare booleans with defaults and no descriptions, so the prose is the only explanation. It defines force vs full re-match and rebuild vs rebuild-from-scratch with a use case, compensating fully for the 0% schema coverage.

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

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

The first sentence states a specific action and object: matching the account's CV against vacancies added since the last look, in the background. This clearly differentiates it from sibling read-only tools like list_matching_jobs and get_match_status, and from the force/rebuild variants it goes on to define.

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 explicit conditions: use force=true for a full re-match, use rebuild=true when the feed looks wrong, and poll get_match_status until ready before calling list_matching_jobs. This gives an agent a clear call-and-poll workflow rather than leaving the decision 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?

With annotations already declaring destructiveHint=true and non-idempotent, the description adds useful context: it sends in the person's name, requires approval of the exact text, and enumerates failure cases (message not found, empty text). It does not state that the send is irreversible, though the destructive hint covers the safety profile.

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

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

Three tight sentences, front-loaded with the operation, then the approval precondition, then failure behavior. No filler.

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

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

For a two-parameter mutation with no output schema, the description covers purpose, precondition, and failure modes, and annotations cover reversibility and openness. Missing only param format detail and any mention of the side effect beyond sending.

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

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

Schema description coverage is 0%, so the description must compensate. It implies text must be non-empty ('text is empty' failure) and that message_id targets a single Inbox message, but gives no format for message_id or note the 20000-char limit on text. Partial compensation only.

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 (SENDS an email) and resource (reply to one Inbox message) and the scope ('as a reply to one Inbox message'), which cleanly separates it from siblings like list_inbox and read_inbox_message. An agent can identify the operation 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?

Explicitly gates use on 'the person's approval of the exact text', which is real when-to-use guidance. It does not name alternatives (e.g., read_inbox_message to obtain the message first), so it falls short of full routing guidance, but the precondition is clear.

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 signal a non-read-only, non-idempotent action. The description adds useful behavior: each call resends the link, and the only blocked operation until confirmation is applying. It does not mention rate limits or side effects, but the added context is sufficient for such a simple tool.

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

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

Two sentences with no wasted words. The first states the action, the second explains the relevant consequence. Information is front-loaded and directly supports tool selection and invocation.

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

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

For a zero-parameter tool with no output schema, the description is complete: it says what happens, to what target, and what effect it has on the user's workflow. An agent can call it correctly with no additional information.

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 there is nothing for the description to document. It still usefully identifies the implicit target as 'this account's address', which provides more semantic clarity than the empty schema.

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

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

States a specific verb and resource: 'Send the email-confirmation link again to this account's address.' It's not a tautology of the title and clearly identifies this as the tool that resends the verification email, distinguishing it from account-management siblings.

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

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

The description gives clear context: 'Applying is blocked until the address is confirmed; nothing else is.' This implies the tool is used when a user needs to unblock applying by resending verification, and no alternative sibling exists. It lacks explicit when-not-to-use guidance, but none is necessary here.

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

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

Annotations already mark this as destructive and non-read-only. The description adds valuable behavioral context beyond annotations: the effect is immediate, all users of the key stop working at once, and revoking the current key ends the session. This is exactly the kind of consequential behavior an agent needs to know.

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

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

Three short sentences with no filler. The most important information (immediate revocation, consequences, self-revocation warning) is front-loaded and every sentence earns its place.

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

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

For a one-parameter destructive tool with no output schema, this description is complete. It explains the action, the immediacy, the impact on users, and the special case of revoking the calling key. The parameter source is covered by the schema.

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

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

Schema coverage is 100% and the key_id parameter is documented as 'From list_api_keys.' The description adds no additional parameter semantics, but with full schema coverage, 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 ('Revoke') and resource ('API key'), and immediately clarifies scope ('this account's API keys'). The description distinguishes it from sibling tools like create_api_key and list_api_keys by clearly indicating this is the invalidation action.

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

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

The description clearly establishes when to use this tool: when an API key must be invalidated immediately. It also warns about the self-revocation case, which is a key usage caveat. It does not explicitly name alternatives, but the intended context is clear enough for a simple destructive operation.

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 behavioral traits beyond the annotations: replace/overwrite semantics, the background side effect of completing and sending waiting applications, and a fidelity constraint ('Only save what the person actually stated'). These add significant context beyond the all-false hints.

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

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

Three focused sentences with no redundancy. The core action and example are front-loaded, the side effect earns its sentence, and the constraint earns its sentence.

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

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

The description covers the main action, side effects, and a correctness constraint, but omits guidance on how to fill optional parameters like kind and options, and does not mention return behavior. With all-false annotations and no output schema, an agent must infer nontrivial parameter usage.

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

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

Schema description coverage is only 25%, so the description must compensate for undocumented parameters, but it only illustrates question and answer. The kind enum and options array semantics are left entirely to inference, making correct invocation for select/number/boolean cases uncertain.

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 ('Add or replace') and resource ('screening answer in the answer book'), with an illustrative mapping from question to answer. It is clearly distinguishable from sibling tools like list_saved_answers and delete_saved_answer.

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

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

The description implies usage by explaining the answer book concept and the background effect on waiting applications, but it never explicitly says when to prefer this tool over related alternatives like answer_screening_question. There are no exclusions or alternative-route hints.

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/no-destructive, so safety is covered; the description goes well beyond by disclosing scope (~2M jobs, no CV required), matching semantics (all words must appear in title/employer/description), ordering (newest first), and the pool_job_id vs public_id distinction that governs downstream apply behavior.

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

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

Front-loads real user queries before mechanics, and nearly every clause carries information. The text is dense and somewhat run-on, mixing usage, filters, ID semantics and apply routing in one block without clear separation.

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 6-param open-world search with no output schema, it covers input semantics, result ordering and key return fields (pool_job_id, public_id). The gap is pagination/total-count behavior, which matters given the offset parameter and a two-million-job pool.

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

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

With schema coverage at 33%, the description compensates by explaining query matching semantics, remote-only filtering, two-letter country codes, and the posted_within_days window. It does not address limit or offset, so pagination behavior on a 6-param search remains unstated.

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

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

Names a specific verb and resource ('Searches the WHOLE live job pool') and immediately distinguishes itself from the CV-based sibling by stating it needs no CV and covers the whole pool, not just matches. The concrete example queries ('find remote data engineer jobs') make the purpose unmistakable.

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

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

Explicitly routes the agent: use this for keyword-based discovery, but 'For jobs ranked against this person's CV use list_matching_jobs instead.' It also names the downstream tools (apply_to_public_job / apply_to_live_job) and which identifier each expects, so the whole flow is inferable.

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 indicate this is a mutating but non-destructive action. The description adds the important behavioral detail that the setting applies to every tailored CV, making the global scope explicit. 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?

A single sentence with no filler. The action, resource, scope, and parameter source are all front-loaded and every word earns its place.

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

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

For a one-parameter mutating tool, the description covers the target resource, global effect, and valid parameter source. It could mention invalid-key behavior or immediate vs. future effect, but these are minor gaps.

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

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

The schema only provides a string with maxLength 40 and no description. The description compensates by defining the 'design' parameter semantically as a key from list_cv_designs, giving the agent a concrete way to find a valid value.

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: 'Set the design every tailored CV is rendered in.' It also clarifies that the accepted value is a key from list_cv_designs, which distinguishes it from the sibling list_cv_designs tool.

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

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

Clearly establishes the tool as the way to change the global CV design and tells the agent to obtain valid values from list_cv_designs. It does not spell out exclusions, but there is no competing sibling setter, so the guidance is sufficient.

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 the safety profile (not read-only, not destructive, not idempotent), so the bar is lower, and the description still adds real behavioral context: the accepted character set and the fact that failures surface as 'the app's own sentence' when a code is taken or disallowed. It omits auth/permission requirements, which keeps it from a 5.

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

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

Two tight sentences that front-load the action and follow with format and failure behavior; nothing is padded. The phrasing 'the app's own sentence' is slightly opaque but compact.

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

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

For a one-parameter mutation with annotations and no output schema, the description covers purpose, accepted input format, and error behavior adequately. Only auth/prerequisite context 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 0% for the single 'code' parameter, so the description must compensate, and it does by specifying the allowed character set (letters, digits, dashes) that the schema's minLength/maxLength constraints do not convey. It does not cover case sensitivity or leading-character rules, so it is not exhaustive.

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 ('Set or change the person's own referral code') and clarifies scope with 'own', which implicitly separates it from the sibling claim_referral_code. It stops short of naming that sibling, so the differentiation relies on inference.

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

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

The word 'own' implies this is for setting your personal code rather than claiming someone else's, which is the key distinction from claim_referral_code, but no alternative is named and no when/when-not conditions are stated explicitly. Usage is implied rather than guided.

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 explicitly discloses replacement semantics, which is the key behavioral trait, and scopes the operation to the person's own note. Annotations are consistent with a write operation, and the destructive aspect of overwriting is surfaced by the word 'Replace'.

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

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

One front-loaded sentence with no filler; the parenthetical adds useful examples without bloating. Every element 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?

The definition covers the action, target, and content scope, but leaves open behavior when no note exists, return or success signaling, and any prerequisites or error conditions. With no output schema and non-informative annotations, these gaps keep it from being fully self-sufficient.

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

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

With schema description coverage at 0%, the description carries the parameter meaning: 'note' maps to notes, and 'tracked application' maps to application_id. The parenthetical examples clarify the expected note content, though application_id's source or format is not detailed.

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 ('Replace'), a clear resource ('the person's own note on one tracked application'), and gives examples of note content. This distinguishes it from tracker siblings like get_tracker and move_tracker_card.

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

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

The description implies the write-on-tracker use case but never explicitly says when to choose it over alternatives or when not to use it. There are no exclusions or conditional guidance, so an agent must infer fit from the action name and context.

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

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

Annotations already mark destructiveHint=true, but the description adds critical behavioral details: real applications leave in the person's name, require a confirmed email and active plan, consume plan quota, and actually submit inside the employer's system. It also discloses the dry_run safety valve and the 'never one already applied to' guard.

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?

Though long, every sentence earns its place. It front-loads usage triggers, then flows through prerequisites, process, side effects, and follow-up. No fluff or redundancy; the density is justified by the action's complexity.

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?

Without an output schema, the description fully explains the action's scope, prerequisites, side effects, and next step (poll get_apply_run_status). It also covers edge cases like single-job scoping and dry-run. An agent has everything needed 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?

Schema coverage is only 60%, so the description compensates heavily. It explains job_id semantics (ignores other filters), dry_run (everything except submit), and limit (up to N matching jobs, best fit first). It also ties fresh/match to the account's saved filters.

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

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

The description states a specific action (start an application run), the resource (matching jobs), and the outcome (tailored CVs, cover letters, screening answers, submissions). It clearly distinguishes itself from siblings like list_matching_jobs (listing) and get_apply_run_status (polling), and explains the job_id scoping for single-job applications.

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

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

The description explicitly lists trigger phrases ('apply for me', 'apply to the best matches', 'apply to this job'), mandates showing jobs first, and instructs to poll get_apply_run_status afterwards. It contrasts with list_matching_jobs by referencing the same filters and clarifies when to use job_id vs. batch mode.

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 annotations are all false, so the description carries the behavioral burden. It adds important context: the stop is requested after the current job, nothing is left half-done, and already-sent applications remain sent. It could also disclose what happens if no run is active or whether the run can later be resumed, but the provided transparency is solid.

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

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

Three short sentences with no filler. The trigger phrases and core semantics are front-loaded, and the consequences are stated in a compact final sentence.

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