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

Description adds valuable behavioral details beyond annotations: soft-delete nature, preservation of scans, removal from lists, and scheduler stoppage. Aligns with annotations (idempotentHint=true, destructiveHint=false) without 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?

Two sentences that are front-loaded with the key action and effect. No redundant or unnecessary 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 simple tool with one parameter and no output schema, the description covers the core behavior well. Could mention reversibility via unarchive briefly, but that is implied by the sibling 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?

Input schema has one parameter with full description coverage (100%). The description does not add additional meaning beyond what the schema provides, so baseline score of 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?

Description clearly states the action ('soft-delete/archive') and the resource ('campaign'), with specific effects (removes from lists, stops scheduler, preserves scans). Distinguishes from sibling tools like 'archive_campaign_group' and 'unarchive_campaign'.

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?

Description provides clear context on what happens when archiving, implying when to use (e.g., to soft-delete). Does not explicitly state when not to use or compare with alternatives like cancel_campaign, but the context 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 discloses the cascade behavior (group and campaigns) and the restriction on default groups. Annotations already provide idempotentHint and destructiveHint, and the description's 'soft-delete' aligns with destructiveHint false. 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?

Two sentences, no fluff. The key information (what it does, exception) is front-loaded. 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?

Given 1 parameter and no output schema, the description adequately covers the tool's main behavior and an important exception. Siblings like archive_campaign and unarchive_campaign_group provide context. A small gap is not mentioning any side effects beyond soft-delete, but annotations fill that role.

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 (group_id) already has a full schema description ('Campaign group UUID.'), so the tool description adds no extra meaning beyond the context of archiving. 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 clearly states the action ('soft-delete') and the resources affected ('the group AND every campaign in it'). This distinguishes it from sibling tools like archive_campaign (single campaign) and cancel_campaign_group (different 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?

Explicitly states when not to use (default group) and what to do instead ('ask the user to move campaigns out first'). Could be improved by mentioning archive_campaign as an alternative for individual campaigns, but the guidance 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?

Beyond annotations (destructiveHint, idempotentHint), the description reveals the critical side effect: naming a campaign on a different set MOVES it here and silently stops evaluation against the old set. It also states membership changes are incremental (other members unaffected). This is exactly the kind of behavior an agent must know and is not disclosed by the schema or 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 five sentences, all relevant and front‑loaded with the primary action, then the distinctions and warnings. It could be slightly tightened (e.g., the last two sentences could merge), but every sentence earns its place given the side‑effect complexity. No 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 destructive mutation tool with no output schema, the description covers the essential context: the exclusive membership mechanism, incremental behavior, the moving hazard, the 500‑item cap, and verification steps. Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 100% and both parameters already have detailed descriptions, including the 500‑per‑call limit and the move behavior for `campaign_ids`. The description adds a practical instruction to split lists over 500, but it largely repeats schema info rather than adding new semantic depth. 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 'Bind campaigns to a policy set' — a specific verb and resource — and immediately distinguishes itself from `detach_policy_set_campaigns` and `update_policy_set`. This makes the tool's role unambiguous even without reading the schema or sibling names.

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

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

It explicitly states this and `detach_policy_set_campaigns` are the only ways to change membership, notes `update_policy_set` never affects campaigns, and gives concrete pre‑call guidance (check `list_campaigns` for existing bindings, split lists over 500, verify with `list_policy_set_campaigns`). This fully orients the agent on when and how 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 behavioral context beyond annotations: it returns replayed/skipped counts and re-fires events. Annotations already indicate readOnlyHint=false and destructiveHint=false, which align with this mutation. However, it does not disclose idempotency, potential duplicates, or whether replaying is safe to rerun.

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 that are front-loaded with the essential action and return type, followed by the use case. No extraneous 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 adequately covers the tool's purpose, use case, and return format. It does not explain what 'replayed' vs 'skipped' means or mention rate limits, but for a simple 3-parameter tool with clear schema, 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?

Schema coverage is 100%, so each parameter has a description. The description reinforces the time window interval notation ([from_ts, to_ts)) which adds a slight nuance about inclusivity/exclusivity, but overall the schema provides adequate 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 clearly states the tool's action: replay every delivery attempt for a webhook endpoint within a time window. It specifies the resource (webhook endpoint), the scope (every delivery in [from_ts, to_ts)), and the output (replayed/skipped counts). The use case 'recover after a downstream outage' further clarifies purpose and distinguishes it from sibling tools like replay_webhook_delivery.

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 context for when to use this tool: 'Use to recover after a downstream outage'. While it does not explicitly mention when not to use it or list alternative tools, the single use case is clear and actionable.

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

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

The description discloses behavior beyond annotations: alerts that cannot transition are skipped rather than failing, and the response reports `updated` and `skipped` counts. Annotations already indicate idempotency and non-destructiveness, so the description adds meaningful context about the operation's effect, though it does not cover every possible failure mode.

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 concise sentences with zero fluff. The core purpose is front-loaded, and the selection modes and behavior are explained efficiently. 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 an 11-parameter bulk operation with no output schema, the description explains the two selection strategies, the response format (`updated` and `skipped` counts), and points to the single-alert alternative. It relies on the schema for the full filter list, which is acceptable given 100% schema coverage, and it advises checking scope via `get_alert_stats` indirectly through the schema's `all_matching` comment.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter. The description adds value by clarifying the mutually exclusive selection modes (ids vs all_matching), the maximum id count, and that filters mirror `list_alerts`, which helps an agent understand parameter relationships without deep schema inspection.

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 the status of many alerts at once') and explicitly differentiates itself from the single-alert sibling by recommending `update_alert_status` for one alert. This tells an agent exactly what the tool does and how it is distinct.

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 provides explicit usage guidance: select either an `ids` list or `all_matching` with filters, and it routes to `update_alert_status` for single alerts. It also explains the skip behavior and how to interpret the response counts, which helps an agent decide when to use this tool and how to validate the result.

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

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

The description discloses that credits are refunded and returns count of cancelled scans, adding value beyond annotations which include idempotentHint=true and destructiveHint=false.

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

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

Two sentences, front-loaded with the main action, every sentence adds 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 single-parameter tool with no output schema, the description adequately explains behavior and return value.

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 100% schema coverage, the description adds no extra detail beyond the schema's 'Campaign UUID' for campaign_id, so baseline score of 3 applies.

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

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

The description clearly states it cancels pending scans across all unfinished runs of a campaign, distinguishing it from siblings like cancel_run and cancel_scan.

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 that running scans complete normally and pending scans are cancelled with credit refund, providing context for when to call it, though it doesn't explicitly contrast with alternatives.

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 behavioral details beyond annotations: it refunds credits and returns a count. The annotations already indicate idempotent and non-destructive (destructiveHint=false), and the description aligns with these traits.

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 action, side effect, and output with no redundant 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 simple cancellation tool with one parameter and no output schema, the description adequately covers the action, refund behavior, and return value. It does not mention permissions or edge cases, but the context is sufficient for basic use.

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 sole parameter (group_id) is fully described in the schema (format: uuid, description: 'Campaign group UUID.'). The tool description does not add extra parameter meaning, so a baseline score 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 clearly states the action (cancel pending scans across all campaigns in the group), side effects (refunds credits), and output (total cancelled count). It distinguishes well from sibling tools like cancel_campaign and cancel_scan.

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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives (e.g., cancel_campaign or cancel_scan). Usage context is only implied.

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

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

The description discloses that running scans complete and pending scans get refunded, adding behavioral context beyond the idempotentHint annotation. It also states the return value (count of cancelled scans). While annotations exist, the description provides useful nuance.

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 two sentences long, front-loaded with the core action, and every sentence adds value. No redundant or filler content.

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

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

Given the simple operation (cancel pending scans in a run) and the presence of output description (returns count), the description is complete. No output schema is needed as the return value is stated.

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 already fully describes the single parameter (run_id) with 100% coverage. The description does not add further parameter-level details, so it meets the baseline for high 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 clearly states that the tool cancels pending scans within a run, differentiating it from sibling tools like cancel_scan (single scan) and cancel_campaign (campaign-level). It uses specific verbs and resources: 'Cancel every pending scan within one run.'

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 for run-level cancellation but does not explicitly state when to use this tool versus alternatives like cancel_scan or cancel_campaign. There are no exclusion criteria or direct comparisons.

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 show idempotentHint=true and destructiveHint=false. The description adds the key behavioral detail that cancellation refunds the scan credit, which is beyond what annotations provide. 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 three short sentences with no wasted words. Every sentence adds value: action, boundary conditions, and side effect. Front-loaded with the core action.

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 tool with one parameter, no output schema, and clear annotations, the description covers all essential aspects: what it does, when it works, and what side effects occur. No additional information is needed.

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

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

There is only one parameter (scan_id) with 100% schema coverage and a clear description in the schema. The tool description does not add additional semantic value beyond stating it is a UUID, so a baseline score 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 clearly states 'Cancel one pending scan by UUID', specifying the action, resource, and unique identifier. It distinguishes from similar tools like cancel_campaign and cancel_run by focusing on scans and the 'pending' state condition.

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 notes that already-running or completed scans are no-ops, guiding when the tool is applicable. It also mentions the refund effect, but does not explicitly compare with sibling tools like cancel_campaign.

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

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

The description goes beyond annotations by disclosing that the full key is returned once, the server stores only a hash, and the user must store the key. This is critical behavioral detail not inferable from annotations.

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

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

Two sentences with no filler. Front-loaded with the action and immediately followed by the most important behavioral note. Highly efficient.

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?

Despite lacking an output schema, the description explains the return behavior (full_key one-time). All parameters are fully documented in the schema. No additional context is needed for this simple tool.

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

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

Schema coverage is 100% and both parameter descriptions are already in the schema. The description adds no additional semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description uses a clear verb ('Mint') and resource ('API key'), and uniquely highlights the one-time return of the secret. This distinguishes it from sibling tools like revoke_api_key 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?

The description clarifies the scope ('caller's organization') and the critical one-time display. However, it does not explicitly state when not to use or suggest alternatives, though the context is inherently 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 are minimal (no readOnly, no destructive, no idempotent), so the description carries the behavioral disclosure burden. It discloses the cost formula (N credits), the fact that it creates scans, and the return shape (one entry per country with repeat_scan_ids). It does not state idempotency or auth requirements, but those are not essential given the operation is clearly a creation. It adds meaningful context beyond the sparse 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 concise and front-loaded: the first sentence states purpose and example, the second gives the cost formula, the third explains the return structure. No filler. It is slightly longer than necessary but every sentence adds information relevant to using the tool correctly.

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

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

For a tool with 12 parameters and no output schema, the description covers the core behavior, cost, and return shape. It does not enumerate all parameters (the schema does), but it explains the key cross-parameter interactions (cost, repeat multiplier) and gives a clear example. It lacks detail on error handling or edge cases, but those are partially in the schema descriptions. Overall, adequate for a complex tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the cost formula tying country_codes and repeat_count together, and clarifying that repeat_count is a multiplier on the tool's own fan-out. It also clarifies the output's repeat_scan_ids semantics. This goes beyond what the schema states, justifying a 4.

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 ('Queue'), resource ('one new scan per country'), and a concrete use case (testing the same URL across multiple countries). It clearly distinguishes from sibling tools like create_scan, which is for a single scan, by emphasizing the per-country fan-out.

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 provides clear context for when to use this tool: when you need to run the same check across multiple countries in one call. It does not explicitly name create_scan as the single-country alternative, but the sibling list includes it and the purpose is evident. A more explicit 'use create_scan for a single country' would raise this to 5.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds valuable behavioral context: credits are charged at run time, repeat_count multiplies the bill, and the returned campaign echoes specific fields for verification. It also warns about 422 rejections for shared mode on ad-discovery targets. 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 concise and front-loaded, stating the core purpose first. Every sentence adds value: the cost warning, the formula, and the read-back instruction. There is no filler or repetition of schema content. It is efficient for the number of parameters involved.

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 27 parameters and full schema coverage, the description is not exhaustive but covers the non-obvious interactions (billing, fan-out, constraints). It also tells the agent what to read back from the response, which is useful given there is no output schema. It could mention error handling or cancellation, but those are covered by sibling tools. It is complete enough for 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?

Schema coverage is 100%, so the schema documents each parameter. The description adds meaning beyond the schema: the fan-out formula (countries × device profiles × repeat_count), the credit billing implication, and the cross-reference to get_proxy_targeting for proxy parameters. It also clarifies referrer semantics and the repeat_mode rejection case, which are not in the schema. This is a strong addition on top of a complete schema.

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

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

The description states a specific verb and resource: 'Create a recurring scan campaign (template).' It clearly distinguishes from siblings like create_scan (one-off vs recurring) and update_campaign (create vs update). The phrase 'recurring scan campaign' and the mention of schedule types make the purpose unambiguous.

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

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

The description implies usage by contrasting with one-off scans and noting that scans cost credits only when they run. It references get_proxy_targeting and list_emulators for valid parameter values, which is a clear guideline. It doesn't explicitly state when not to use it or name alternatives, but the distinction from create_scan is implicit and sufficient for an agent to select 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 provide readOnlyHint=false, destructiveHint=false. The description adds 'Free operation, no scans queued', which provides useful behavioral context beyond annotations. 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?

Extremely concise - two clear phrases. Front-loaded with purpose. Every word is meaningful 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 simple 1-parameter tool with no output schema, the description is sufficient. It covers purpose and key behavioral traits. Could mention that a campaign group is a folder, but that is implied by the title.

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

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

Only one parameter 'name' with a description in the schema covering 100%. The tool description adds no extra parameter-specific information, so 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?

The description clearly states 'Create a new campaign group (folder)' which specifies the action and resource. It distinguishes from sibling tools like get_campaign_group, archive_campaign_group, update_campaign_group, etc.

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 explicit guidance on when to use this tool vs alternatives. The description implies usage by stating 'Free operation, no scans queued' but lacks when-not or alternative tool references.

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 mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds value by stating the action 'Create' and the return of the persisted role, and suggests assignment behavior. No contradictions. Additional context like permissions or side effects would be helpful but not mandatory 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 extremely concise, using two sentences with no redundant information. It is front-loaded with the main action and includes a clear follow-up instruction. 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 simple create tool with two parameters and no output schema, the description is largely complete. It covers the return value, next steps, and references a related tool. Minor gaps (e.g., activation timing, limits) exist but are not critical given the tool's simplicity and annotation coverage.

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

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

Schema coverage is 100% for both parameters, so the description does not need to add much. The description mentions the 'supplied permission set' and references 'list_org_roles' for examples, which is helpful but not essential. Baseline 3 is appropriate as the description adds marginal value over the schema.

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

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

The description clearly states the action ('Create'), the resource ('custom organization role'), and the key input ('supplied permission set'). It also mentions the return value and next step, distinguishing it from siblings like 'update_user_role' and 'list_org_roles'.

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 context for usage by noting that the created role should be assigned via 'update_user_role'. It implicitly tells the agent when to use this tool (when a new custom role is needed) but does not explicitly state when not to use it or list alternatives.

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 richly discloses behaviors beyond the annotations: the API auto-registers tag definitions for emitted slugs, built-in system-slug collisions return HTTP 422 with checking.system_slug_reserved, matches only future scans, and existing scans stay untouched until recheck_scans. It also explains best-effort historical matching, one-day request body retention, and resource/URL limits.

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

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

The description is long but dense and purpose-driven; nearly every sentence conveys actionable constraints or trade-offs. Some information is repeated between the main description and the schema property descriptions, but the structure is clear enough and the detail-earning content justifies the length.

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

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

For a complex create tool with no output schema and many rule types, the description covers most of the high-risk behavior: future vs existing scans, retention, request body limits, target semantics, and collision errors. It falls just short of complete because a few rule types like stopword_content, stopword_url, regexp_content, and blacklist_domain are only named and not behaviorally explained, and the response shape is not 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 coverage is 100%, so the baseline is a 3, but the description adds meaningful semantic context on top of the schema: it explains what config shapes do, the side effects of tag_slug and config.tags auto-registration, target semantics, and match_scope behavior for combo rules. This helps an agent reason about valid parameter combinations more reliably 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 opening sentence is specific: 'Define a custom tag-detection rule' names the verb, the resource, and the operation, and the rest of the description clarifies what kind of rules exist and which rule types match what. It also implicitly distinguishes itself from siblings like update_custom_rule, delete_custom_rule, and test_custom_rule by focusing on the initial creation semantics.

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 when-to-use guidance for the main rule types: use regexp_request_url for captured URLs, use regexp_request_body when filenames keep changing, and regexp_url is described as redirect-chain-only. It also gives direct advice on pitfalls, such as page-only rules missing iframe traffic and llm rules using config.tags keys instead of tag_slug.

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 (readOnlyHint=false, destructiveHint=false) already indicate it's a non-destructive mutation. The description adds important context: the taxonomy is persisted, returned with allocated UUIDs and version=1, and the default node constraint. No contradictions 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 three sentences long, each with a distinct purpose: purpose statement, constraint/guideline, and return value. No unnecessary words, well-structured, and front-loaded with the main action.

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 absence of an output schema, the description compensates by stating the return includes the taxonomy with UUIDs and version=1. It covers the creation logic, default node requirement, and tree structure. It could mention error conditions or rate limits, but for a creation tool with three parameters, 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 input schema has 100% coverage with descriptions for all properties. The description, however, adds value by explaining the tree structure and client_id/parent_client_id linking mechanism, which is not fully detailed in the schema. It also reiterates the is_default constraint in context.

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

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

The description clearly states 'Create a custom classification taxonomy with its initial tree,' specifying the verb (create), resource (taxonomy), and the concept of an initial tree. This distinguishes it from siblings like update_custom_taxonomy or delete_custom_taxonomy. The mention of a default node further clarifies the unique behavior.

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 context on when to use the tool (to create a taxonomy) and includes a critical constraint ('Exactly one node should have is_default=true'). It explains the purpose of the default node (fallback for classification). However, it does not explicitly state when not to use it or mention alternatives like parse_custom_taxonomy_text, but the sibling list implies differentiation.

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

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

Annotations declare readOnlyHint false, destructiveHint false, and idempotentHint false. The description does not contradict annotations but adds minimal behavioral context beyond listing rule types. It does not disclose any side effects, auth requirements, or return behavior.

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

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

Two sentences efficiently cover the core purpose and a key nuance (binding campaigns). No unnecessary words. Every sentence adds 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 creation tool with no output schema, the description adequately covers the input parameters and a post-creation step. It lacks return type details (likely the created policy set), which is common but could be improved. Overall, it is sufficiently complete given the tool's 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 100%, with detailed parameter descriptions. The description adds a concise summary of rule kinds, complementing the schema without redundancy. It provides a helpful overview but does not introduce entirely new information.

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 creates a new policy set (a named collection of violation rules), listing the five rule kinds. It distinguishes from sibling tools like update_policy_set and delete_policy_set by its unique 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 mentions binding campaigns via update_campaign after creation, which provides context. However, it does not explicitly state when to use or avoid this tool, nor compare it to alternatives like update_policy_set. The guidance is implied but not comprehensive.

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?

Goes well beyond the annotations by disclosing the critical side effect: this call costs credits and bills the caller's organization for every scan created. It also explains the repeat_count fan-out and the repeat_scan_ids response field, making the operation's real-world impact transparent.

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

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

Three tight, front-loaded sentences: scope first, then cost/billing behavior, then return value shape. Every sentence earns its place and there is no repetition of schema 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 complex 16-parameter tool with no output schema, the description covers the essential usage constraint, cost/fan-out behavior, and return-value shape. The fully described schema supplies the remaining per-parameter and cross-tool context, so an agent has enough to select and invoke the tool correctly.

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

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

The input schema has 100% parameter description coverage, with detailed explanations for every property including cross-tool references. The description's summary of 'one target and one country' adds no per-parameter meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

States a specific action — 'Queue a single new scan' — for a concrete resource (a URL, ad-tag, or VAST tag) and explicitly narrows it to one target and one country. It also rules out a multi-URL form, which distinguishes it from bulk scan creation.

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

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

Explicitly says this tool takes one target and one country, with no multi-URL form, and directs callers to invoke it once per URL. It does not name the bulk alternative (create_bulk_scans), but the usage condition 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?

The description discloses that the HMAC-SHA256 signing secret is returned only once and must be stored by the caller. This is a crucial behavioral trait beyond what annotations provide (readOnlyHint=false, destructiveHint=false). It does not discuss rate limits or other behaviors, but the information given is highly relevant.

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 two sentences long, front-loaded with the core action, and every word adds value. The first sentence specifies the action and scope, the second explains the critical response detail. No fluff 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?

Although there is no output schema, the description explains the response format (webhook and secret envelope) and the caller's obligation to store the secret. This covers the main output. It does not mention error handling or edge cases, but for a creation tool with four parameters, 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 100%, so the description does not need to add parameter details. The description mentions 'chosen event types' and the response envelope, which aligns with the schema. However, it does not add new meaning beyond the schema's existing descriptions.

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 registers a webhook endpoint for chosen event types, which matches the name 'Create Webhook'. It distinguishes from sibling tools like update_webhook and delete_webhook by focusing on creation and the unique response envelope.

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 (to set up a webhook) but provides no explicit guidance on when not to use or alternatives like update_webhook or rotate_webhook_secret. The context signals show many webhook-related siblings, so more guidance would help.

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

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

The description goes beyond annotations by specifying that removal is immediate and that campaign-level overrides referencing the destination are pruned. This adds concrete behavioral detail to the destructiveHint and idempotentHint 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 two sentences long, with the first sentence stating the core action and the second detailing effects. It is front-loaded and contains no unnecessary 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 simple delete tool with no output schema, the description fully explains the outcome (stops pings, prunes overrides) and side effects. No additional information is needed.

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% with a single parameter description ('Destination UUID.'). The tool description does not add further parameter information, but given the simplicity and full schema coverage, a baseline score 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 clearly states the action ('Remove an alert-notification destination') and immediately specifies the consequences ('stops receiving pings', 'overrides pruned'). This distinguishes it from siblings that list or update alert destinations.

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 indicates when to use the tool (to remove an alert destination) and explains immediate effects and side effects (pruning overrides). However, it does not explicitly mention when not to use it or compare to alternatives, but the sibling list contains no other delete-alert-destination 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?

The description adds important behavioral context beyond annotations: it notes that deletion is permanent, but already-applied tags on past scans are preserved and only future scans are affected. This aligns with the destructiveHint annotation and provides helpful detail.

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

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

Two short sentences, 18 words total. The first sentence states the action, the second adds behavioral transparency. No wasted words.

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

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

Given the tool has only one required parameter and no output schema, the description covers the action, permanence, and effect on tags/scans. It is complete for the tool's 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?

The input schema already has 100% coverage with a description for the only parameter, rule_id. The tool description does not add any further meaning or context about the parameter beyond what the schema provides. Baseline score 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 clearly states the action 'Permanently delete a custom rule', with a specific verb and resource. It distinguishes itself from sibling tools like create_custom_rule or update_custom_rule.

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 does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the action, but no guidance on context or exclusion is provided.

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 soft-delete behavior and consequences: 'Historical scan classifications keep referencing the id; new scans skip this taxonomy.' This adds significant context beyond the annotations (destructiveHint, idempotentHint) by clarifying the non-permanent effect and impact on scans.

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 concise: two sentences conveying the action, effect, and reversion. No unnecessary words, well-structured.

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

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

For a simple tool with one parameter and no output schema, the description fully explains the behavior, consequences, and undo option. It is complete and 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?

The sole parameter 'taxonomy_id' is described in the schema as 'Custom taxonomy UUID.' The description does not add further details about the parameter. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the action: 'Soft-delete a custom taxonomy (sets is_active=false).' It is specific about what happens and distinguishes from siblings like 'delete_custom_rule' and 'restore_custom_taxonomy'.

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 mentions the undo operation: 'Use `restore_custom_taxonomy` to undo.' It implies when to use this tool (to soft-delete) but does not explicitly state when not to use it or alternative scenarios. Overall, it provides adequate 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?

Adds important context beyond annotations: permanence, error condition, side effect on alerts (their policy_set_id becomes null). 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?

Each sentence adds value; front-loaded with purpose. Slightly wordy but well-structured.

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

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

Covers purpose, preconditions, error handling, workaround, and side effects – comprehensive for a delete tool.

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

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

Schema description covers the parameter ('Policy set UUID.'). The tool description adds no further semantic 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?

Starts with 'Permanently delete a policy set' – a specific verb+resource. Clarifies it's permanent and distinct from siblings like archive or cancel.

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 warns about HTTP 400 when campaigns are bound, provides a step-by-step unbinding workaround using list_campaigns and update_campaign.

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 annotations (destructiveHint=true, idempotentHint=true), the description reveals that historical tag assignments are preserved and future scans will not receive the tag, adding valuable behavioral context.

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

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

Two concise sentences: the first states the action and restriction, the second explains consequences. No superfluous 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 single-parameter delete tool without output schema, the description fully covers purpose, constraints, and effects, leaving no gaps for agent decision-making.

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 'slug' has 100% schema coverage with a clear description. The tool description adds little beyond emphasizing 'CUSTOM,' so the schema already carries the semantic load.

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 'Delete a CUSTOM tag definition' and explicitly distinguishes custom from system tags, which differentiates it from sibling tools like delete_custom_rule or archive_campaign.

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

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

It explicitly says 'System tags cannot be deleted,' providing a clear when-not-to-use condition. However, it does not mention any alternative tools for handling system tags.

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 destructive and non-readonly behavior. The description adds value by specifying that no further events are delivered, in-flight retries are dropped, and past delivery history is preserved. This goes beyond the annotations.

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

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

The description is exceptionally concise with two sentences that each add unique value without any 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 deletion tool with one parameter and no output schema, the description covers the essential effects (event delivery, retries, history preservation). It is complete enough for an agent to understand the tool's impact.

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% with a clear parameter description. The tool description does not add additional meaning beyond what the schema already provides, so a baseline score 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 clearly states the action 'Unregister a webhook endpoint' with a specific verb and resource. It also provides behavioral details about event delivery and history preservation, distinguishing it from other webhook tools like create or update.

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 lacks explicit guidance on when to use this tool versus alternatives such as updating a webhook to disable it. No when-to-use or when-not-to-use context is provided.

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 destructive (destructiveHint: true), but the description adds crucial detail: detaching is incremental (unnamed bindings survive), the policy set and rules remain intact, and existing alerts are kept. It further explains that detached campaigns stop being evaluated, so new alerts simply stop. This goes well beyond the annotation 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?

The description is compact yet information-dense. It opens with the core behavior, then gives parameter options and contrasts with siblings, and closes with side effects. Every sentence earns its place; no 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 mutation tool with no output schema, the description covers all essential aspects: what it does, incremental semantics, alternatives, and consequences for alerts. It even includes a practical tip for checking membership first. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: it clarifies the mutual exclusivity of campaign_ids and detach_all, caps campaign_ids at 500, and advises checking current membership via list_policy_set_campaigns before using detach_all. This enriches the agent's understanding of parameter usage and side effects.

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 ('Unbind campaigns') and resource ('policy set'), and explicitly differentiates from siblings: it names attach_policy_set_campaigns as the complementary operation and clarifies that update_policy_set does not touch campaigns. This makes the tool's role unmistakable even without reading 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?

It provides explicit when-to-use guidance: pass campaign_ids for specific campaigns or detach_all: true for full clearance, and warns to check membership first via list_policy_set_campaigns. It also contrasts with update_policy_set and attach_policy_set_campaigns, covering both when to use and when not to use this 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the returned fields and the purpose of confirming authentication and capturing org context, going beyond what annotations provide.

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 spans two sentences with no extraneous information. It front-loads the core functionality and follows with a usage note, achieving maximum conciseness.

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

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

Given the tool has no parameters and no output schema, the description is fully complete: it explains what the tool does, what fields are returned, and when to use it. No additional information is needed.

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%. Per guidelines, this earns a baseline of 4. The description does not need to add parameter information, but it successfully clarifies the output and usage.

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 retrieves the organization owning the current API key and lists the returned fields (id, name, owner_id, is_active, created_at). It distinguishes itself from sibling tools by being the only tool for reading account info, as siblings focus on creating, updating, or deleting entities.

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 this to confirm authentication and capture the org context for follow-up tool calls,' providing clear guidance on when to invoke this tool. The read-only, non-destructive nature is further supported by annotations, making it safe to call anytime.

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 valuable behavior: the scope of unfiltered counts ('cover the whole organization over all time') and the fact that the response buckets by status, which is not implied by the annotations. It does not describe pagination or response format, but given the annotation coverage, this is acceptable.

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

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

The description is two sentences long, with the primary purpose front-loaded. It packs a lot of context (status grouping, filter compatibility, scope, and usage guidance) into a minimal length. Every sentence adds value, and there is no redundant or filler text.

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

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

Given the tool's complexity (7 filters, no output schema), the description is remarkably complete. It explains what the tool returns (counts by status), how filters behave (same as list_alerts except status), the default scope (whole org all time), and a concrete use case (sizing before bulk_update_alert_status). Nothing critical is missing for an agent to decide to call it and understand the results.

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

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

Schema description coverage is 100%, so all 7 parameters are individually documented. The description adds a crucial semantic above the schema: it explicitly notes that the tool accepts every filter list_alerts does except status, explaining the absence of a status parameter and why (because the response is grouped by status). This extra clarity about parameter constraints is helpful and goes beyond the schema.

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

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

The description immediately states the specific function: 'Get alert counts grouped by status: open, escalated, resolved, dismissed.' It names the resource (alerts) and the output format (counts by status). It also distinguishes itself from list_alerts and references bulk_update_alert_status, making it clear what this tool is versus what it is not.

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 tells the agent when to use this tool: 'Use this to size a selection before calling bulk_update_alert_status with all_matching.' It also explains the relationship with list_alerts, noting that the same filters can be used and that counts sum to the total from list_alerts, thereby guiding the agent on when this provides value versus simply listing alerts.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by enumerating the specific fields returned (balance in micros, plan, counters, etc.), providing context beyond the annotations. No contradictions.

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 sentence that efficiently conveys the tool's purpose and key return fields without any unnecessary words 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?

Given the absence of output schema and parameters, the description provides sufficient context: it identifies the tool as a read operation, lists return fields, and implies organizational scope. No critical information is missing for an agent to invoke it correctly.

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

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

There are zero parameters; schema coverage is 100% by default. The description adds meaning by explaining what the returned data includes, meeting the baseline for a parameterless tool as per guidelines.

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 it retrieves a billing snapshot with specific fields (balance, plan, counters, suspension, scan acceptance). The verb 'get' and resource 'billing summary' are specific and distinguishable from sibling tools like 'get_usage_summary' or 'list_balance_history'.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It lacks instructions on when not to use it or comparisons to 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 and idempotentHint=true. Description adds value by detailing exact return fields, including repeat/retry settings and ad_discovery behavior.

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

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

Description is a single paragraph, front-loaded with purpose, and each sentence adds value. Slightly long but appropriate for detail.

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 tool with one parameter and no output schema, the description covers all return fields, explains the scan count formula, and handles edge cases like ad_discovery. Fully complete.

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

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

Schema coverage is 100% and describes campaign_id as UUID. Description doesn't add new semantic info beyond what the schema already provides for the 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?

The description clearly states it retrieves one campaign by UUID, lists the fields returned, and distinguishes from list_campaigns. It uses specific verbs and resources.

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

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

Explicitly says this confirms what create_campaign or update_campaign saved, providing clear context for when to use. Doesn't mention when not to use but differentiation from siblings is clear.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining the three modes ('inherit', 'override', 'silence') and their behavioral consequences (e.g., 'override' means alerts go ONLY to returned destination_ids). This goes beyond what annotations provide, though it stops short of detailing response structure.

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 two sentences with zero fluff. It fronts the main purpose and then explains the mode semantics, which are essential for interpreting the response. 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?

With no output schema, the description partially compensates by describing the mode values and referencing 'destination_ids'. For a simple one-parameter read operation with annotations covering safety, this is fairly complete, though a bit more detail on response structure would be ideal.

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

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

Schema coverage is 100% and the only parameter (campaign_id) is fully described in the schema as a UUID. The description adds nothing about the parameter itself, but since the schema already handles it, 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 states a specific verb ('Get') and resource ('per-campaign override of which alert destinations receive its alerts'), making the tool's purpose immediately clear. It also distinguishes from the sibling 'set_campaign_alert_overrides' by explicitly covering the semantics of 'mode', which clarifies what the getter returns.

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 (when you need to read the override) but doesn't explicitly say when to use this versus alternatives like 'list_alert_destinations' or the setter. There are no exclusions or alternative pointers, so guidance is only implied.

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

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

The description adds context beyond annotations by specifying the returned fields (flags and campaign count). Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. No contradictions.

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, front-loaded sentence that conveys essential information without any redundant or unnecessary 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?

The description adequately explains the tool's purpose and return data for a simple get operation. No output schema is present, but the description covers what the agent needs to know.

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 has 100% coverage: one parameter (group_id) with a description. The description adds no further meaning beyond the schema, meeting the baseline for high 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 description clearly states the action ('Get'), the resource ('campaign group'), the identifier ('by UUID'), and the specific data returned ('default/archive/pause flags and campaign count'). This fully distinguishes it from sibling tools like list_campaign_groups.

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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. However, the verb 'Get' and the resource 'campaign group by UUID' imply usage when a specific UUID is known. No explicit when-not-to guidance is given.

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. The description adds transparency about the config object's behavior for combo rules, specifically the match_scope key and its effect on updates, which is beyond the annotation metadata.

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 with no fluff. The first sentence states the core purpose, and subsequent sentences provide critical behavioral details and update guidance. Perfectly front-loaded and efficient.

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

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

Given the tool's simplicity (1 parameter, no output schema, no nested objects), the description fully covers the returned fields and special behavior for combo rules. It also links to the update tool, making it contextually complete for an agent.

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% with a single parameter rule_id that has a clear description and format. The description does not add additional semantic meaning beyond the schema, so baseline score 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 explicitly states 'Get one custom rule by UUID' with the specific fields returned, clearly distinguishing it from siblings like list_custom_rules and update_custom_rule.

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 guidance on using the returned config object when updating via update_custom_rule, warning about the match_scope key. Does not explicitly state when not to use, but the purpose is clear and usage context is well-covered.

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

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

Adds context beyond annotations by specifying the return structure (full node tree with fields like id, parent_id, level, etc.). Annotations already indicate read-only and idempotent behavior.

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

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

Single sentence, front-loaded with key information, no redundant text.

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 retrieval tool with one parameter and no output schema, the description adequately describes the purpose and return structure.

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

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

Only one parameter with schema coverage 100%. The description adds no extra meaning beyond the schema's description, but baseline is 3.

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?

Clearly states the verb 'Get' and the resource 'custom taxonomy by UUID', and distinguishes from siblings like 'list_custom_taxonomies' and 'create_custom_taxonomy'.

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?

Implies usage when needing a single taxonomy by UUID, but lacks explicit guidance on when to use vs alternatives or when not to use.

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 provide readOnlyHint, idempotentHint; description adds that return is base64-encoded and as single MCP resource content block, beyond annotation scope.

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 efficient sentences, no fluff, front-loaded with action and output format.

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?

Although no output schema, description explains return format adequately for a simple download 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?

Invoice_id description in schema references list_invoices. Description does not add new semantics but schema coverage is 100%, so baseline 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?

Clearly states the verb 'download' and specific resource 'one invoice as an inline PDF'. Distinct from siblings like list_invoices which provide metadata.

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?

Mentions agents can save/forward without a second API call, implying convenience. Does not explicitly exclude alternatives, but purpose is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context by detailing what the response contains (entries, rule kinds, country codes, is_default semantics), which goes beyond 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 primary action, then concise elaboration on return structure. No redundant words or padding; 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 simple get-by-id tool with one parameter, the description covers the key return details (entries, rule kinds, country codes, is_default). It omits other metadata like name or description, but those are likely secondary. Acceptable completeness for typical use.

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% with the parameter described as 'Policy set UUID.' The description does not add further meaning about the parameter (e.g., format constraints or default behavior). Baseline 3 applies given high 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 description clearly states the tool retrieves a single policy set by UUID and specifies the return structure: complete list of entries with five rule kinds and country codes, plus the is_default flag. This distinguishes it from list_policy_sets (retrieves many) and create/update/delete 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?

Usage is implied (use when you need a specific policy set by ID) but there is no explicit guidance contrasting it with list_policy_sets or set_default_policy_set. No exclusions or alternative selection criteria are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds rich behavior beyond that: values are dynamically sourced from the upstream provider, ordered by pool size with a 'prefer front' heuristic, residential/mobile pool separation, the country-wide default for cities when a region is omitted, and the subtle warning that mismatched region/city pairs are accepted but leave no exit node. No annotation is contradicted.

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?

Five sentences, each carrying distinct operational information: purpose, when-to-call, acceptance guarantee, ordering preference, and the two traps. The purpose is front-loaded, and the structure flows logically from what → when → how → gotchas. Nothing is repeated from the schema verbatim, and the length is justified given the real complexity of 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?

Behavioral guidance is exhaustive: sourcing, ordering, pool semantics, validation behavior, and downstream consumer tools are all covered. The only gap is the exact output shape: there is no output schema, and while the schema's reference to 'this tool's own regions array' anchors one field name, the precise structure for cities and ISPs (field names, nesting) is left implicit. For a tool with three flat parameters and strong annotations, this is a minor omission.

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

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

Schema coverage is 100% and each parameter already has a strong description (ISO format, case-insensitivity, enum with defaults, pool separation, regions-array sourcing), so the baseline is 3. The description adds genuine meaning beyond the schema: the ordering heuristic ('prefer values near the front'), the acceptance guarantee ('Anything listed here is accepted'), the two-call workflow ('if you target a region, call again with that region and take the city from that narrower list'), and the 422 consequence — all of which shape how the agent chooses values.

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

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

The opening sentence 'List the proxy regions, cities, and ISPs accepted for a country' states a specific verb, resource, and scope. The description further distinguishes this from the many sibling read tools (list_geos, list_emulators, get_scan) by naming the four consumer tools (create_scan, create_bulk_scans, create_campaign, update_campaign) that this lookup feeds, making its role unmistakable.

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

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

Gives explicit when-to-call guidance: 'Call this before setting proxy targeting on create_scan, create_bulk_scans, create_campaign, or update_campaign'. It explains why this is mandatory (values come from the upstream network provider and cannot be listed in those tools' schemas) and the failure mode of the alternative ('a guess is a 422'), effectively stating the when-not-to: never guess or hardcode values.

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, covering safety. The description adds return field context but doesn't disclose additional traits like auth requirements or rate limits. With annotations, this is satisfactory.

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 sentence, front-loaded with the action and then details. Every word adds value, with no 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?

With one required parameter, no output schema, and clear annotations, the description provides sufficient context. It lists the return fields, which is valuable without an output schema. Slightly more detail on the structure could improve it, but it's mostly complete.

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

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

Schema coverage is 100% with description for run_id (UUI). The tool description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool gets a single run by UUID and enumerates the fields returned (totals with statuses, parent campaign, label, source). This is specific and distinguishes it from sibling tools that retrieve other entities.

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—when needing a run by UUID—but provides no explicit guidance on when not to use it or alternatives. For a simple retrieval tool, this is adequate but leaves room for ambiguity.

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 mark it as read-only, idempotent, and non-destructive. The description adds value by explaining repeat/retry semantics, shared mode, and VAST video details. It warns against constructing URLs manually, providing behavioral context beyond 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 front-loaded with the main purpose but becomes lengthy explaining VAST and repeat/retry details. Every sentence adds value given the complexity, but could be slightly more concise.

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

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

No output schema exists, so the description must cover return fields completely. It does so, listing status, URLs, timing, labels, campaign, VAST specifics, and repeat/retry fields with detailed explanations. The description is comprehensive for the tool's 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?

The input schema fully describes the single parameter (scan_id as UUID, sourced from list_scans or create_scan). The description does not add new constraints or format details; it only repeats the purpose. With 100% schema coverage, this is a baseline score.

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 it retrieves full detail for a single scan by UUID, listing specific fields like status, URLs, timing, labels, and parent campaign. It distinguishes from sibling tools like list_scans (which returns a list) and get_scan_screenshot (which gets a screenshot).

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 use when full detail of a specific scan is needed, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The note about linking users with report URLs is a usage hint but not about tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe. The description adds two critical behaviors beyond annotations: 'The markup is returned inert as text and is never executed' and 'Markup over 256 KiB is refused.' These are valuable operational details that affect caller behavior (e.g., not treating output as executable) and handling of large payloads. No contradiction with annotations exists.

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

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

The description is front-loaded with the main action and then efficiently covers why to use it, limitations, and behavior. Every sentence earns its place: the first states the purpose, the second gives the use case, the third differentiates scan types, the fourth clarifies safety, and the fifth notes the size limit. No filler or repetition. It is concise despite being multi-sentence because each sentence contributes unique, actionable information.

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

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

For a single-parameter tool with no output schema, the description covers all essential aspects: what is returned (HTML markup with embedded elements), why to use it (explain tagging not visible in screenshots), scope (only ad-tag scans), behavior (inert text, never executed), and a critical limitation (256 KiB limit with fallback). The agent has everything needed to decide when to call, what to expect, and how to handle edge cases, making it contextually complete.

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

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

Schema coverage is 100%, so the parameter scan_id is already described as 'Scan UUID.' The description adds meaning beyond that by clarifying that the scan must be an ad-tag scan, not a URL or VAST scan, since only ad-tag scans have this artifact. It also implies the UUID must refer to an existing scan. This is a subtle but important constraint that helps the agent pass a valid scan_id, going beyond the schema's generic description.

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: 'Fetch the generated creative markup for an ad-tag scan as text.' It clearly states what the tool returns (scripts, iframes, click-through URLs) and differentiates from siblings by specifying that only ad-tag scans have this artifact, URL/VAST scans return not-found. This immediately distinguishes it from related tools like get_scan_screenshot or get_scan_vast_xml.

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 gives when to use the tool: 'Use it to explain WHY a creative was tagged when a screenshot cannot show it (obfuscated redirectors, hidden trackers, injected handlers).' It also gives a clear exclusion: 'Only ad-tag scans have this artifact; a URL or VAST scan returns not-found.' Additionally, it provides a fallback for large markup: 'open the report URL from get_scan.' This is concrete, actionable guidance that tells the agent exactly when to invoke this vs. alternatives.

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

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

The description goes well beyond the readOnly/idempotent annotations by revealing the return encoding (base64 WebP), the client-side decode requirement, and the specific 404 behavior when no creative exists. This is valuable behavioral context an agent cannot infer from the schema.

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

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

The description is compact and well-structured: it leads with the action and resource, then gives the encoding detail, then the error condition. Every sentence adds useful information without 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 read-only fetch tool with no output schema, the description sufficiently covers the return format, decode expectations, and failure conditions. The schema covers parameters, and the annotations cover safety, so 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?

Schema coverage is 100%, so scan_id and width are already documented. The description adds the ad-tag-scan context already present in the schema's scan_id description, but does not add meaningful new parameter-level semantics.

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

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

The description states a specific verb-resource pair: 'Fetch the creative screenshot for an ad-tag scan.' It also clarifies the output form (inline base64 WebP image) and the ad-tag-scan prerequisite, which separates it from related screenshot tools like get_scan_screenshot and get_scan_landing_screenshot.

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 indicates when the tool is appropriate: for ad-tag scans with a captured creative, and it explicitly describes when it will not work via the 404 condition. However, it does not name alternatives such as get_scan_creative_html or get_scan_screenshot for non-ad-tag scans.

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 valuable behavioral detail: only VAST scans contain the video (others return not-found), files over 8 MiB are refused rather than inlined, and it explicitly notes fallback options. This goes beyond the annotations to disclose edge cases and limitations that could affect successful 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?

The description is three sentences, no fluff, and information is front-loaded: the main action is stated first, then the constraint (only VAST), then alternatives and size limit. Every sentence earns its place with actionable guidance. There is no redundant phrasing or over-explanation.

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 read-only tool with no output schema, the description covers all essential context: what the tool returns, when it succeeds (VAST only), when it fails (non-VAST, large files), and what to use instead. The presence of sibling alternatives and fallback options makes it fully self-contained for an agent to decide when to call it.

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

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

The input schema covers the single parameter (scan_id) with a clear description 'Scan UUID' at 100% coverage. The description does not add further semantic detail about the parameter itself, but it does implicitly tie it to VAST scans. Since schema coverage is complete, a baseline of 3 is appropriate; the description adds no extra meaning beyond what the schema provides.

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 ('Fetch'), the resource ('MP4 MediaFile a VAST scan downloaded'), and the output format ('one inline resource block'). It distinguishes this tool from siblings by explicitly noting that only VAST scans have the video and that others return not-found. The purpose is unmistakable and well-differentiated from similar tools like get_scan_creative_screenshot and get_scan_vast_xml.

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 guidance on when to use this tool versus alternatives: it recommends preferring get_scan_creative_screenshot for still frames and get_scan_vast_xml for metadata, calling them 'far cheaper,' and reserves video usage for 'when the moving image is the evidence.' It also gives a clear fallback for large files, stating that files over 8 MiB are refused and directing users to use get_scan_creative_screenshot or the report URL from get_scan. This is complete usage 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?

The description discloses that the API always serves WebP and that resized screenshots are top-cropped when height exceeds 2.5x width. It warns against concluding content is absent from resized captures, which is critical behavioral context beyond the idempotent and read-only 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. The key action and format are front-loaded, followed by necessary warnings and a clear procedural pointer. Every sentence adds value, 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?

Given the tool's simplicity (3 params, no output schema), the description covers the necessary pre-requisite, the return format, the resizing caveat, and how to get the full page. Nothing essential 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?

While schema coverage is 100%, the description adds crucial meaning to the `width` parameter by explaining the cropping behavior and advising to omit it for full-page captures. It also reinforces how `landing_ord` relates to `get_scan` output, going beyond the raw schema.

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

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

The description clearly states the tool fetches a screenshot of one landing tab on an ad-tag scan as a base64-encoded inline image. It specifies the format (WebP) and distinguishes from sibling tools like get_scan_screenshot and get_scan_creative_screenshot by mentioning "landing tab on an ad-tag scan."

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

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

It explicitly instructs to call `get_scan` first to discover available `landings[*].ord` values, giving a clear before/after sequence. It also explains when to omit the `width` parameter to get the whole page, which is actionable 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?

Beyond the annotations, the description discloses the exact return format (one MCP image content block, base64 WebP) and the server-side resize/top-crop behavior. It even flags a practical caveat about long pages being top-cropped. This strongly helps an agent predict tool behavior and is consistent with the readOnlyHint and idempotentHint 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 concise and front-loaded: purpose, output format, and primary usage tip appear in two efficient sentences. The additional width caveat lives in the schema where it belongs, keeping the main description readable without losing critical 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 read-only, two-parameter tool, the definition is complete: required input, optional behavior, return format, and an important interpretation caveat are all covered. The lack of an output schema is mitigated by explicitly stating the one MCP image content block. The only minor omission is an explicit routing note about sibling screenshot tools, but the primary/creative/landing naming makes that clear enough.

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 already documents both parameters thoroughly, including the width range and crop behavior. The main description adds limited parameter-specific meaning beyond the schema, mostly repeating the width intent. With 100% schema description coverage, a 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 states a specific verb and resource: 'Fetch the primary screenshot for a scan'. It also identifies the output format, an inline base64-encoded WebP image, making the tool's purpose concrete. The word 'primary' differentiates it from sibling screenshot tools like get_scan_creative_screenshot and get_scan_landing_screenshot.

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 guidance on when to use optional width: pass it for a smaller server-resized image, and omit it when the whole page is needed. It also warns against concluding content is absent from a resized capture. However, it does not explicitly contrast this tool with screenshot siblings such as creative or landing screenshot tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behaviors beyond that: wrappers are resolved, documents over 256 KiB are refused, and non-VAST scans return not-found. This gives the agent realistic expectations about content and failure modes without contradicting 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?

Every sentence earns its place: the primary action, the usage rationale, the alternative, the applicability restriction, and the size limit. It is front-loaded with the main purpose and avoids any fluff. The length is justified by the rich content.

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

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

With a single parameter, no output schema, and a text return value, the description sufficiently covers what is returned (VAST document as text), the resolution of wrappers, the size cap, and the not-found case. It also directs the agent to get_scan for a summary, covering the relationship between tools. 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 coverage is 100%, so the schema already documents scan_id as 'Scan UUID.' The description does not add any syntax, format, or constraint details beyond that. It mentions 'VAST scan' as context but this is not parameter-specific semantics. Baseline 3 is appropriate since the schema carries the full burden.

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 ('Fetch'), a precise resource ('the VAST document for a VAST scan as text'), and a key differentiator ('wrappers already resolved so the whole chain is visible in one payload'). It distinguishes itself from siblings like get_scan by explicitly contrasting its full element tree with get_scan's parsed summary. No ambiguity about what it 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?

Explicitly states when to use it: to inspect tracking pixels, verification vendors, companion ads, and click-through targets. It names the alternative (get_scan) and exactly what that alternative covers (duration, media file, ad system), making the choice unambiguous. It also notes that only VAST scans have this artifact, guiding the agent on applicability.

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 safety profile is covered. The description adds useful edge-case behavior: returns 404 for archived tags the org does not own, including every archived system tag. This goes beyond structured annotations without contradicting 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, information-dense paragraph with no filler. Each part earns its place: field enumeration, cross-reference, and a 404 edge case. It is slightly long but still front-loaded and readable.

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

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

With no output schema, the description compensates by enumerating the return fields and the linked_rules shape. It also covers an important error case and a relevant sibling route. For a one-parameter read-only tool, this is complete.

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

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

Schema coverage is 100% and the slug parameter already has a clear description with examples. The tool description adds no further parameter-level detail, so baseline 3 is appropriate.

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

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

The description uses a specific verb and resource, 'Get full definition of one tag,' and enumerates the exact fields returned. It distinguishes itself from siblings by being tag-level rather than rule-level and explicitly points to get_custom_rule for rule config.

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 when to use this tool (full tag definition) and explicitly directs rule-config needs to get_custom_rule. It does not mention list_tags, but the single-tag scope and alternative reference provide adequate usage 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 declare the tool as read-only, idempotent, and non-destructive. The description adds context that the output is a one-liner aggregate, but does not disclose any behavioral traits beyond what annotations provide (e.g., no mention of handling empty usage or error conditions). It adds some value but not rich behavioral context.

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

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

The description is a single sentence that immediately states the purpose and lists the return fields. Every word adds value, and there is no extraneous information. It is ideally concise and 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 the tool's simplicity (zero parameters, no output schema), the description is fully complete. It explicitly states what data is returned, and no additional context (e.g., error behavior) is necessary for a read-only aggregate query. The annotations further assure the agent of safe 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?

The tool has no parameters, so the description does not need to explain them. Schema coverage is 100%, and the description correctly implies no inputs are required. This exceeds the baseline for zero-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?

The description clearly specifies the action ('Get'), the resource ('usage summary'), and the scope ('current billing period'), along with the exact fields returned (total cost in micros, check count, period start/end). This fully distinguishes it from siblings like 'get_billing_summary' or 'list_usage'.

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 it is for a quick aggregate view via the phrase 'one-liner aggregate', but it does not explicitly state when to use this tool versus alternatives like 'list_usage' or 'get_billing_summary'. No exclusions or alternative suggestions are provided.

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 provide readOnlyHint=true and idempotentHint=true; description adds return field details (URL, event types, active flag) beyond annotations. No contradictions.

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 of 12 words, front-loaded with verb and resource, no wasted words.

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

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

Simple read tool with full annotation coverage; description adequately explains what is returned, compensating for lack of output schema.

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

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

Schema coverage is 100% and parameter description is clear; description adds little beyond schema for the webhook_id parameter, only reiterating 'by UUID'.

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 clearly states verb 'Get one webhook endpoint by UUID' and specifies returned fields (URL, subscribed event types, active flag), distinguishing it from sibling tools like list_webhooks.

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?

Description implies usage for retrieving a single webhook by UUID, but does not explicitly contrast with alternatives like list_webhooks or provide when-not guidance. Context makes it 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 indicate non-read-only, non-destructive, and non-idempotent. Description adds that it sends an email and returns a pending member record, which is useful beyond annotations. Could mention idempotency or rate limits.

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

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

Two sentences, no fluff, front-loaded with the action. Every sentence adds 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?

The description explains the return value (pending member record) since there is no output schema. Covers the tool's purpose and parameters adequately for its 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?

All four parameters are described in the input schema (100% coverage). The description adds helpful hints: 'They get a signup link' for email and 'Get UUIDs from list_org_roles' for role_id, enhancing understanding.

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

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

Clearly states the action (send invitation email), the target resource (new person joining organization), and the return value (pending member record). Distinguishes from siblings like 'remove_user' and 'update_user_role'.

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

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

Implies usage for inviting a new user to the organization, but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. No mention of prerequisites or conditions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it returns custom label definitions at the organization level, which is useful context but does not reveal any surprising behaviors beyond what annotations imply.

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 with front-loaded verb phrase. Every sentence adds value: first states the action and output fields, second explains the purpose and connection to list_scans. No wasted words.

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

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

For a zero-parameter tool with no output schema and clear annotations, the description is complete. It explains what is listed, the fields, and how labels are used, providing sufficient context for an agent 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?

Tool has no parameters (schema coverage 100%), so description does not need to add parameter info. The description lists the fields returned, which provides meaning beyond the empty schema. Baseline for 0 params is 4.

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 clearly states the tool lists organization's custom label definitions and enumerates the fields (key, display_name, position, auto_extract). It differentiates from siblings like update_account_labels and list_scans by specifying the listing behavior and the use of labels as filters.

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 explains that labels enrich scans and can be used as filters in list_scans, providing context for when to use this tool. It does not explicitly state when not to use alternatives, but the purpose is clear enough for a simple list operation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds content information (return fields) but no further behavioral traits such as pagination, limits, or authentication requirements. With annotations covering safety, the description is adequate but adds little beyond what is evident.

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: first states purpose and scope, second details output fields. No filler, every sentence adds 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 simple list tool with no parameters and no output schema, the description fully covers what is returned and the nature of the resource. No missing 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 and 100% schema coverage (none). Baseline is 4 per guidelines. Description adds value by describing the return fields, which helps the agent understand the output.

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 specifies exactly what the tool does: list configured alert-notification destinations (channels) with explicit types (Slack, Telegram, etc.) and field details. Clearly distinguishes from sibling tools like delete_alert_destination or set_alert_destination_version.

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 (to view destinations) but does not explicitly contrast with alternatives or state when not to use it. Since the tool is simple and has no parameters, the lack of explicit guidance is acceptable but not optimal.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), which aligns with the non-mutating 'List' verb. The description adds value beyond annotations by disclosing the dedup rule, the kind-aware rule_type values, and the filter behavior. No contradiction; annotation_contradiction=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?

One information-dense sentence delivers the return fields, dedup rule, filter list, OR-match semantics, and the stats relationship with no filler. It is front-loaded with the return semantics. It is dense enough that a line break or two would aid readability, but nothing is wasted.

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

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

With no output schema, the description correctly carries the return-value burden by enumerating the fields (offer URL, country, status, scan back-reference, rule_type, matched_value) and the dedup semantics. Filters and pagination are covered by a fully-documented schema. Together they give an agent 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?

Schema coverage is 100%, so the baseline is 3 because the schema already documents all 10 parameters with defaults and enum meanings. The description earns a 4 by adding semantics beyond the schema: the dedup definition, the kind-aware field context, and the OR-match behavior for comma-separated values. It also points out the cross-tool filter relationship with get_alert_stats.

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 precise verb+resource ('List violation alerts') and enriches it with the dedup semantics ('one per scan + violating rule combo') and the exact returned fields (offer URL, country, status, scan back-reference, rule_type, matched_value). This distinguishes it clearly from the sibling get_alert_stats, which is about aggregates rather than the alert list itself.

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

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

Gives clear actionable context: it explains that the same filters passed to get_alert_stats yield agreeing counts, which routes the agent between list vs. stats tools. It also explains the OR-match semantics of comma-separated filters. It stops short of an explicit 'use X instead when…' exclusion, 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, establishing safety. The description adds crucial context that 'The full secret is NEVER returned' – an important behavioral constraint beyond annotations. No contradictions.

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: first sentence clearly states what the tool lists, second sentence adds a critical behavioral warning. No wasted words, front-loaded with purpose.

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?

Despite no output schema, the description lists the fields returned. For a simple parameterless list tool, this is complete. All necessary context is 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?

Input schema has 0 parameters, so schema description coverage is 100%. Baseline for zero parameters is 4. Description does not need to explain parameters.

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 clearly states 'List the organization's API keys' and enumerates returned fields (id, key prefix, display name, etc.). Verb 'List' and resource 'API keys' are specific, and sibling tools (create_api_key, revoke_api_key) differentiate this as a read-only operation.

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 explicit when-to-use or when-not-to-use guidance is provided. The description implies this tool is for listing keys and notes that the full secret is not available, but does not mention alternatives such as create_api_key for creation or revoke_api_key for revocation.

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, closed-world), so the bar is lower. The description adds real behavioral content beyond them: the shape of each returned row (type, amount, description, timestamp) and the crucial unit detail that amounts are in micros. Pagination ordering and default sort are not disclosed, keeping it short of a 5.

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

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

Two sentences, front-loaded with the resource identified first and the filters second. No filler, no restatement 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?

With no output schema present, the description compensates by describing the returned row fields and the micros unit, which is exactly what an agent needs to interpret results. Filtering is fully covered by the schema. Ordering/pagination behavior is the only material omission.

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

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

Schema description coverage is 100% and the schema itself documents page/limit bounds, ISO date inclusivity and the enum semantics including OR-ing and the signed adjustment caveat. The description's mention of multi-select type and date range merely restates the schema, adding nothing new.

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 ('ledger transactions ... on the organization's balance') and enumerates the transaction kinds covered. It does not explicitly contrast itself with nearby siblings such as list_invoices or get_billing_summary, so an agent must infer the boundary, but the resource is named precisely enough to be usable.

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 tells how to narrow results ('Filter by `type` (multi-select) and / or date range') but never says when this tool is preferred over list_invoices, list_usage or get_billing_summary. Usage is implied by the resource rather than stated as a decision rule.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds meaningful behavior: the list is not paginated (all groups returned at once) and the org-scoped list is small. It also explains the semantics of last_run_at (newest run across its campaigns), which is not derivable from annotations. This gives the agent a solid mental model of the tool's behavior.

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

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

The description is two sentences. The first sentence states the action and key returned fields. The second covers filters, the special meaning of last run, and the non-pagination/size note. Every sentence earns its place, and the most important info 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?

There is no output schema, so the description must convey the return shape. It does state per-group campaign count and last_run_at, which is a useful sketch. It also addresses potential concerns like pagination and list size. It doesn't mention sorting or other fields, but for a read-only list tool that is typically small, this is adequate. Slightly more detail on return fields would push it to a 5.

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

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

Schema coverage is 100% so baseline is 3, but the description adds value beyond the schema by explaining what 'last run' means in the context of last_run_from/last_run_to filters. It also summarizes the filter groups (archived flag, name substring, date ranges) in one concise phrase. This extra semantic context justifies a 4.

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

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

The description states the verb 'List' and the resource 'campaign groups', then defines what a campaign group is ('folders that group related campaigns') and what it returns (per-group campaign count and last_run_at). This clearly distinguishes it from listing campaigns or getting a single group, so the purpose is unambiguous and well-scoped.

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 usage context: what it lists, the available filters, and the note that the list is not paginated and typically small. However, it does not explicitly contrast with siblings like get_campaign_group (for a single group) or list_campaigns (for campaigns). Since the tool name and description make the resource type clear, it earns a 4 for context without explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'per-run counters' and 'paginated', providing context beyond annotations without 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?

Single sentence, front-loaded, with no unnecessary words. Efficiently conveys purpose and key characteristics.

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?

Adequate for a simple list tool with 3 parameters and full annotations. Missing details like return format, but counters imply some data shape. Sufficient for agent to select and invoke correctly.

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

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

Schema coverage is 100%, so parameters are well-documented. Description adds 'paginated' and 'per-run counters' but does not enhance parameter meaning beyond schema defaults.

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?

Clearly states 'List every run...of one campaign, paginated, with per-run counters.' Specifies verb, resource, and additional details that distinguish from sibling tools like 'list_run_scans'.

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