toffu

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that content is Meta-sourced diagnostic aggregates, but says nothing about latency, whether data is cached or freshly queried from Meta, or partial-failure behavior for account connections.

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

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

One dense sentence with no filler, and the most important content (account health / opportunity score) is front-loaded. The lack of a leading verb makes it read as a label list, 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?

An output schema exists and the input schema is fully documented, so return values and parameters need no explanation in prose. What is missing is operational context: prerequisites for the Meta account connection, whether sections are independently expensive, and when this diagnostic should be preferred over querying campaign performance.

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%: both `sections` (with the valid enum list and the default excluding ab_tests) and `account_id` override are fully documented in the schema. The description adds no parameter-level detail beyond restating the same section names, so the baseline 3 applies.

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

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

The description enumerates exactly what the tool returns: opportunity score with ranked recommendations, pixel EMQ diagnostics, catalog diagnostics, and A/B test results. It is clearly a read-only Meta ad account diagnostic, distinguishable from siblings like query_campaign_performance or get_account_context. It lacks an explicit verb ('returns'/'fetches'), which keeps it from a 5.

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

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

There is no statement of when to use this tool versus alternatives such as query_campaign_performance, get_account_context, or creative_report, and no exclusions or prerequisites. The only usage signal is implicit in the section names, so the agent must infer routing from the sibling list.

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

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

Annotations already declare destructive, non-idempotent, non-read-only behavior. The description adds important context beyond annotations: user confirmation is required, server-side budget hard-limits still apply, and the result includes whether the change can be undone.

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

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

Three short sentences, front-loaded with the action and confirmation gate, then the operational constraint and return behavior. No wasted 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 destructive execution tool with an output schema and rich annotations, the description covers the key workflow gate, hard limits, and undoability signal. It leaves some failure-mode behavior unspecified, but is largely complete 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?

With one parameter and 0% schema description coverage, the description partially compensates by explaining that the proposal comes from a propose_* tool. However, it does not explicitly say to pass the proposal_id returned by that tool or clarify identifier format.

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

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

The description states a specific verb and resource: execute a proposal produced by any propose_* tool. It distinguishes this tool from the propose_* family by framing it as the execution step after user confirmation.

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

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

It explicitly says to use this after the user confirms a proposal from any propose_* tool, which is a clear workflow gate. It does not explicitly name undo_change as the reversal route, so the alternative is only implied by the mention of undoability.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context that it returns creative details and a specific set of metrics, but does not disclose pagination, rate limits, or result size behavior beyond the limit param. With annotations covering safety, a 3 is appropriate.

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

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

A single, front-loaded sentence that efficiently lists the key creative fields and metrics. The metric list is long but each item is informative and earns its place. No redundant sentences.

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

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

Given the output schema exists, the description need not explain return values, and it clearly states the granularity (per creative) and metrics. The main gap is the lack of explicit usage guidance versus query_campaign_performance, but the description is otherwise complete for a read-only reporting 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 all five parameters are fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 ('report') and resource ('Meta Ads performance per CREATIVE'), and lists the exact creative fields and metrics returned. It implicitly distinguishes from campaign-level siblings via 'per CREATIVE', but does not explicitly name or contrast with query_campaign_performance.

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

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

No guidance on when to use this tool versus alternatives like query_campaign_performance, nor any prerequisites or exclusions. The only usage hint is that results are sorted by spend, which is 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that the return is account-scoped rules plus KB docs, skills and ad accounts, but it says nothing about size, latency, whether absent rules are omitted, or how the 'skills' parameter changes the payload — behavior beyond the annotation is only partially disclosed.

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

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

A single front-loaded sentence opening with the verb and resource, with the parenthetical list kept tight. The enumeration is long but each item is informative, so there is little waste; it is not quite maximally crisp.

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 an output schema present, the description need not explain return values, and annotations cover the safety profile, so the remaining burden is scope and routing. Scope is well covered; the only real gap is the missing when-to-use guidance relative to the many sibling tools.

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 one optional parameter with 100% schema description coverage ('skill names whose full content to include'), so the schema carries the semantics. The description mentions skills only as part of the returned contents and does not clarify the default (null) behavior or the cost of requesting full skill content, so it adds essentially nothing beyond the schema.

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

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

States a specific verb ('Returns') and resource ('this company's account context') and then enumerates the contents: standing rules (conversion events, funnel sources, targets, currency, scope), knowledge-base sheets/docs, skills, and connected ad accounts. Against siblings like query_campaign_performance or the propose_* family, an agent can tell this is the read-only configuration/context fetch without opening the schema.

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

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

Usage is only implied: the description suggests this is the setup/grounding call, but it never says when to call it (e.g., before analysis or before proposing changes) or when to prefer query_campaign_performance or account_health instead. No exclusions or prerequisites are 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?

Beyond the readOnly/non-destructive annotations, the description adds useful behavioral context: this is a polling tool and should be repeated until status='done'. It does not explain what happens on failure or timeout, but the output schema covers return values.

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, front-loaded with the purpose and immediately followed by the polling instruction. Every sentence earns its place with no redundant restatement of the name or title.

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

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

For a simple one-parameter polling tool with annotations and an output schema, the description covers the essential usage pattern and cadence. The main remaining gap is explicit guidance on sourcing the session_id and handling non-'done' terminal states.

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 required parameter session_id has 0% schema description coverage and is not explicitly explained in the description. The description implies the session comes from a send_message call, but it does not state that session_id is the value to pass or where to obtain 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 states a specific action (collect the answer) tied to a specific originating call (send_message that returned status='working'). It clearly distinguishes this from the sibling send_message tool, though the phrasing 'answer' is slightly less precise than 'result'.

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

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

It gives an explicit trigger condition (after send_message returns status='working') and polling guidance (~every 30s until status='done'). It does not mention failure/timeout cases or alternatives, so it is clear but not fully exhaustive.

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, openWorldHint=true, so 'Read-only' in the description is redundant. The only added context is the single-platform scope, which is mild value; nothing about pagination, result caps, or cross-platform auth is disclosed.

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, front-loaded and scannable. The 'Read-only' sentence is redundant against annotations and slightly dilutes the value per sentence, preventing a 5.

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

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

Output schema exists and the input schema is fully documented, so the description needn't explain returns or params. However, for a cross-platform listing tool with 5 parameters and an open-world hint, it could note that the platform must already be connected and that results may require paging.

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 already documents platform enum values, ad_set_id requirements for Microsoft Ads, and account_id semantics for DV360. The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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

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

Clear specific verb+resource ('List ads') and adds scoping ('on one connected ad platform'). Distinguishes itself from siblings like list_campaigns and list_ad_sets by resource name, though it never states that relationship explicitly.

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

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

No guidance on when to use this versus list_campaigns/list_ad_sets or how to drill down. An agent must infer that ads are the leaf level of the hierarchy.

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=false and openWorldHint=true, so the explicit 'Read-only' restates structured data. The real added value is the semantic disclosure of what an 'ad set' maps to per platform, which tells the agent what the returned entities look like conceptually. No pagination, rate-limit, or result-volume 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 sentences, front-loaded with the verb and scope, no filler. The second sentence is dense but every clause resolves a real ambiguity an agent would hit when switching platforms.

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?

An output schema exists so return values needn't be explained, and annotations fully cover the safety profile. The description's job here is concept normalization, which it does thoroughly; only minor gaps (pagination or result-size behavior for large accounts) remain.

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 carries its own description, including the enum-like platform list and the account_id caveat (DV360 advertiser, Outbrain marketer). The description adds nothing parameter-specific beyond reinforcing single-platform scope, so baseline 3 applies.

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

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

States a specific verb (List) and resource (ad sets) plus the constraint that it operates on one connected ad platform. The terminology mapping ('Ad set = Meta ad set, Google... ad group, X or DV360 line item, LinkedIn campaign') makes the resource unambiguous across all supported platforms, which no sibling tool does.

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

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

The 'one connected ad platform' scoping plus the hierarchy-normalization sentence gives the agent a clear context: use this to enumerate the mid-level entities under a campaign for a single platform, versus list_campaigns (above) or list_ads (below). It stops short of explicitly naming those alternatives or stating 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=false and openWorldHint, so 'Read-only' adds nothing. What the description does contribute is the single-platform scoping constraint and a hint at the returned fields, which is modest added context, with no mention of pagination or result 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 short sentences, front-loaded with the core action and capped by the safety note. 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?

An output schema exists so return values need not be explained, and all three parameters are documented. Only minor gaps remain, such as pagination behavior and what an empty result means.

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

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

Schema description coverage is 100%, so platform, account_id and filters are already explained well (including DV360/Outbrain account mapping). The description adds no filter syntax or semantics beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb and resource ('List campaigns') plus the returned fields (ids, names, status) and the scope ('one connected ad platform'). It distinguishes itself implicitly from list_ads/list_ad_sets by naming campaigns, but never explicitly routes away from query_campaign_performance.

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

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

Usage is only implied: you list campaigns on a chosen platform. There is no statement of when to prefer this over query_campaign_performance (metrics) or get_account_context, and no exclusions or prerequisites are 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 destructiveHint=false and openWorldHint=true, so the safety profile is partly covered, but readOnlyHint=false leaves ambiguity about whether this mutates state. The description resolves that by clarifying it only stages for review and 'Does NOT create anything', which is genuinely additive. It still omits permissions, idempotency behavior, and what staging produces (covered by the output schema), so it is not 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 short sentences with the primary action front-loaded and the key non-behavioral fact ('Does NOT create anything') immediately after. No filler or repetition.

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

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

With a 100% covered schema and an output schema present, the description needn't explain parameters or return values, and it correctly clarifies the non-creation semantics. However, for a propose-stage tool the critical missing context is the follow-up path (what applies the staged test, whether approval is needed), which the agent cannot derive from the structured fields alone.

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 each parameter already carries rich inline documentation (date constraints, cell structure, percent defaults, account override). The description adds nothing about parameters, so the baseline of 3 for a fully documented schema 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 names a specific verb and resource ('Stage a Meta A/B test (split test)') and adds the scope qualifier 'for review', so an agent understands this is a proposal operation. It stops short of naming the sibling that would execute the test (apply_change), so differentiation is implied rather than explicit.

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

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

There is no explicit when-to-use guidance, no when-not guidance, and no named alternative such as apply_change or propose_change. 'Stage for review' hints at a propose-then-apply workflow, but the agent must infer which sibling commits the staged test.

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 the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds substantively beyond them: no execution occurs, a proposal_id plus current→new diff is returned, proposals expire in 1h, and the human-confirmation gate before apply. This is rich behavioral context the annotations cannot convey.

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

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

The non-execution and workflow constraints are front-loaded, and every line adds needed information given the 0% schema coverage. It is dense, but the density is warranted rather than redundant.

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

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

Despite an output schema existing, the description still surfaces the return contract (proposal_id + diff preview) and the lifecycle (1h expiry), and covers all operation field semantics. An agent has everything needed to build a valid proposal and route to apply_change 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 0% with a single loosely-typed 'operations' array, so the description carries the full burden and does so: it defines platform values, level values with the ad_set→Google-ad-group mapping and campaign default, object_id meaning, account_id purpose, and per-platform constraints (daily_budget only for Meta campaign/ad set or Google campaign; ads take status only), plus the MAJOR-unit currency caveat.

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 (stage/propose) and resource (campaign changes) and immediately bounds the scope with 'Does NOT execute anything', which cleanly separates it from the apply_change sibling. An agent can distinguish propose from apply without opening any schema.

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

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

Gives explicit workflow routing: 'Show the preview to the user; call apply_change(proposal_id) only after they confirm.' This names the alternative tool and the exact condition that selects it, plus the 1h expiry constraint. Nothing is left to inference.

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

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

Annotations mark readOnlyHint=false and destructiveHint=false, which alone leaves an agent guessing whether a call mutates the ad account. The description resolves this by declaring no account change, naming the return value (proposal_id plus preview), and prescribing the follow-up apply_change step.

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

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

Three short sentences, front-loaded with the non-mutation guarantee and the required confirmation flow; nothing is repeated or 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?

An output schema exists, so the brief return-value mention suffices. The one minor gap is that the schema less-than-obvious path for unknown/missing fields returning a schema is only documented in the nested field description, not reinforced here.

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

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

Schema description coverage is 100%, including platform-specific mapping notes for ad_set_id, account_id, and campaign_id, so the description adds no parameter meaning. Baseline 3 applies.

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

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

States a specific verb and resource ('Stage a new ad') and immediately contrasts it with the real mutation path ('Does NOT change the account'), which cleanly separates it from apply_change and the propose_update_* 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?

Gives explicit sequencing guidance: show the preview, then call apply_change(proposal_id) only after user confirmation. It doesn't say when to pick this over propose_change or propose_create_campaign, but the staging workflow it describes is unambiguous.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety bar is lower. The description still adds real substance: it discloses that no account change occurs, that the return carries a proposal_id plus preview, and that a human confirmation gate precedes apply_change — the key behavioral trait an agent could otherwise get wrong. Minor tension with readOnlyHint=false is resolved by the staging semantics, but it is worth noting the tool is not literally read-only.

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

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

Three sentences, front-loaded with the core action, then the safety gate, then the cross-platform disambiguation. Every sentence earns its place and there is no filler.

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

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

With an output schema, full parameter coverage, and annotations in place, the description supplies exactly the missing pieces: the proposal/preview lifecycle, the confirmation gate, and the platform vocabulary needed to fill fields correctly. An agent has everything required to pick this tool and invoke it safely.

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

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

Schema description coverage is 100%, so the schema already documents platform enum, fields payload, account_id aliasing (DV360 advertiser, Outbrain marketer), and campaign_id. The description adds conceptual clarity about what an 'ad set' maps to per platform, which aids field construction, but it adds no parameter-level syntax or format guidance beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Stage a new ad set') and immediately fixes the tool's place in the lifecycle by contrasting it with account mutation and with apply_change. The cross-platform mapping sentence is unusually valuable: it tells the agent that 'ad set' covers Meta ad sets, Google/TikTok ad groups, X/DV360 line items, and LinkedIn campaigns, which is exactly the ambiguity that would otherwise push an agent toward propose_create_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?

Gives an explicit workflow: stage, show the preview, and call apply_change(proposal_id) only after user confirmation. That is a clear when-to-use and when-not-to-proceed rule. It stops short of explicitly contrasting with propose_update_ad_set or propose_create_ad/campaign, so sibling routing is mostly implied by the terminology sentence rather than stated.

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

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

Annotations say readOnlyHint=false and destructiveHint=false but leave the agent guessing what 'not read-only but not destructive' means. The description resolves that precisely: no account change occurs, a proposal_id and preview are returned, and mutation happens only via apply_change. It also discloses the platform-dependent pausing 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, front-loaded with the action and its key constraint, followed by the return value and the follow-up procedure. No filler and no repetition of the title.

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

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

There is an output schema, yet the description still flags the two return values an agent must act on (proposal_id, preview). Combined with the confirmation workflow, nothing needed to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so platform, fields, and account_id are already documented in the schema, including the currency-unit convention and the unknown-field fallback. The description adds no parameter-specific guidance, so the baseline 3 applies.

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

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

States a specific verb+resource ('Stage a new campaign') and immediately clarifies the scope ('paused where the platform allows'). It is clearly distinguishable from siblings like propose_create_ad_set and propose_update_campaign, and from apply_change, which it names explicitly.

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

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

Gives explicit routing: call this to stage, then 'call apply_change(proposal_id) only after the user confirms.' The when-to-use and the when-to-escalate-to-a-sibling are both spelled out, along with the required user-confirmation gate.

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 real value beyond the annotations: it explains why destructiveHint=false (this call is non-destructive; permanence happens on apply), states the account is not mutated, and names the return value. That said, the annotations already flag non-readOnly/non-idempotent, and the description doesn't cover rate limits, auth, or failure modes, so it sits at a solid but not exceptional level.

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

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

Four short sentences, each carrying a distinct fact (staging, permanence, non-mutation/return, confirmation gate), with the effect front-loaded. Nothing is padded.

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

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

The output schema covers return values, and the description still names proposal_id and the preview so the agent knows what to surface. Combined with the confirmation gate and permanence warning, an agent has everything needed to call this correctly without risking an unconfirmed deletion.

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 platform, entity_id, account_id and campaign_id are all documented in the schema, including the Taboola campaign_id:item_id format. The description adds no parameter-level guidance, so the baseline 3 applies.

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

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

"Stage deleting an ad" gives a specific verb (stage) plus resource (ad), and the word "stage" immediately separates it from siblings propose_delete_ad_set/propose_delete_campaign and from propose_update_ad. An agent knows exactly which sibling to pick without opening a schema.

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

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

It prescribes the full workflow: show the preview, then call apply_change(proposal_id) only after user confirmation. It also warns that applying is permanent, which is the key when-to-use condition. Alternative tools are named explicitly.

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 that the operation only stages a change, that applying is permanent, and that the account is not modified. Annotations only give readOnlyHint=false and destructiveHint=false, so the staging-vs-applying distinction and the permanence warning are meaningful additions the agent would otherwise have to guess.

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

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

Four short sentences with zero filler, front-loaded with the action and the non-mutation guarantee, followed by the confirmation workflow. 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?

Complete for a staging tool: it covers what it does, what it does not do, what it returns (proposal_id and preview), and the required follow-up call. With an output schema present and full param coverage, no further detail 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%, so platform, entity_id, account_id and campaign_id are all documented in the schema, including the Taboola and DV360 platform-specific caveats. The description adds no parameter semantics of its own beyond the returned proposal_id, so the baseline 3 applies.

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

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

States a specific verb and resource ('Stage deleting an ad set') and immediately scopes what it does not do ('Does NOT change the account'). This cleanly separates it from siblings apply_change, undo_change and the other propose_* tools.

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

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

Explicitly sequences the workflow: show the preview, then call apply_change(proposal_id) only after the user confirms. It names the alternative tool and the condition that gates the transition, leaving nothing to inference.

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

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

Adds real context beyond annotations: the operation is a staging step whose application is permanent, the account is not mutated, and the return includes a preview the agent should surface. This is consistent with destructiveHint=false (the proposal itself is not destructive) and readOnlyHint=false (a proposal is created), but the description could say more about whether a proposal expires or can be replaced.

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

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

Three short sentences, front-loaded with the core action and the safety-critical constraint ('applying it is permanent') before the follow-up workflow. 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 staged-mutation tool with an output schema, the description covers everything the agent needs: intent, non-mutation of the account, return shape, and the confirmation gate for apply_change. A minor gap is guidance on what happens if a proposal is never applied or re-proposed, but that is peripheral.

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 platform enum list, entity_id format (Taboola campaign_id:item_id), and account_id requirements are already fully documented. The description adds nothing about parameters beyond the returned proposal_id, 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?

States a specific verb+resource ('Stage deleting a campaign') and immediately clarifies scope: it does not change the account, it returns a proposal_id and preview. This distinguishes it cleanly from apply_change, which is the sibling that actually performs the deletion.

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 an explicit workflow rule: show the preview and call apply_change(proposal_id) only after the user confirms. That is actionable sequencing guidance, though it does not explicitly exclude or compare against alternative staging tools like propose_update_campaign or propose_delete_ad_set.

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

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

The description adds important behavior beyond the annotations: the tool does not mutate the ad account, it returns a proposal_id and preview, and the proposal should only be applied after user confirmation. These details are central to using a non-destructive staging tool correctly and are consistent with destructiveHint=false and idempotentHint=false.

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

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

The description is three compact sentences, front-loads the staging behavior, and every sentence adds actionable information about non-mutation, return values, and confirmation workflow.

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 rich schema, existing output schema, and annotations, the description provides the remaining context an agent needs: this is a staging tool, it returns a preview/proposal_id, and apply_change is the follow-up only after confirmation. No critical usage detail appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents platform, entity_id, fields, account_id, and campaign_id in detail. The description adds no parameter-specific meaning beyond the workflow, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Stage a change to an existing ad.' It clearly distinguishes this from apply_change by saying it does not change the account and only returns a proposal/preview, and it implicitly distinguishes from propose_create_ad/propose_delete_ad through 'existing ad' and 'change.'

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

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

It gives explicit workflow guidance: stage the change, show the preview, and call apply_change(proposal_id) only after user confirmation. This tells the agent both when to use this tool and which sibling to use next, with a clear confirmation gate.

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=false with destructiveHint=false, and the description explains the resulting semantics that matter: staging only, no account change, a proposal_id plus preview returned, and a human-confirmation gate before apply_change. That is precisely the behavioral context an agent needs to avoid treating this as an immediate mutation.

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, both earning their place, with the non-mutation constraint front-loaded before the follow-up workflow instruction. 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?

Output schema exists and the description still names the two things an agent will act on (proposal_id and preview). Rich param coverage plus the description's confirmation-gate warning makes the definition complete for a 5-parameter proposal 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 platform enums, entity_id, account_id and campaign_id semantics are fully documented in the schema, including the nested fields object and its currency note. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource ("Stage a change to an existing ad set") and immediately clarifies the scope: it does not mutate the account but produces a proposal_id and preview. This separates it from the mutating sibling apply_change and from the generic propose_change without needing to open either schema.

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

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

Gives explicit sequencing and a gating condition: show the preview, then call apply_change(proposal_id) only after the user confirms. It does not explicitly say when to prefer this over the generic propose_change sibling, which keeps it short of a 5, but the workflow guidance is unambiguous.

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

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

Adds real context beyond the annotations: it does not mutate the account, it returns a proposal_id plus a preview, and it is a human-in-the-loop step. It does not mention that repeat calls are non-idempotent (annotations flag idempotentHint=false) and produce multiple proposals, which would be a useful caveat.

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

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

Three short sentences, front-loaded with the action and its non-mutating nature, then the follow-up workflow. No filler and nothing repeated from the schema.

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

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

An output schema and full parameter documentation carry most of the load, and the description covers the non-mutating behavior and confirmation flow. The only gap is the duplicate-proposal risk from non-idempotent calls, which matters for a staging 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 platform, entity_id, account_id, and fields are already documented, including platform enum values and the fields semantics. The description adds nothing further about parameters, so the baseline 3 applies.

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

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

States a specific verb and resource ('Stage a change to an existing campaign') and draws the key line against apply_change by saying it does not modify the account. It doesn't address how it differs from the similarly named propose_change sibling, which an agent working from names alone might confuse it with.

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

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

Gives an explicit workflow: stage here, show the preview, and call apply_change(proposal_id) only after user confirmation. That names the alternative tool and the condition that gates the switch, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely useful context that results are merged and normalized across heterogeneous platforms into one table, but says nothing about latency, row volumes, or partial-connection 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?

One front-loaded sentence with the key fact (all platforms, normalized table) stated first. The 16-name platform enumeration partially duplicates the schema's platform id list, which is mild bloat, but it does signal full coverage at a glance.

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 an output schema present, rich 100%-covered input schema, and safety annotations, the description doesn't need to explain return values or field meanings. The remaining gap is routing guidance versus sibling reporting tools, which is a minor omission for a read-only query.

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 every parameter is documented in the schema, so the schema carries the semantics. The description adds no parameter-level meaning beyond noting the cross-platform merge; baseline 3 applies.

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

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

States a specific resource and scope: campaign performance across all connected ad platforms merged into one normalized table. It's clear what it returns, but it doesn't contrast itself with nearby reporting siblings like creative_report or account_health, so an agent must infer the boundary.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative named. The 'ALL platforms' emphasis implies it is the broad reporting call, but the description never says when to prefer creative_report or account_health instead.

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 beyond the annotations by scoping what cannot be mutated and by disclosing that proposed changes come back as drafts and that long tasks emit progress before the final answer. Annotations only give readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the 'returns drafts, mutates nothing' framing resolves real ambiguity. It stops short of covering auth needs, cost or latency expectations.

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

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

Front-loaded with purpose, then constraints, then the alternative routing, then async behavior — every sentence carries information. The parenthetical list of propose_*/apply_* names is slightly dense but functional; nothing is padded.

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

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

For a two-parameter, open-world agent task tool with an output schema, the description covers purpose, mutation boundary, alternatives and async completion. Session semantics live in the schema, so nothing critical is missing; only operational details like latency or rate expectations are absent.

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

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

Schema description coverage is 100% and both parameters (message, session_id) are already documented in the schema, including the session continuation rule. The description adds no additional meaning about the parameters, so the baseline 3 applies.

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

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

States a specific verb and resource: hands a task to Toffu, the company's AI marketing agent, for analysis, reports and drafts. It also distinguishes itself from the many propose_*/apply_change siblings by naming them as the route for actual changes.

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 frames the use case (analysis, reports, drafts) and the exclusion (no changes to ad accounts, content channels, messages or Toffu settings), then routes the agent to propose_*/apply_change or propose_write/apply_write when a change is wanted. That is direct when-to-use/when-not/alternative 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?

Goes well beyond the annotations: the annotations only say destructive/non-idempotent, while the description adds the 24-hour expiry and the write-conflict guard, plus the rationale (reverting would overwrite someone else's change). That directly explains the failure mode an agent will hit.

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, the core action front-loaded, followed by the two constraints that govern success. 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?

An output schema exists so return values need no explanation, and annotations already declare the destructive/non-idempotent profile. The description supplies exactly the missing pieces – expiry and the precondition check – leaving nothing essential unstated.

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

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

Schema description coverage is 0% and the single parameter is only implied by the phrase 'applied proposal', so the description does convey that proposal_id must reference a previously applied proposal. It adds nothing about identifier format or how to obtain one, which is the main gap at 0% 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?

Specific verb (revert) plus a precise resource (an applied proposal) and the exact target state (values read just before it was applied). An agent can distinguish it from apply_change and the propose_* family without opening any schema.

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

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

Gives a concrete usage window (24h after apply) and an explicit refusal condition (refused if the objects no longer hold what that apply wrote). It stops short of naming an alternative when undo is refused (e.g., re-propose via propose_change), so it is clear but not fully routing.

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