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?

Beyond the annotations (which only mark this as a non-idempotent write), the description discloses substantial behavior: a confirmation email is sent, applying is gated on address confirmation, and the trial/paid plan terms. This is exactly the kind of side-effect and prerequisite context annotations cannot convey.

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

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

Front-loaded with the action and requirement, then flows into consequences. The trial and pricing details are on the verbose side but are decision-relevant context rather than padding.

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

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

For a mutation tool with no output schema, the description covers prerequisites, side effects, and the gating flow, and it names the API key returned. It is complete enough to invoke correctly, though it doesn't detail error/validation behavior.

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

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

Schema coverage is 0%, so the description must carry the load. It explains accept_terms meaningfully (accepting Terms/Privacy and authorising job applications on the user's behalf), but email and password are left to the schema's format/length constraints with no added meaning.

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

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

The description opens with a specific verb and resource ('Register a new Keywordise account') and states the outcome ('receive an API key for it'). It is clearly distinguishable from siblings like login, create_api_key, and get_account.

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

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

It states the key precondition (accept_terms=true) and the post-registration flow (confirmation email, applying opens after confirmation), giving clear context for when this applies. It does not explicitly contrast against login for existing accounts, so it stops short of full when/when-not routing.

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

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

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

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

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

Three short sentences with the primary action first, followed by two high-value constraints. No filler or repetition.

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

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

For a one-optional-parameter create tool with no output schema, the description covers purpose, quota, and the one-time visibility of the key. It doesn't spell out that the label is optional or what happens when the five-key cap is reached, but these are minor given the low complexity.

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

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

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

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

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

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

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

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

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

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

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

Annotations already include destructiveHint=true, and the description adds important behavioral detail: the operation is irreversible, it destroys specific categories of data, and it requires confirm_email to match the account address. There is no contradiction with the annotations.

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

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

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

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

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

With one parameter, destructive annotations, and no output schema, the description covers action, scope, irreversibility, and the prerequisite for invocation. Nothing needed to call the tool correctly is missing.

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

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

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

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

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

The description uses a specific verb ('Erase') and precisely identifies the resource ('the account') and everything it contains. The enumerated data types make it easy to distinguish from sibling tools like delete_saved_answer or cancel_subscription.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Three sentences with no filler, front-loaded with the usage trigger and followed by behavior and preset options. Every sentence adds useful information.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those: the result is delivered as a file, and large accounts receive different handling. No contradiction with annotations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful scoping context: the data belongs to the account behind the calling key, which clarifies the operation's anchor and why zero parameters suffice. No contradiction with annotations.

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

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

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

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

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

For a zero-parameter read-only getter with no output schema, the description carries the return-value burden well, enumerating fields in commendable detail. Minor gaps remain: terms like 'applications used' and the exact shape of subscription state are slightly ambiguous, and error behavior is unmentioned, but nothing needed to invoke the tool correctly is missing.

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

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

The tool takes zero parameters and the input schema has 100% coverage, so the baseline-4 rule applies. The description's scoping phrase ('behind this key') implicitly confirms the account is resolved from the caller's credentials rather than from any parameter.

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

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

States a specific resource ('the account behind this key') and enumerates exactly what it returns: email, confirmation status, plan state (trial days, applications used/remaining, subscription), and active API key count. The scope is precise and informative, though it does not explicitly differentiate from overlapping siblings like get_my_profile or list_api_keys.

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

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

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

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

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

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

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

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

The description is compact but information-dense. Every sentence earns its place: the first scopes the tool and names alternatives, the second details return fields and the completion condition. It is front-loaded and not padded.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%, and the single optional 'design' parameter is already documented with its default behavior. The description only references 'the chosen design' without adding new parameter meaning. Baseline 3 is appropriate because the schema handles parameter semantics.

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

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

The description states a specific resource, 'the account's base CV', and a clear action, 'rendered as a PDF ... returned as a file.' The parenthetical '(the saved profile, untailored)' distinguishes this from tailored CV variants like get_sent_cv_pdf or preview_tailored_cv. There is no ambiguity about what the tool does.

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

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

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

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

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

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

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

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

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

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

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

For a zero-parameter read-only tool, the description covers purpose, contents, and usage boundaries well. There is no output schema, so the description's enumeration of returned data partially compensates, though it stops short of describing the exact response structure or field formats.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The description appropriately focuses on what the tool returns rather than inputs, which is the only meaningful semantic contribution possible here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds behavioral value by stating that the result is returned as a file rather than structured data, and that it is the exact artifact sent to the employer.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The tool has zero parameters and 100% schema coverage, so the description cannot meaningfully add parameter-level detail. The no-parameter baseline is 4, and the description appropriately focuses on clarifying the scope of the returned resource instead.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_my_applications, move_tracker_card, or set_tracker_note. It simply describes what the tracker board contains, leaving usage context entirely implied.

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

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

Annotations only declare the mutation-ish flags (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds genuinely new behavioral context: the upgrade is asynchronous and external, completed only once the payment lands in the browser — a side effect an agent cannot infer from the flags.

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

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

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

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

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

No output schema exists, and the description does explain what the caller gets (a checkout link) and what happens after payment. For a single-optional-param tool this is nearly complete; only explicit alternative-tool routing is missing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The entire description is one focused, front-loaded sentence. It states the resource, scope, returned fields, and a critical privacy guarantee with zero wasted words.

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

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

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

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

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

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

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

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

The description uses a specific verb ('list') and resource ('API keys'), and specifies scope ('active', 'on this account') and the exact output fields (prefix, label, created, last used). This clearly distinguishes it from sibling tools like create_api_key and revoke_api_key.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%: the only parameter, limit, has a clear description plus default/min/max. The description adds no parameter-specific meaning, which is acceptable since the schema already handles it.

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

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

States a specific verb ('list') and resource ('blocking questions'), and clarifies these are employer questions, grouped by application, with suggested answers. It also names the answering sibling, distinguishing this read/list tool from actions like answer_screening_question.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false. The description adds the useful detail that the result includes the account's current pick, but it does not disclose output shape, ordering, or any list-level behavior beyond that. No contradiction with annotations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: ordering ('jobs that apply automatically come first'), the default scoping (fresh='new' means last two weeks, match default excludes weak matches), and the per-job payload contents. This is genuinely useful information an agent cannot derive from the annotations.

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

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

Front-loads the when-to-use triggers before the behavioral detail, which is the right order. The middle sentence listing what each job carries is somewhat run-on, but every clause carries information rather than filler.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (match percentage, recruiter-pass verdict, auto-apply status, awaiting-answer flag, already-applied flag) plus ordering and default filtering. For a 7-parameter, 0-required list tool, nothing essential is missing.

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

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

Schema description coverage is 71% and four parameters have enums, so the schema already documents sort, fresh, match, applied, and auto_only. The description only restates the filter axes ('match tier, freshness and applies-automatically; page with offset') without adding syntax or edge-case detail, so the baseline 3 applies.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructveHint, so safety is covered. The description adds useful account-scope context and the automatic-reuse behavior, but does not disclose output shape, ordering, or whether results are paginated. No contradiction with annotations.

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

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

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

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

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

For a zero-parameter, read-only list tool, the description is largely sufficient: it states the account scope and the purpose of the answers. Slight gaps are the lack of detail about the returned entry fields and pagination behavior, but these are minor given the tool's simplicity and the safety-related annotations.

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

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

The tool has zero parameters and schema description coverage is 100%, so the description need not explain parameters. The phrase 'every screening answer' reinforces the unfiltered, account-wide scope, aligning with the empty input schema.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For a single-parameter, no-output-schema tool, the description is complete: it explains what the tool does, what the generated result contains, that it is preview-only, and the cost/rate-limit behavior. An agent has enough to select and invoke it correctly.

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

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

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

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

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

States a specific verb and resource: 'Rewrite this account's CV for one vacancy' with a clear list of output components. The 'preview only' framing and 'Nothing is sent' distinguish it from sending/apply tools like start_apply_run and get_sent_cv_pdf.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Four sentences, each carrying distinct value: core behavior, conditional idempotence, parameter semantics, and required follow-up polling. It is front-loaded with the main operation and contains no filler or repetition.

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

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

For a background mutation with no output schema, the definition provides the essential operational contract: what runs, how force/rebuild change behavior, what to do after calling, and why waiting for ready matters. Nothing an agent needs to invoke it correctly is missing.

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

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

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

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

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

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

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

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

It gives explicit conditions: use force=true for a full re-match, use rebuild=true when the feed looks wrong, and poll get_match_status until ready before calling list_matching_jobs. This gives an agent a clear call-and-poll workflow rather than leaving the decision to inference.

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

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

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?

Annotations already mark destructiveHint=true, but the description adds critical behavioral details: real applications leave in the person's name, require a confirmed email and active plan, consume plan quota, and actually submit inside the employer's system. It also discloses the dry_run safety valve and the 'never one already applied to' guard.

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

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

Though long, every sentence earns its place. It front-loads usage triggers, then flows through prerequisites, process, side effects, and follow-up. No fluff or redundancy; the density is justified by the action's complexity.

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

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

Without an output schema, the description fully explains the action's scope, prerequisites, side effects, and next step (poll get_apply_run_status). It also covers edge cases like single-job scoping and dry-run. An agent has everything needed to invoke correctly.

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

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

Schema coverage is only 60%, so the description compensates heavily. It explains job_id semantics (ignores other filters), dry_run (everything except submit), and limit (up to N matching jobs, best fit first). It also ties fresh/match to the account's saved filters.

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

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

The description states a specific action (start an application run), the resource (matching jobs), and the outcome (tailored CVs, cover letters, screening answers, submissions). It clearly distinguishes itself from siblings like list_matching_jobs (listing) and get_apply_run_status (polling), and explains the job_id scoping for single-job applications.

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

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

The description explicitly lists trigger phrases ('apply for me', 'apply to the best matches', 'apply to this job'), mandates showing jobs first, and instructs to poll get_apply_run_status afterwards. It contrasts with list_matching_jobs by referencing the same filters and clarifies when to use job_id vs. batch mode.

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

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

The annotations are all false, so the description carries the behavioral burden. It adds important context: the stop is requested after the current job, nothing is left half-done, and already-sent applications remain sent. It could also disclose what happens if no run is active or whether the run can later be resumed, but the provided transparency is solid.

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

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

Three short sentences with no filler. The trigger phrases and core semantics are front-loaded, and the consequences are stated in a compact final sentence.

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

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

For a zero-parameter control action, the description covers purpose, scope, async behavior, and postconditions. It does not mention the no-active-run case or reversibility, but those are relatively minor gaps given the sibling tool get_apply_run_status could provide status 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?

The tool has zero parameters, so there is no parameter detail to clarify; the baseline for a zero-parameter tool is 4. The description correctly avoids introducing any phantom input options.

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: 'stop' an 'application run', plus the precise boundary ('after the job it is on'). Trigger phrases and the contrast with a running run make it easy for an agent to distinguish from start_apply_run and other 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?

Gives explicit trigger phrases ('stop applying', 'pause', 'hold off') and clearly implies it applies only to a running application run. It does not explicitly name alternatives or say when not to use it, but the intended use case is unambiguous.

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

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

Annotations already cover 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?

All annotations are false, so the description carries the full burden and meets it: it discloses the parse pipeline, that save=true persists the profile and rebuilds the job feed (a real side effect), that save=false returns the parsed profile for review only, and the 8 MB input cap. No contradiction with annotations — the described write behavior aligns with readOnlyHint=false, and the side-effect disclosure fits idempotentHint=false.

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

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

Two sentences with zero filler: trigger condition is front-loaded, followed by the parse pipeline, the save-toggle semantics, and the size limit, each clause earning its place. It avoids restating schema content like base64 encoding or parameter names.

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

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

With no output schema and no annotation support, the description explains exactly what the agent gets in each mode — a saved profile with a rebuilt feed, or a review-only parsed profile whose contained fields are enumerated. Input constraints (format, size) are covered; the only minor omissions are error behavior for oversized/unsupported files and whether an existing profile is overwritten, which are secondary for a 3-parameter upload tool.

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

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

The schema documents filename and content_base64 but leaves save completely undescribed; the tool description compensates by fully explaining both save modes and their downstream consequences (feed built vs. review only). It also adds accepted formats (PDF/DOCX from the title) and the 8 MB constraint, which are not in the schema, pushing it above the baseline for its 67% schema coverage.

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

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

States a specific verb + resource ('Upload a CV file and turn it into the account's profile') and names the exact parsed fields (name, contact, summary, roles, skills, languages, education), so an agent knows the transformation this performs. The opening trigger phrase ('Use when the person shares or mentions their resume/CV') plus the explicit profile-building behavior distinguishes it from siblings like update_profile and preview_tailored_cv without needing to open their schemas.

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

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

Opens with an explicit trigger condition and illustrative user quotes ('here's my resume', 'use my CV'), which is strong guidance for when to select this tool. It also tells the agent the save=true vs save=false trade-off (persist and build feed vs. review only), effectively a when-to-persist guideline. It does not explicitly name alternatives or exclusions (e.g., 'use update_profile for direct field edits'), which keeps it from a 5.

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