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?

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?

Discloses major side effects beyond annotations: it authorises Keywordise to apply for jobs on the user's behalf, sends a confirmation email, gates applying on address verification, and sets a trial quota (7 days/27 applications, then $49/month). Annotations are all false and convey none of this, so the description carries the behavioral burden well.

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

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

Four tight sentences, with the core purpose in the first sentence and supporting prerequisites/effects in the rest. There is no redundant filler or repetition of schema fields.

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?

Covers what the tool does, the key precondition, the post-conditions (API key, confirmation email, activation rule), and cost/quota. Since there is no output schema, the return value (an API key) is explicitly mentioned, making this complete enough to call 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 schema has zero parameter descriptions, but the description compensates by explaining accept_terms in depth: what true means legally and the job-application authorisation it grants. Email and password semantics remain self-evident from their types/constraints, so the critical non-obvious parameter is covered.

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 exactly what it does: 'Register a new Keywordise account from the terminal and receive an API key for it.' The verb+resource is specific and the 'new' framing differentiates it from sibling operations like login or create_api_key, even without naming them.

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 frames when to use it: to register a brand-new account, including the terminal context and the accept_terms prerequisite. It does not explicitly point to login or create_api_key as alternatives for existing users, so when-not guidance is 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 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?

Annotations declare readOnlyHint=false, and the description correctly says apply=true saves and re-matches the feed, so mutating behavior is disclosed. It also mentions the non-apply path returns inferred rules and chips for confirmation. With no openWorldHint/idempotentHint help, these details add meaningful behavioral context. A slightly higher score is constrained by not describing what happens to the saved CV or whether it is used automatically.

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 packs a lot of information into a compact, front-loaded structure. The first sentence states purpose; the second describes outputs and mutation behavior; the third enumerates preset options. No unnecessary words or repeated schema 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 tool with 3 simple parameters and no output schema, the description provides enough to call it correctly: input format, preset options, apply behavior, and what the response contains. Missing is a caveat about maxLength or what happens with an empty/ambiguous sentence, but that is minor and inferable. The sibling landscape is large, and the description still makes this tool identifiable.

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 a concrete example, explains preset via its enum values, and explains apply via its behavioral effect. That covers all three parameters meaningfully, which is strong for a description that is only two sentences long.

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's purpose: turning a plain sentence plus the saved CV into concrete targeting rules. It also distinguishes itself from siblings like update_targeting by focusing on natural-language parsing rather than direct targeting edits. The verb 'turn' with the resource ('concrete targeting rules') is specific, and the example sentence makes the input format immediately understandable.

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 when to use it: when a user expresses targeting preferences in a plain sentence and wants them converted into structured rules. It does not explicitly name alternatives like update_targeting, but the distinction is implicit through 'plain sentence' vs direct editing. The apply=true mention clarifies the save-versus-preview behavior, which is useful 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?

The description discloses that narrative=true triggers a paid model call with a 60-per-hour limit, which is a real behavioral consequence not available in annotations. Combined with readOnlyHint, idempotentHint, and destructiveHint, the agent understands this is a safe but potentially costly operation.

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 well-structured sentence front-loads the scope and packs only essential details. The parenthetical about the paid model call and rate limit is high-value information stated without waste.

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

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

For a two-parameter read-only tool with no output schema, the description enumerates all returned components: match percentage, covered requirements, missing requirements, and optional narrative assessment. No essential calling information 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?

narrative has no schema description, but the tool description fully explains its meaning, when to enable it, and its cost/quota. The other parameter, job_id, is already well-described in the 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?

States the tool analyzes one vacancy and returns match percentage plus covered and missing requirements, optionally adding a written assessment. This clearly distinguishes it from sibling tools by its per-vacancy focus and explicit output elements.

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 opening 'For one vacancy' gives clear context for when to use the tool, and the schema links job_id to list_matching_jobs or list_my_applications. It does not explicitly name alternatives or exclusions, but the usage context is otherwise 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 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 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 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, 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 this as read-only, idempotent, and non-destructive. The description adds value by indicating that the status is 'live', that it reports on the 'latest' run, and that it includes elapsed time and feed counts, providing useful behavioral context beyond the annotations.

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

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

The description is a single, information-dense sentence that front-loads the output and then adds the usage context. No wasted words; every part contributes to understanding what the tool does.

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 polling tool, the description covers what status is reported, which fields are included, and when to poll. Combined with the safety annotations, an agent has enough context to select and invoke this tool correctly without an output schema.

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

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

The tool has zero parameters, so there is no parameter semantics to clarify. The schema coverage is complete at 100%, and the description correctly focuses on behavior and output rather than parameters. Baseline 4 is appropriate.

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

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

The description clearly identifies the resource ('latest match run'), the type of data returned ('scanned, inserted, elapsed' and feed counts), and the intended polling context. It is specific enough to distinguish this tool from related siblings like get_apply_run_status or 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?

The description explicitly states when to use this tool: 'for polling after upload_cv, update_targeting or refresh_matches.' This gives clear context, though it does not explicitly mention alternatives or 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?

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 the tool as read-only, idempotent, and non-destructive. The description adds value by disclosing exactly which data areas are included and by indicating call ordering, which goes beyond the annotations.

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

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

The description is one information-dense sentence plus a short directive. Every clause carries meaning, and nothing is wasted or redundant.

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

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

For a zero-parameter read-only tool without an output schema, this is complete: the agent knows when to call it, whose data it returns, what categories of data are included, and that it is safe. No critical guidance 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 100% schema coverage, so there is no input ambiguity. The description helpfully enumerates the data the agent can expect back, partially compensating for the lack of an output 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 defines the tool as a composite account snapshot: CV profile, targeting rules, and plan status. It also distinguishes itself from siblings like get_account or get_targeting by bundling those concerns into one bootstrap call.

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 explicit instruction 'Call this first' gives clear when-to-use guidance for an initial context-loading call. It does not mention exclusions or alternatives, but for a zero-parameter bootstrap tool that is a minor gap.

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 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?

The description explains the full behavioral flow: the link is opened by the person in a browser, payment is made, and the account upgrades automatically when payment lands. It also adds value beyond the sparse annotations by clarifying the delivery mechanism and the external effect. It does not contradict the annotations.

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

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

Two sentences with no filler. The first sentence defines what is returned and the key commercial terms; the second explains how to use it and what happens next. 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 zero-parameter, no-output-schema tool, the description is sufficiently complete: it states what the link is, what plan it's for, how it's used, and what happens after payment. No critical operational detail is missing for an agent 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?

The tool has zero parameters and the schema is already complete. The description therefore has no parameter documentation burden, and the score is set to the baseline for a no-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 names the exact resource (checkout link), the plan (Pro at $49/month), the provider relationship (active payment provider), and what the user does with it. This clearly distinguishes it from other payment-related tools like get_billing_portal_link, because the focus is a one-time checkout-to-upgrade flow.

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 is clear about when to use it: when a user wants to upgrade to Pro by paying via a checkout link. It also explains the expected downstream behavior once the link is used. However, it doesn't explicitly name alternatives like get_billing_portal_link, so the differentiation 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 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?

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 this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond annotations by specifying that results are live and calibrated, and that each job includes a recruiter-pass verdict and application-sent status. 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 description is tightly written: three sentences, purpose first, then result contents, then filtering controls. No fluff and no repetition of schema defaults.

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

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

With no output schema, the description appropriately lists the key per-job fields and the main filters. It is slightly brief on pagination details and does not mention empty-CV or no-match behavior, but it is sufficient for a read-only list operation in a large sibling set.

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 covers 67% of parameters, and the description restates that filtering is by match tier and freshness and pagination by offset. This adds mild grouping value, but it does not meaningfully enrich beyond the schema's own parameter descriptions for sort, fresh, match, and applied, nor explain limit or offset semantics beyond a brief mention.

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: listing live vacancies matched to the account's CV, ranked. It also declares what each result contains (match percentage, recruiter-pass verdict, application status), which clearly distinguishes it from siblings like list_my_applications, list_hidden_jobs, or get_job_posting.

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

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

The description gives clear operational context: this tool returns matched vacancies for the current account, filterable by match tier and freshness, with offset pagination. It does not explicitly contrast with alternative tools or state when not to use it, but the intended use case is evident from the description.

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 useful context about scope ('every application sent for this account') and the returned status fields. However, it does not disclose pagination behavior or how the filter affects the result set.

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, focused sentence that front-loads the scope and then lists the returned fields. It is concise and contains no filler, though the long field list could be slightly more structured.

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 only partial parameter documentation, so the description carries a heavy burden. It explains the returned fields but leaves include_cover_letter undefined, does not explain limit behavior or pagination, and provides no decision support for sibling list tools. It is adequate only as a basic overview.

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 needed to compensate for the undocumented limit and include_cover_letter parameters. It does not mention either parameter. The mention of 'how many screening questions it still waits on' describes an output field, not the only_waiting_on_me filter semantics, so the description adds no real meaning beyond the schema.

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

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

The description clearly states a specific verb and resource: it lists applications sent for the current account, and enumerates the fields returned (company, title, stage, outcome, etc.). It is not a tautology and is easy to understand, but it does not explicitly distinguish itself from sibling tools like list_run_history or get_tracker.

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

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

There is no guidance about when to use this tool versus alternatives such as list_run_history, get_tracker, or list_blocking_questions. The description says what is returned but not why an agent should choose this tool over its 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?

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable contextual behavior: it is a paid model call, limited to 20 per hour, and has the same billing gate as applying. It also clarifies that every segment is labelled tailored, verbatim, or pinned, which describes the output behavior beyond the schema.

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

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

Two dense sentences with no filler: the first describes the tool's scope and output components, the second covers safety and cost constraints. Every sentence contributes essential information and the key context 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 one-parameter preview tool with rich annotations, the description is nearly complete. It covers purpose, output content, non-sending behavior, and rate/billing limits. The only minor gap is that it doesn't explicitly describe the exact return format or structure beyond naming the segments, but the description supplies enough 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?

Schema coverage is 100% and the only parameter job_id is already documented with its source in the schema. The description only implicitly reinforces that the CV is tailored 'for one vacancy', which adds no real semantics beyond the schema.

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

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

The description states a specific verb and resource: 'Rewrite this account's CV for one vacancy' and enumerates exactly what the preview contains (headline, summary, rewritten bullets, curated skills, cover letter). 'Nothing is sent' and 'preview only' clearly distinguish it from sending/apply tools even without naming a sibling.

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

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

Usage is implied: the tool previews what Keywordise would send, and 'Nothing is sent' signals it is a dry-run before applying. However, it does not explicitly name alternatives or provide clear when-to-use/when-not-to-use guidance relative to sibling tools like start_apply_run or get_my_cv_pdf.

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 explicitly states 'Idempotent and cheap when nothing is new,' but the annotations set idempotentHint to false. This is a direct contradiction between the description and the structured metadata, which undermines reliability and warrants the lowest transparency score.

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: the main action is in the first sentence, followed by two short sentences that add meaningful behavioral and parameter detail. Every sentence earns its place without 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 simple one-parameter background trigger with no output schema, the description covers the operation, the force flag, and the idempotency/no-op behavior. It does not mention how an agent would discover results or status afterwards, but given the low complexity and sibling tools like get_match_status, 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 description coverage is 0%, but the description fully compensates for the single parameter by explaining that force=true runs a full re-match regardless. It also clarifies the default incremental behavior through the first sentence, so the agent understands exactly what the parameter does.

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 and resource: match the account's CV against vacancies added since the last look, in the background. This is clear and unambiguous, though it does not explicitly name sibling tools or contrast itself with them.

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 and explains when to set force=true, but it does not provide explicit guidance on when to prefer this over alternatives like get_match_status or list_matching_jobs. The 'idempotent and cheap when nothing is new' line gives useful context but stops short of explicit when-to-use or when-not-to-use wording.

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 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?

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?

The description goes well beyond the annotations by disclosing concrete consequences: it actually submits inside the employer's system, applications leave in the person's name, it never re-applies to jobs already applied to, and it consumes plan quota. This is high-stakes behavioral context that an agent needs before invoking the tool, and it aligns with destructiveHint, openWorldHint, and idempotentHint.

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

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

The description is dense but every sentence earns its place: the action, the safety valve, the prerequisites, the side effects, and the follow-up polling step. The most important consequence—real submission—is front-loaded, and the dry-run escape hatch appears early enough to prevent accidental real applications.

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

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

For a complex, destructive, externally visible operation with no output schema, the description is remarkably complete: prerequisites, side effects, plan usage, filter semantics, duplicate avoidance, dry-run mode, and status polling are all covered. An agent has enough information to decide whether to call it, how to call it safely, and what to do afterward.

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

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

With only 50% schema description coverage, the description compensates by explaining `limit` (takes up to limit matching jobs) and `dry_run` (does everything except submit). The `fresh` and `match` parameters remain schema-covered with defaults explained, and tying them to 'same filters as list_matching_jobs' adds valuable cross-tool context.

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

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

The description states a specific verb and resource: 'Start an application run' and then explains exactly what that entails—tailoring CV/cover letters, answering screening questions, and submitting inside the employer's system. It clearly differentiates from siblings by referencing list_matching_jobs filters and get_apply_run_status for polling, so an agent can distinguish it from preview, listing, or status 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 gives strong contextual usage signals: real applications are submitted, prerequisites are a confirmed email and active plan, it counts against the plan, and dry_run=true is the non-submitting safe path. It does not explicitly name alternatives like preview_tailored_cv or stop_apply_run, but it clearly implies when the tool is appropriate and what preconditions must hold.

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 this is a mutating but non-destructive operation. The description adds meaningful behavioral detail: the run stops only after the current job, nothing is left half-done, and already-sent applications remain sent. This goes beyond what the annotations alone 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?

Two short, front-loaded sentences contain all necessary information without any filler. The first states the action and timing; the second provides the safety guarantee.

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 action with no output schema, the description covers the essential context: when it applies, what happens, and the side-effect guarantee. It does not describe the return value, but none is declared and the behavior 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?

The tool has zero parameters and an empty input schema, so there is no parameter documentation burden. The description correctly avoids inventing parameter details that do not 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 states a specific action (stop) on a specific resource (the running application run) and defines exactly when it happens (after the current job). It is easily distinguished from siblings like start_apply_run and 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 implies the key precondition: there must be a running application run. It clearly communicates that this is a graceful stop rather than an immediate cancellation, which tells the agent when this tool is appropriate. It does not name sibling alternatives, but no sibling offers the same stop action.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that keywords come from the saved profile, which is useful, but it does not disclose the output format or any other behavioral nuance. This is acceptable given strong annotations but adds only moderate value beyond them.

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, efficient sentence that front-loads the core function and then supplies the practical use case. No filler, no repetition of the title, 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?

Given that the tool takes no parameters and has no output schema, the description is mostly complete: it says what the tool does and why it is useful. It could be more explicit about the return shape, but 'keywords derived from saved profile' is enough for an agent to understand the expected result.

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 schema already fully describes the input surface. The description still adds relevant context by clarifying that results derive from the saved profile and are meant for include_keywords, which fits the baseline of 4 for parameterless 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?

The description clearly identifies the tool's action ('search keywords') and its resource ('derived from the saved profile'). It also states its intended use ('useful as include_keywords in update_targeting'), which distinguishes it from generic keyword tools and ties it to a specific sibling 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 description implies clear usage context: when preparing include_keywords for update_targeting, this tool is the source of suggested keywords. It does not explicitly state when not to use it or mention alternatives, but for a zero-parameter utility tool the context is reasonably 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 mutation (readOnlyHint=false) and non-idempotency. The description adds valuable behavioral detail beyond that: it states the job returns to the feed and the negative signal is dropped. This clarifies 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?

A single, front-loaded sentence states the action and its consequences with no filler. Every phrase earns its place, and the key behavior is immediately visible.

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 covering read-only/idempotent/destructive aspects, the description is essentially complete. It explains the effect and the input source is covered by the schema. A small gap is the lack of any expected response or error semantics, but this is minor given the tool's simplicity and low parameter count.

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 fully documents job_id with its allowed source, and there is only one parameter. The description adds no additional parameter-level meaning beyond referring to 'the job', so the schema carries the burden and 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?

The description opens with a specific verb and target ('Undo hide or dislike') and clearly distinguishes this from read-only siblings like list_hidden_jobs by stating the job returns to the feed. The title reinforces the same meaning, so an agent can immediately tell 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 makes the operative scenario explicit: use this when a job was hidden or disliked and should be restored to the feed. It does not name alternative tools explicitly or state when not to use it, but the use case is clear enough and the sibling set contains no equivalent 'hide' tool.

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

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

Annotations are all false, providing no safety hints, so the description carries the behavioral burden. It discloses that untouched fields remain untouched (patch semantics) and that the feed will be re-ranked as a side effect. This goes beyond the structured data and helps set 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 three sentences with no filler. The purpose is front-loaded, input semantics follow, and the side effect is stated last. 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?

Given the open-ended patch object and lack of output schema, the description provides the key details: what to send, that changes are partial, and that the feed re-ranks. The ellipsis acknowledges additional fields without an exhaustive enumeration. It doesn't cover validation or errors, but for this tool 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?

The schema only says 'Profile fields to change, by name.' The description greatly expands this by listing numerous concrete field names and explaining the partial-update behavior ('everything else is untouched'). This is essential for correctly constructing the patch object.

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 verb+resource: 'Change fields of the saved profile'. It also distinguishes the tool from upload_cv by explicitly saying 'without re-uploading the CV'. The list of concrete fields further clarifies exactly what the tool operates on.

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

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

It explains when to use this tool: when changing profile fields without replacing the CV. It also gives usage guidance by telling the agent to send only the fields to change, implying a partial update. It doesn't explicitly name alternatives beyond the CV-upload distinction, 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 indicate this is a mutating, non-readonly operation. The description goes beyond them by explaining the partial-patch behavior and the background re-matching side effect. It does not describe response or validation behavior, but the annotations cover 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?

The description front-loads the action and the key partial-update instruction, then lists the supported fields, and ends with the background effect. It is dense due to the long field list, but every element 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?

For a single nested parameter with no output schema, the description supplies the essential field list, value constraints, and post-call behavior. Minor gaps remain around response format and unknown-field handling, but the tool is callable with the information provided.

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 describes the patch parameter as 'Targeting fields to change, by name', leaving nested field semantics undefined. The description compensates by enumerating many valid keys, enum values (remote_mode, geo_scope), and formats (ISO-2 for geo_countries), giving the agent substantially more meaning than the schema alone.

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 and resource: 'Change targeting rules', and the title clearly states 'Change my job targeting'. It clearly distinguishes from the read sibling get_targeting and other profile tools, so an agent can identify it as the update operation for 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 instruction 'send only the keys to change' provides clear partial-update semantics, and the note that the feed re-matches in the background tells the agent what happens after the call. It does not explicitly name alternatives or exclusion criteria, but the intended use is clear from the 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 only indicate that this is not read-only, so the description carries the burden of explaining side effects. It does so by disclosing that the default behavior saves the profile and rebuilds the job feed, and that save=false avoids persistence. It also adds practical constraints: PDF/DOCX formats and an 8 MB limit.

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: purpose, parsed fields, save behavior, and size limit are all covered. The most important outcome is front-loaded, and the conditional branch is explained immediately after.

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 accepted formats, size limit, parsed fields, and the persistence vs review-only behavior, which is sufficient for most calls. The main gap is that it does not explicitly state what a successful save=true response contains, but the absence of an output schema is partially mitigated by describing the resulting profile state.

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 documents filename and content_base64 and notes save's default, but the description adds meaningful semantics: save=true vs false changes whether the parser result is persisted or just returned, and file type/size constraints are called out. This supplements the schema rather than merely repeating 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?

The description names a specific verb and resource: it uploads a CV file and converts it into the account's profile. It also lists the parsed fields, making the tool's function concrete and distinct from read-oriented siblings like get_my_profile or preview_tailored_cv.

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 explains the two modes of use: save=true saves the profile and builds the job feed, while save=false returns the parsed profile for review only. It does not explicitly name alternatives like update_profile or preview_tailored_cv, but the conditional behavior provides solid usage guidance.

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