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

Annotations already declare readOnlyHint=false, so the agent knows this mutates state; the description correctly reinforces that with 'start tracking.' It adds the reason for tracking but omits whether the operation is idempotent, what happens if the brand is already tracked, or whether it replaces an existing tracked brand.

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

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

A single front-loaded sentence with no filler, and the purpose clause is placed after the action. It is arguably under-specified rather than verbose, but nothing in it 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 parameters, no output schema, and annotations covering only the write hint, the description carries the remaining burden. It does not explain persistence, the relationship to get_my_brand/clear_my_brand, or what state changes after the call, leaving gaps for a state-mutating 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?

There are zero parameters, and schema coverage is reported at 100%, so there is no parameter semantics gap for the description to fill. The baseline for a zero-parameter tool 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 states a specific verb and resource ('start tracking a brand') plus the downstream payoff ('explore its ads'), so the action is unambiguous. However, it does not distinguish itself from adjacent siblings such as save_my_brand or search_brands, leaving the agent to infer which one actually registers a tracked brand.

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 clause 'so you can explore its ads' implies this is a prerequisite step before ad-exploration tools like get_brand_ads, which is useful implied usage. But there is no explicit when-to-use statement, no exclusion, and no named alternative versus save_my_brand or clear_my_brand.

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 readOnlyHint=false annotation already tells the agent this is a mutation, so the description adds little. It does specify the platform is Google, but it omits which campaign is affected, how keywords are supplied, reversibility, and permission requirements — significant gaps for a write operation.

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

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

A single front-loaded sentence with no filler, which is good, but it is under-specified rather than concise — the brevity comes at the cost of telling the agent what the tool actually operates on.

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, no usable parameter definitions, and only a readOnlyHint, the description carries most of the burden and carries it poorly. It lacks the campaign identifier, keyword input format, and any result expectations an agent needs to call this 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?

Parameter count is zero, which normally earns a baseline 4, but the schema is an open bag (additionalProperties: true) with no declared properties or descriptions — the agent must guess the payload shape. The description does nothing to clarify what keys (keywords, campaign id) should be passed, so it cannot claim the clean zero-param baseline.

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 conveys the outcome (prevent a Google campaign from showing on unwanted searches) but never names the mechanism — negative keywords — or states a verb+resource pairing like 'add negative keywords to a campaign.' An agent can infer the intent from the tool name, but the description itself is oblique.

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 siblings such as update_keywords, research_keywords, or create_ad_group, and no stated preconditions (campaign must exist, account must be connected). The agent gets no routing signal at all.

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

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

Annotations only declare readOnlyHint=false, so the description must carry the rest. It implies persistence but says nothing about scope (which brand/account the product attaches to), duplicate handling, required prior context, or what happens on success. The phrase "from its product page" adds a small amount of source context but no behavioral depth.

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

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

A single front-loaded sentence with no filler; the verb and object come first and nothing is repeated from the title. There is 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 zero-parameter tool with no output schema, the description covers the basic idea but leaves the core operational question unanswered: how the specific product is identified or scoped if nothing is passed. It is minimally adequate rather than 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?

With zero declared parameters the baseline is 4, but the description names fields ("name, price and photos") that do not appear anywhere in the schema, which declares no properties and allows additionalProperties. That hint is useful but sits in tension with the schema rather than clarifying 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 gives a concrete verb and resource ("Save ... your products") and distinguishes the product object from the sibling add_brand/save_my_brand tools. It is clear what the tool acts on, though it never explains the mechanism by which a product is selected, since the schema declares no parameters.

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 list_my_products, remove_product, or add_brand, and no prerequisites or exclusions. "From its product page" hints at context but does not tell an agent under what conditions to call it.

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

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

Annotations only supply readOnlyHint=false, and the description usefully adds that approval is the trigger for video production. It says nothing about reversibility, what happens if the item was already approved, or what state the caller must already be in. With no declared parameters, it is also silent on how the target script is identified.

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 action front-loaded. The second sentence largely restates the first, adding emphasis rather than new information, which costs it a point but keeps the definition scannable.

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

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

For a no-parameter, no-output-schema mutation tool, the description covers the core effect but leaves gaps: how the target video is scoped, whether approval is idempotent or reversible, and what the caller gets back. Adequate but not complete for an approval gate.

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?

Zero declared parameters, so there is no schema-level parameter documentation to compensate for; baseline 4 applies. The lax additionalProperties:true isn't addressed, but the description has no real parameter surface to explain.

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

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

States a specific verb (approve) and resource (a video script / video), and the phrase 'so the video gets made' clarifies the gate role that separates it from siblings like check_video_status or revise_video_brief. Minor wobble between 'video' in the name and 'video script' in the description, but the intent is 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?

Implies the usage context ('Nothing is made until you approve') so an agent can infer this comes after script generation and before production. However, no sibling tool is named and no explicit when-not condition is given, so the agent must infer the sequencing itself.

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, so the safety profile is covered. The description adds that the tool targets an in-flight generation job and can yield the finished video, but says nothing about what is returned when the video is still rendering, whether polling is expected, or how long it may take.

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 short sentence with no padding, and the check-then-fetch behavior is front-loaded. It is efficient, though it is arguably too terse for the amount of ambiguity it leaves.

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 status/polling tool with no output schema and no annotations beyond readOnlyHint, the description should explain readiness states, error conditions, and the identity of the video being checked. None of that is present, leaving the agent unable to call it confidently.

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 zero declared parameters the baseline would be 4, but the description implies the tool operates on one specific in-progress video ad without any described mechanism for selecting it, which leaves a meaningful semantic gap the schema does not close (additionalProperties is true).

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 verb+resource ('check on a video ad', 'get the finished video'), so the intent is identifiable, but it never says how the target video is identified and does not distinguish itself from siblings like clone_video_ad, list_my_creatives, or approve_video_clone.

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 guidance on when to call this versus polling alternatives such as list_my_creatives or approve_video_clone, nor any stated precondition (e.g. that a video generation must have been started first). Usage must be inferred entirely from the sentence.

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?

This is a delete/reset operation and annotations only declare readOnlyHint=false, with no destructiveHint. The description says 'Remove' but never discloses whether the action is reversible, whether brand-associated assets (products, ads, creatives) are also affected, or whether confirmation is required. For a destructive tool with minimal annotations, this leaves the key behavioral risk undisclosed.

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 short sentence with zero filler, front-loading the action. Appropriately sized for a no-argument tool, though it could have spent that brevity budget on a risk note.

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-param tool with no output schema, the definition is minimally adequate to invoke correctly, but the omission of any irreversibility or data-loss warning is a real gap for a destructive reset operation.

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

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

Zero parameters, so there is nothing for the description to document. Baseline 4 applies; no compensation is needed.

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 (Remove) and resource (your saved brand) plus a hint of scope (start over). An agent can tell it apart from get_my_brand and save_my_brand by the verb alone, though it never explicitly names those siblings.

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

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

The clause 'so you can start over with a different one' implies the use case (resetting to configure a new brand), but no explicit when/when-not or alternative is named. Given the close sibling save_my_brand, a routing statement would have been valuable.

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

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

Annotations only declare readOnlyHint=false, so the description carries the burden of behavioral disclosure and adds almost none. It does not say that this is a mutating operation, what it produces, whether it consumes credits, or what must already exist before calling it. With an empty schema this leaves the tool's actual behavior opaque.

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

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

A single front-loaded sentence with no filler or redundancy. It is, however, so short that it omits information an agent needs, which is a completeness problem rather than a verbosity one.

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 mutating clone operation with no output schema, an empty object schema, and a permissive additionalProperties, the description is not complete: it omits required prerequisites and the mechanism for identifying the source ad. The agent cannot determine how to invoke this correctly from the description 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?

The tool declares zero parameters, so per the rubric the baseline is 4; there is no parameter surface for the description to add meaning to. Note that additionalProperties=true means the real invocation contract (how the target ad or competitor is identified) is undocumented in both schema and 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?

States a specific verb (rebuild/clone) and a specific resource (a competitor's image ad) scoped to the caller's own brand and product. The 'image ad' qualifier distinguishes it from sibling clone_video_ad and clone_tiktok_ad, though it does not clarify its relationship to clone_from_script or clone_from_concept.

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

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

There is no when-to-use guidance beyond the name itself: no statement of prerequisites (e.g., a saved brand via save_my_brand, a product via add_product, or a prior competitor ad lookup), and no explicit routing against the other clone_* siblings. The agent must infer the trigger condition entirely.

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 supply only readOnlyHint=false, so the description carries most of the behavioral burden. It confirms a generative write but says nothing about the surrounding flow that siblings check_video_status and approve_video_clone imply (async job, approval step, credit/cost, or what happens if the idea is under-specified).

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

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

A single front-loaded sentence with no filler; the action and the input type both land immediately. It is efficient rather than padded, though it is terse enough that it reads as light specification.

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

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

With no output schema and only a readOnlyHint annotation, the description covers the core call but omits the process context an agent needs to sequence this correctly (long-running generation, status polling, approval). Adequate for the single invocation, incomplete for the workflow it starts.

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?

Zero declared parameters, so the baseline is 4. The schema is free-form (additionalProperties: true) and the description usefully clarifies that the expected payload is a plain-English idea, reconciling the empty schema with how the tool is actually invoked.

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 ("Make a video ad") plus the input modality ("from an idea described in plain English"), which implicitly separates it from clone_from_script and clone_video_ad. It never names the sibling it is distinguished from, so the agent must infer the boundary rather than read it.

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: "from an idea described in plain English" tells the agent the required starting material but not when to prefer this over clone_from_script or clone_video_ad. No when-not conditions, prerequisites, or named alternatives 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?

With only readOnlyHint=false in the annotations, the description carries the full behavioral burden and does not meet it. It says nothing about this being an asynchronous generation job, expected latency or cost, what artifact is produced, or that sibling tools like check_video_status and approve_video_clone are likely the follow-up steps.

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 short sentence with the action and input source front-loaded and no filler. Slightly generic marketing phrasing ('for your brand') costs it the top score 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?

For a generative, mutating tool with no output schema, no documented parameters, and thin annotations, the description omits the async workflow, result handling, and where the script is supplied. An agent cannot call this correctly without guessing.

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?

Parameter count is zero, which normally sets a baseline of 4, but the schema is an open object with additionalProperties=true and no declared properties while the description implies a 'script' input. The mismatch leaves the agent unsure how to actually supply the script, so the baseline is reduced.

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 ('Make a video ad') and the input source ('from a script you wrote'), which meaningfully distinguishes it from clone_from_concept and clone_tiktok_ad. It does not, however, name any sibling or clarify how it differs from clone_video_ad or clone_ad, which look close in scope.

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 the many adjacent cloning tools (clone_ad, clone_video_ad, clone_tiktok_ad, clone_from_concept). The phrase 'from a script you wrote' only faintly implies the required input; no conditions, prerequisites, or exclusions 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?

The readOnlyHint=true annotation covers the safety profile, and the description usefully clarifies the artifact produced ('shot-by-shot script you can film yourself'). It does not say how the source ad is selected, whether the result is persisted, or any auth/rate behavior, so it adds modest value over the annotation.

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

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

One tight sentence, front-loaded with the input (TikTok ad) and the output (shot-by-shot script), with no filler. Every clause earns its place.

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

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

The description explains what comes out but not what goes in or how the source ad is identified, which matters because the schema declares no parameters while additionalProperties is open. With no output schema, the description is the only source of return-shape context and it is thin, though adequate for a simple generation tool.

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

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

The tool takes zero parameters, so there is nothing for the description to document; the baseline for a 0-param tool applies. No parameter-level detail is expected or missing.

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 transformation: a TikTok ad in, a shot-by-shot script for the user's own product out. That verb+resource pairing is clear. However, it never distinguishes this from the many clone_* siblings (clone_ad, clone_video_ad, clone_from_script), which an agent will have to disambiguate on its own.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the closely related clone_ad / clone_video_ad / clone_from_concept tools. With five-plus clone variants in the sibling set, the absence of routing guidance is a real gap.

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

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

Annotations only declare readOnlyHint=false, so the description carries the disclosure burden. It usefully reveals a human-in-the-loop step ("You review the script first"), which implies a draft-then-approve flow, but it omits what the call actually produces (job id, script artifact), whether an approval step is required, and any auth or rate-limit notes.

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

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

Two tight sentences, front-loaded with the core action and followed by the key workflow constraint. No filler, and each sentence carries distinct 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 multi-step clone-and-review pipeline with no output schema and no documented parameters, the description should connect to the surrounding lifecycle tools (approve_video_clone, revise_video_brief, check_video_status, launch_cloned_ad). It gestures at the review step but leaves the agent guessing about what is returned and what the next call should be.

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

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

The schema is an open object with zero declared properties (additionalProperties: true), so there is no schema-level parameter documentation to lean on. The description compensates by naming the kinds of source input expected (competitor ad, reel, TikTok, own video), which is meaningful guidance for an otherwise free-form input, though it does not specify format (URL vs. asset id).

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

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

States a specific verb (write/clone) and resource (video ad) and enumerates acceptable source material (competitor ad, reel, TikTok, own video). It is clear on its own, but does not differentiate itself from close siblings like clone_tiktok_ad, clone_ad, or clone_from_concept, whose boundaries are left ambiguous.

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 or routing versus the many clone_* alternatives (clone_ad, clone_tiktok_ad, clone_from_script, clone_from_concept). The only process hint is "You review the script first," which implies a workflow but does not tell the agent when this tool is the right choice.

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 readOnlyHint annotation already tells the agent this is a safe read, so the bar is lower. The description adds one real behavioral constraint — 'two or more brands' as a minimum arity — but says nothing about what the comparison covers, how brands are identified, or what comes back.

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

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

A single front-loaded sentence with no filler, and the key constraint (two or more brands) appears immediately. It is efficient, though arguably under-specified rather than genuinely 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?

For a zero-parameter tool with no output schema, the description carries the entire burden of explaining input shape and result content, and it does neither. An agent cannot tell how to pass brands or what a 'comparison' returns.

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 zero declared properties, the baseline is 4. The description is the only hint about inputs, implying at least two brand identifiers must be supplied, but it does not explain the argument form for a schema that simply accepts additionalProperties.

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 ('Compare the advertising of two or more brands side by side'), so an agent knows the operation is a read-only multi-brand comparison. It does not distinguish itself from siblings such as find_competitors, search_brands, or get_brand_ads, which are adjacent in purpose.

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

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

There is no guidance on when to choose this tool versus alternatives like find_competitors or get_brand_ads, nor any precondition (e.g., brands must already be saved via save_my_brand/add_brand). Usage is only implied by the name.

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?

readOnlyHint=false signals this is not a plain read, yet the description frames it as 'Get a link', which could mislead an agent into treating it as a pure read. It adds the useful detail that the output is a link and names the platforms, but does not explain that this initiates an OAuth-style connect flow requiring user interaction, nor what the link represents. With annotations present the bar is lower, so 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 with no filler. The platform list is the only elaboration and it is directly relevant.

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 0-parameter tool with no output schema, the description covers what an agent needs to call it correctly and confirms the return is a link. It could be stronger by clarifying this is the entry point of the connect flow versus list_ad_accounts (which shows accounts already linked).

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing in the schema for the description to add or compensate for.

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 ('Get a link to connect your own ad account') and names the supported platforms (Meta, Google, TikTok, X, ChatGPT Ads). It is clear what the tool does, but it does not differentiate itself from adjacent siblings like list_ad_accounts or inspect_ad_account.

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

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

Usage is implied (use this when you want to connect an ad account) but there is no explicit when-to-use versus alternatives, no note about the relationship to list_ad_accounts/inspect_ad_account, and no prerequisites such as an existing auth session.

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

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

Annotations only supply readOnlyHint=false, so the description still carries most of the burden. It does not say whether this is purely additive, whether it needs a connected ad account, or what side effects occur on the parent campaign.

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

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

It is a single short sentence, but the 'or more ads' clause introduces ambiguity rather than value, so brevity comes at the cost of precision.

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 an empty parameter schema, no output schema, and only a readOnlyHint, the agent is left without any indication of how the ad group is specified or what is returned. The description does not fill that gap.

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

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

The schema declares zero parameters, so there is no parameter semantics to document; baseline for a 0-param tool is 4. The description adds nothing here, but nothing is required of it.

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

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

States a verb and resource ('Add an ad group'), which matches the title and readOnlyHint=false. However the trailing 'or more ads' muddies what the tool actually creates, and it offers no differentiation from siblings like launch_campaign or launch_meta_ad.

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?

'to a campaign you already have' hints at a prerequisite (an existing campaign), but there is no explicit when-to-use guidance and no alternative named among the many launch_* 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 only supply readOnlyHint=false, confirming this is a write operation, which the verb 'Create' already implies. The description adds nothing about required inputs, whether creation is synchronous, whether it needs a connected Meta ad account, or whether the new audience is immediately usable in campaigns.

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

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

A single efficient sentence with the action front-loaded and no filler. It is appropriately sized for the sparse information it carries.

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 write tool with no output schema and an open-ended parameter object, the description should say what inputs are required and what the result is. Instead it only gives illustrative examples, so an agent cannot reliably construct a valid call.

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

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

The declared schema has zero parameters, but additionalProperties=true means the tool actually accepts undocumented inputs. The description's examples ('website visitors', 'people similar to your customers') hint at an audience-type concept but never name the required fields (name, source, retention, lookalike ratio), leaving the real input contract opaque.

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 ('Create an audience') plus the account scope ('in your Meta account') and two concrete examples of audience kinds. It is clear and distinguishing, though there are no audience-focused siblings to differentiate from.

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

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

There is no when-to-use guidance, no prerequisites (e.g. ad account connection, minimum audience size), and no mention of alternatives such as reusing an existing audience. The examples describe audience types but do not tell the agent when this tool is the right call.

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

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

readOnlyHint=true already covers the safety profile. The description adds two behavioral traits beyond annotations: results are scoped to brands currently advertising, and they are sorted by ad volume. It says nothing about result count, pagination, or what fields come back, so the added value is modest.

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 tight sentence with no wasted words, front-loading the resource ('brands in your space') before the ranking behavior. Nothing could be cut without losing meaning.

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

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

With no parameters, no output schema, and a readOnly annotation, the main remaining question is what the agent receives. The description characterizes the return set (competitor brands ranked by ad count) adequately, though it omits result volume/limits and any notion of how 'your space' is determined.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Per the rubric, a parameterless tool sits at the baseline of 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?

States a specific verb and resource ('find the brands... that are advertising') plus the ranking criterion (by ad volume), which is far more than a restatement of the name. It implicitly separates itself from search_brands (broad brand search), but never names a sibling explicitly, so sibling differentiation is left to inference.

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

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

The phrase 'in your space that are advertising right now' implies the discovery/competitive-research use case, but there is no explicit when-to-use, no when-not-to-use, and no pointer to alternatives such as search_brands or compare_brands. Usage must be inferred.

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, so the agent knows this is a non-mutating read, and 'Get a written brief' is consistent with that. However, the description adds almost nothing beyond the annotation: it does not say whether this triggers a costly generation, how long it takes, or what the brief contains. With annotations carrying the safety profile, this is the minimum 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification for a generative tool.

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

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

With no output schema, the description is the only source of return-value information, and 'written brief on ad strategy' gives a coarse but usable sense of the output. It omits how the target brand is determined and whether a saved brand is a prerequisite, which matters given the adjacent get_my_brand/save_my_brand 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?

The tool takes zero parameters, which normally sets a baseline of 4, but the description's phrase 'one brand's' implies a brand selector or at least a scope decision that the empty schema does not resolve. It never explains whether the brand comes from saved state (get_my_brand/save_my_brand) or is chosen some other way, so the zero-param baseline is not fully earned.

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 concrete verb-plus-resource: producing a written brief on one brand's ad strategy. It is distinguishable from data-retrieval siblings like get_brand_stats or get_brand_ads, since it yields prose analysis rather than raw numbers. It stops short of explicitly contrasting itself with adjacent tools such as compare_brands or revise_video_brief.

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

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

The description gives no when-to-use guidance, no prerequisites, and names no alternatives among the many siblings. An agent cannot tell from the text whether to call this instead of get_brand_stats, compare_brands, or revise_video_brief.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the useful detail that values are 'real' account metrics (spend, clicks, conversions), but says nothing about time range, granularity, or scope of the returned data.

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

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

A single front-loaded sentence with the metric list up front and no filler. Efficient, though extremely terse for the scope it covers.

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-param read tool with no output schema, the description names the metrics but leaves the temporal scope unexplained -- 'real spend' over what window is ambiguous with no date parameter available. Adequate but incomplete given the missing output schema.

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

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

The tool takes zero parameters, so per the rubric this defaults to a 4. There is nothing for the description to clarify beyond confirming the no-argument nature.

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 ('See ... from your connected ad account') and enumerates the returned metrics (real spend, clicks, conversions). It is clear what the tool does, though it does not distinguish itself from nearby siblings like get_brand_stats or get_account_performance-style stats tools.

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

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

The description offers no when-to-use guidance, no prerequisites, and no alternatives. With siblings such as get_brand_stats, get_brand_ads, and list_ad_accounts in the same space, the agent gets no signal on when this tool wins over those.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description usefully adds what the result contains (hook, format, copy, run duration) in the absence of an output schema. It does not disclose whether results are scoped to the saved brand, whether pagination or result limits apply, or any rate-limit 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?

A single tight sentence with the resource first and the useful return detail trailing, no filler and nothing redundant with the title.

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

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

For a read-only, parameterless tool with no output schema, the description covers the return shape reasonably but omits the crucial operational fact of which brand is queried and how to change it. An agent can invoke it, but cannot predict its scope or routing relative to search_ads.

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

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

The schema has zero parameters, so per the baseline there is nothing for the description to clarify. The one relevant semantic gap is that the implicit brand context (how the 'brand' is resolved with no argument) is left unstated, which slightly undercuts an otherwise clean 0-param case.

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 ('See a brand's ads') and even enumerates the payload ('hook, format, copy and how long each one has been running'). It does not differentiate itself from plausible siblings such as search_ads or research_tiktok_ads, so the agent must infer which ad-listing tool to choose.

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

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

There is no when-to-use guidance, no statement of alternatives, and no prerequisite named. Given the tool takes zero parameters, the agent is never told that it presumably operates on the brand already saved via save_my_brand/get_my_brand, which is essential context for calling it sensibly.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description does not need to restate safety. It adds the useful fact that the result is aggregated (counts, format breakdown, duration) rather than a raw listing, but says nothing about scope, time window, or result size.

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 15-word sentence with the core action front-loaded and the colon-delimited payload spelled out immediately after. No filler and nothing repeated from 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 and no parameters, the description is the only source of truth, and it covers the return shape reasonably well. It leaves open which brand is summarized and what reporting window or scope the stats cover, which is a real gap for a zero-argument tool.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to compensate for; baseline 4 applies. The description correctly does not invent or describe nonexistent inputs.

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

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

Specific verb and resource ('Get a summary of a brand's advertising') plus the concrete contents of that summary (ad count, formats, run duration), so an agent knows exactly what comes back. It stops short of 5 because it never distinguishes itself from siblings like get_brand_ads or compare_brands, and does not clarify whose brand (the zero-parameter schema implies the caller's own brand, but the description says 'a brand's').

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 when-to-use guidance, no exclusions, and no mention of the closely related siblings (get_brand_ads for individual ads, compare_brands for cross-brand comparison). The agent must infer the placement from the name alone.

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, so safety is covered. The description adds that posts and reels are both included, which is useful content-type context. However, it says nothing about recency window, result limits, pagination, or whether a brand must be selected first.

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 short sentence with no filler, front-loading the action and the resource. Every word earns its place.

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

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

For a simple read-only tool with annotations and no output schema, the description covers what is returned (posts and reels). It is still thin on operational detail such as recency bounds, volume, and brand binding, which an agent would need to call it confidently.

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

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

With 0 defined parameters, the baseline is 4, but the description refers to 'a brand's' posts while the schema defines no brand parameter (additionalProperties: true). That mismatch mildly muddies how the tool is scoped and leaves the brand selector unspecified.

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 ('See a brand's recent Instagram posts and reels'), naming the content types returned. It does not explicitly differentiate from siblings like get_brand_ads or get_brand_stats, but no sibling covers Instagram content, so it is reasonably distinguishable.

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 when-to-use guidance, no prerequisites, and no alternatives named (e.g., when to use this vs get_brand_ads or research_tiktok_ads). The word 'recent' implies scope but does not tell the agent when this tool is the right choice.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the bar is lower. The description adds that the returned value is the previously saved brand, but says nothing about what happens when no brand has been saved (empty state) or about any auth/account scoping.

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

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

A single front-loaded sentence with no filler; the core action leads and the rationale follows. Efficient for a trivial zero-argument tool.

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

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

For a zero-parameter, read-only getter with no output schema, the description is sufficient to call it correctly. Only gap is the unaddressed empty/no-saved-brand case.

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

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

The tool takes zero parameters, so the baseline of 4 applies. Nothing is encoded in the schema that the description needs to compensate for.

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 ('Show') plus resource ('the brand you saved'), which is enough to separate it from save_my_brand and clear_my_brand in the sibling cluster. The trailing purpose clause ('so research and ads are tailored') names the concrete downstream use, though it doesn't explicitly call out the sibling alternatives.

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 guidance and no reference to the obvious alternatives (save_my_brand, clear_my_brand). The purpose clause implies the result is consumed by research/ads tools, but that is motivation, not selection guidance.

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

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

The readOnlyHint annotation already establishes this is a safe, non-mutating call, so the description only needs to add context. It hints at a readiness verdict but never says what 'ready' means, what conditions are checked, or what a negative result implies, leaving the behavioral picture thin.

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 short sentence that front-loads the action and the resource. There is no filler or redundancy.

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

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

With no output schema, the description carries the burden of explaining the return concept, and 'ready to run ads' is only vaguely defined. For a zero-parameter read check it is adequate, but an agent still cannot tell what the result will look like or how to act on 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 tool takes zero parameters, so there is nothing for the description to clarify beyond what the schema already conveys; the baseline for a parameterless tool 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?

The description states a specific verb ('check') and resource ('connected ad account') plus the intent ('ready to run ads'), which is far more informative than the title alone. It does not explicitly contrast itself with siblings like list_ad_accounts or connect_ad_account, so sibling differentiation is left implicit.

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 'ready to run ads' phrasing suggests calling this before launching campaigns, but there is no statement of when to prefer this over list_ad_accounts or connect_ad_account, and no 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 only declare readOnlyHint=false, so the description carries most of the burden. It usefully discloses two behavioral facts: the campaign is created in a paused state and requires preview confirmation. It does not say whether an ad account must already be connected (a sibling, connect_ad_account, suggests that prerequisite) or what happens on failure.

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 no filler; the core action is front-loaded and the paused/preview caveat follows immediately. Every clause earns its place.

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

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

For a zero-parameter mutation tool with no output schema, the description covers the basic lifecycle state (starts paused) but omits account prerequisites and output expectations. It is minimally adequate rather than complete.

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

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

The tool takes zero declared parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The empty schema has additionalProperties=true, which the description does not address, but with no named parameters there is no semantics gap to compensate for.

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

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

Names a specific verb ('Create') and resource ('a new campaign') plus the target scope ('your connected ad account'), so the action is unambiguous. However, it does nothing to separate itself from the many channel-specific siblings (launch_meta_ad, launch_search_campaign, launch_pmax_campaign, launch_tiktok_campaign), leaving the agent to guess when the generic tool applies.

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 clause 'after you confirm a preview' implies a prerequisite workflow step, which is more than most definitions offer. But there is no explicit when-to-use versus the other launch_* tools, and no stated exclusions or conditions for picking the generic launcher over a channel-specific one.

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?

Only readOnlyHint=false is annotated, so the description carries the disclosure burden well: it reveals that the ad 'starts paused' and requires confirming a preview. This post-launch state and the preview-gate workflow step are valuable context beyond the annotation, though permission or error behavior is not covered.

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

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

Two tight sentences with zero filler, and the most decision-relevant fact (what gets launched and where) is front-loaded ahead of the behavioral note about the paused state.

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

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

For a no-parameter mutation tool with no output schema, the description covers the action, target platforms, and the key behavioral outcome (starts paused after preview confirmation). Only the absence of an explicit alternative-tool reference keeps it short of complete.

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

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

The tool takes zero defined parameters (additionalProperties is open), so there is no parameter surface for the description to explain. Baseline of 4 applies; the description correctly adds no redundant parameter detail.

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

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

States a specific verb+resource (launch a cloned image ad) and names the destination platforms (Facebook and Instagram). It narrows the scope to cloned image ads, which separates it from clone_video_ad and launch_meta_ad, but it never explicitly contrasts itself with the closely-named launch_meta_ad sibling.

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

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

The phrase 'an image ad you cloned' implicitly establishes the prerequisite that a clone must already exist, but there is no explicit when-to-use guidance or naming of alternatives such as launch_meta_ad or launch_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?

With readOnlyHint=false already declaring a write operation, the description adds real behavioral value beyond annotations: the ad starts in a paused state and requires preview confirmation before going live. This tells the agent the operation is safe-by-default and has a confirmation gate, though it omits auth requirements and which ad account/campaign the ad attaches to.

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

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

Two tight sentences, front-loaded with the core action and immediately followed by the key behavioral caveat (starts paused, needs confirmation). No filler, though the brevity is close to under-specification for a launch tool.

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

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

For a low-complexity, zero-parameter tool with no output schema, the description covers the essentials (what it does, paused default, confirmation step). It leaves notable gaps: where the 'your own images or videos' come from when no parameters exist, and which ad account or destination the ad lands in.

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?

Zero parameters, so the baseline is 4. The description mentions 'your own images or videos', which hints at media inputs, but the empty schema with additionalProperties=true means parameter semantics are not really a factor here.

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

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

States a specific verb and resource (Launch + Facebook/Instagram ad), and the phrase 'your own images or videos' implicitly distinguishes it from clone-based siblings like launch_cloned_ad. However it does not explicitly name which sibling to prefer over launch_campaign or launch_pmax_campaign, leaving that differentiation to inference.

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

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

The description implies usage context (you supply your own media rather than cloning) and notes the workflow (starts paused after preview confirmation), but never states when this tool should be chosen over launch_campaign, launch_pmax_campaign, or launch_cloned_ad. Usage is implied rather than explicit.

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

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

The annotations only declare readOnlyHint=false. The description does add two genuinely useful behavioral facts beyond that: the campaign starts paused (so it is not immediately live) and a preview confirmation is a precondition. It says nothing about required account authorization, prerequisites such as connect_ad_account, or what happens if account/brand is unset, which matters for a tool with no parameters.

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 action front-loaded and the key caveat (starts paused, preview confirmation) immediately after. No filler, nothing 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?

With no output schema, no meaningful annotations beyond readOnlyHint=false, and no parameters, the description carries most of the burden. It covers the critical behavioral caveats (paused start, preview confirmation) but leaves open which campaign/account is launched and whether ad-account connection is a prerequisite, which an agent launching into a multi-channel sibling family would benefit from knowing.

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

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

The tool takes zero declared parameters, so per the baseline rule the schema cannot be improved on and the description is not penalized for omitting parameter detail. The open additionalProperties object means any supplied arguments are undocumented in both places, but with 0 required params this is a minor concern.

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 (Launch) plus a precisely scoped resource (Google Performance Max campaign), which cleanly distinguishes it from launch_meta_ad, launch_tiktok_campaign, launch_search_campaign and the generic launch_campaign siblings without opening any schema.

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

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

Usage context is only implied: the tool is for Performance Max launches and it notes a preview-confirmation step must precede it. It never names the preview tool, nor states when to prefer this over launch_search_campaign or launch_campaign, so the agent must infer routing from the name alone.

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

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

Annotations only carry readOnlyHint=false, so the description shoulders most of the burden and does add real value: it discloses that the campaign launches in a paused state and requires confirming a preview. That is meaningful safety/flow context beyond the annotation. It still omits auth requirements and what the launch actually returns or triggers.

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

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

Two tight sentences with zero waste. The core action is front-loaded and the behavioral caveat (starts paused, preview confirmation) follows immediately.

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

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

With no output schema and minimal annotations, the description covers purpose and the key behavioral quirk (paused launch, preview confirmation). The main gap is that the empty input schema leaves the keyword/ad-text handoff unexplained, but for a launch action this is close to complete.

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

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

There are zero schema parameters, so the baseline is 4. The description references 'your keywords and ad text,' which hints at required inputs, but since the schema is empty with additionalProperties=true it does not clarify how those inputs are supplied or their 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?

Specific verb (launch) plus channel-specific resource (Google Search campaign), which cleanly separates it from launch_meta_ad, launch_tiktok_campaign, and launch_pmax_campaign. It also states the required inputs qualitatively (keywords and ad text). It stops short of explaining how it relates to the generic launch_campaign sibling, so a 4 rather than 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?

The description gives process context ('starts paused, after you confirm a preview') but never states when to choose this tool over launch_campaign, launch_pmax_campaign, or the other launch_* siblings. Usage is implied by the channel name, but no explicit when/when-not guidance or prerequisites 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 only supply readOnlyHint=false, so the description carries the rest, and it delivers genuinely useful behavior: the campaign 'starts paused' and requires a preview confirmation before going live. That is exactly the kind of non-obvious side effect an agent could otherwise assume away. It stops short of describing error behavior or post-launch state transitions.

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 essential action first, with the paused-start and preview caveat immediately after. Nothing is redundant and nothing is buried.

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 launch action with no output schema, the description covers the key state fact (starts paused) and the gating step (confirm preview). It is thin on how the video argument is supplied and what the tool returns on success, but the annotations and narrow scope limit how much more 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?

The schema declares zero properties (additionalProperties: true), so the baseline is 4. The description mentions 'your video' as the input but does not name or describe the parameter that carries it, leaving the agent to infer where the video reference comes from.

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 ('Launch a TikTok campaign') and names the required asset ('with your video'), which distinguishes it from launch_meta_ad, launch_search_campaign, and launch_pmax_campaign by platform. It never names those siblings explicitly, so differentiation relies on the agent inferring from the platform word.

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 rather than prescribed: the phrase 'with your video' signals the prerequisite, and the preview-confirmation step hints at the intended workflow. There is no statement of when this tool is preferable to launch_campaign or launch_cloned_ad, and no 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=true, so the safety profile is covered. The description adds the useful constraint that results are limited to the caller's own connected accounts, but says nothing about return ordering, pagination, or what an empty result means.

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

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

A single front-loaded sentence with no filler. Nothing is repeated from the title or schema, and there is no waste.

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

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

For a trivial zero-parameter list tool with annotations covering safety, this is close to adequate. However, with no output schema, the description leaves the agent unaware of what an account record contains or how results are ordered/truncated, which is a real gap when the return value drives follow-up calls like inspect_ad_account.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate beyond what the empty schema already conveys.

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 accounts) with a scoping qualifier ('you have connected'). This clearly separates it from connect_ad_account and inspect_ad_account, though it never names them explicitly.

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

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

Usage is only implied: an agent can infer this is the entry point for seeing which accounts exist before inspecting or launching against one. There is no explicit when-to-use or when-not-to-use guidance versus siblings like inspect_ad_account or get_account_performance.

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 readOnlyHint annotation already signals a safe read operation. The description adds that results include campaign status, which is useful behavioral context, but it does not disclose return format, pagination, ordering, or any account connection prerequisites beyond the phrase 'connected ad account'.

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

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

A single front-loaded sentence with no filler. Every part of the sentence contributes to identifying the tool's output: resource, scope, and status.

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

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

For a zero-parameter read-only listing tool with no output schema, the description covers what is listed and that status is included. It does not need to explain return values, though it could mention ordering or whether all campaigns are returned to be 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?

The tool has zero parameters, so the baseline score is 4. The description adds no parameter semantics because none exist, and it appropriately does not invent any.

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 (List) and resource (campaigns) and adds scope ('in a connected ad account') and content ('their status'). It distinguishes itself from action siblings like launch_campaign or pause_campaign by operation, but does not explicitly name an alternative tool.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. The agent can infer that this is for viewing campaigns, but the description gives no explicit context for selecting it over related tools such as get_account_performance or inspect_ad_account.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower, and the description is consistent with it. It usefully specifies the returned asset types (images and videos), but says nothing about pagination, result caps, or ordering.

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 short sentence with no filler, front-loading the verb and the resource. Nothing is wasted or buried.

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?

A parameterless, read-only listing tool with no output schema needs only to say what it returns and that it is safe; the description does both. Minor gap: no hint about result volume or pagination behavior for a potentially large library.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to clarify or fail to clarify.

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 a specific verb (List) and resource (images and videos in your creative library), which an agent can separate from siblings like list_my_products or search_ads by resource name. It stops short of explicitly contrasting itself with those siblings.

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

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

The description contains no when-to-use statement, no prerequisites, and never mentions the many sibling listing/search tools (list_my_products, search_ads, get_instagram_content). The agent must infer usage entirely from the name.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's job is lighter. It adds the scope that the list is user-saved products, but says nothing about ordering, pagination, or what fields come back, which limits its added value.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though so minimal that it barely earns more than the verb+object it contains.

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 trivial parameterless read tool with no output schema, the definition is adequate but leaves real gaps: it does not say whether results are paginated, what shape they take, or whether an empty list is possible. A little more would make it fully callable without surprises.

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

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

The tool takes zero parameters, which is the baseline-4 case, and the empty schema is fully consistent with a parameterless list operation. The description adds nothing further, but there is nothing further to add.

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 (list) and resource (products you have saved), which distinguishes it from the write-side siblings add_product and remove_product. It does not explicitly name any sibling or scope boundary, so it stops short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named (e.g., how this relates to add_product/remove_product or whether a search tool exists for products). The phrase 'you have saved' only implies the saved-items context.

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

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

The annotation already marks this as a non-read-only operation (readOnlyHint=false), so the agent knows it mutates state. The description adds the behavioral detail that it stops spending, but does not cover reversibility, required permissions, or what happens if the campaign is already paused.

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 definition is a single sentence with no wasted words. The action and its purpose are front-loaded, which is exactly what an agent needs for quick selection.

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

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

For a simple mutation tool with no output schema and annotations covering the safety profile, the description is largely sufficient. However, it does not explain how the target campaign is identified despite having no parameters, leaving a gap in invocation context.

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

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

The input schema has zero parameters, so there are no parameter semantics to clarify. Per the rubric, a 0-param tool receives a baseline of 4; the description does not need to compensate for schema gaps.

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 (pause) and resource (a running campaign), and adds the effect (stops spending). An agent can distinguish this from resume_campaign and launch_campaign 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?

The phrase 'so it stops spending' implies the intended use case, but the description does not explicitly name alternatives or conditions when not to use it. With a sibling 'resume_campaign' present, a routing cue would have been helpful.

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

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

Annotations only supply readOnlyHint=false, so the description carries most of the burden. It does add useful scoping context (the target is a previously saved product, i.e., user state rather than arbitrary catalog items), but it says nothing about whether removal is permanent or reversible, or what happens if the product isn't found. No contradiction with the annotation.

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

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

A single short sentence with no padding. The verb and the object scoping are both front-loaded in the first four 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 only a readOnlyHint annotation, the description covers the essential purpose adequately. It is slightly thin on what the removal affects and how errors are surfaced, but nothing critical is missing 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?

Zero parameters are declared, so per the baseline the schema cannot be a source of ambiguity. The description adds the only semantic cue available (the product must have been saved earlier), though it doesn't explain how the product is identified given an empty parameter object.

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

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

States a specific verb (remove) and resource (a product you saved earlier), which the agent can contrast with add_product and list_my_products. It does not name any sibling explicitly, so it stops short of full differentiation.

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

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

The phrase 'you saved earlier' implies a precondition (the product must already be in the user's saved set) and implies the inverse of add_product, but there is no explicit when-to-use, when-not-to-use, or named alternative.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's job is to add context — and it adds almost none. With zero input parameters, the description never explains how the target competitor is identified (saved brand context? prior find_competitors call?), which is the most important behavioral unknown for this tool.

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

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

One front-loaded sentence with no filler or redundancy. It is tight, though its brevity is partly a consequence of under-specification rather than deliberate economy.

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?

This is a low-complexity, annotation-covered, no-param tool, so a short description can suffice. The missing piece is how the competitor is selected given the total absence of inputs — that gap should be closed for an agent to invoke it with confidence.

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

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

The tool takes no parameters, so there is no schema detail for the description to compensate for; baseline 4 applies. The description does not need to explain parameter syntax here.

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

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

States a concrete verb ('See') and a specific resource ('Google keywords a competitor's website shows up for'), which clearly separates it from the sibling research_keywords (own keywords) by scope. It stops short of naming that sibling explicitly, so the differentiation is inferred rather than stated.

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

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

The phrase 'a competitor's website' implies the tool is for competitor research rather than your own brand, which is useful implied context. However, it never says when to prefer this over research_keywords or how it relates to find_competitors/save_my_brand, and gives no prerequisites or 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?

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description usefully adds what the tool returns (search volume and cost estimates), but says nothing about data source limits, freshness, or whether the topic must be supplied elsewhere before calling.

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

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

One front-loaded sentence with no filler; the resource and its return payload come first, which is the right order for scanning.

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?

Annotations cover the safety profile and the sentence covers the return content, which is good given no output schema. However, for a tool that clearly expects a subject ('a product or topic'), the absence of any statement about how to supply that input leaves the agent under-equipped to invoke 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?

With zero declared parameters the baseline would be 4, but the description asserts the tool works 'for a product or topic' while the schema exposes no named properties (additionalProperties: true), so the agent is left guessing the argument name and format. That ambiguity is a real gap the description does not close.

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 (Get) plus resource (Google keyword ideas) with the return payload named (search volume and cost estimates) and scope (a product or topic). It does not explicitly distinguish itself from the sibling research_competitor_keywords, so sibling differentiation is left to inference.

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

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

There is no when-to-use guidance, no exclusions, and no reference to the obvious alternative research_competitor_keywords. Usage is only implied by the phrase 'for a product or topic'.

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 readOnlyHint annotation already establishes this is a safe read operation, lowering the burden on the description. The description adds the narrow scope (brand or topic) but says nothing about result volume, rate limits, pagination, or what a returned ad looks like.

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

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

A single, front-loaded sentence with no filler, and the verb+resource come first. It is efficient, though it is arguably too terse given the missing routing guidance.

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, parameterless research tool with no output schema, the description should at least convey how results are scoped and how it differs from get_brand_ads/search_ads. As written it is functional but leaves the agent guessing at result shape and boundaries.

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 zero declared parameters, the baseline is 4. The description mentions "a brand or a topic" as the search subject, which is the only signal about input, but the schema exposes no fields at all despite additionalProperties being true, so no further semantics are needed.

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 concrete verb ("Find") and resource ("TikTok ads") with a clear scope ("for a brand or a topic"). However, it does not distinguish itself from the closely related siblings get_brand_ads and search_ads, which sound like they retrieve the same thing.

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

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

There is no guidance on when to prefer this over get_brand_ads or search_ads, nor any exclusions or prerequisites. The only hint is the word "research" in the name, leaving the agent to guess the boundary.

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

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

Annotations only supply readOnlyHint=false (a mutation), and the description adds a real behavioral trait beyond that: a confirmation step is expected. But it omits other mutation-relevant context — what is required to target the campaign, whether resuming is reversible, and whether it can fail if the campaign is not paused.

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 short sentence with the action front-loaded and no filler. It is appropriately sized, though it could spend a few more words on the confirmation requirement without bloat.

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 parameters, no output schema, and only readOnlyHint=false, the description should clarify how the campaign is identified (since no identifier parameter exists) and what happens on failure. Instead it says nothing about targeting, making it materially incomplete 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?

The schema declares zero parameters (additionalProperties true, coverage 100%), so per the baseline for parameterless tools this defaults to 4. The description adds no parameter detail, and notably does not explain how the target campaign is identified, but with no declared params there is little to document.

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

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

States a specific verb+resource pair ('Turn a paused campaign back on') and names the precondition state (paused), which distinguishes it from its inverse sibling pause_campaign. It stops short of explicitly naming the sibling or scope limits, but an agent can identify the operation unambiguously.

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

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

The phrase 'after you confirm' implies a confirmation gate before invoking, which is genuine usage guidance. However, there is no explicit when-to-use/when-not, no mention of pause_campaign as the inverse, and no stated prerequisite that the campaign must currently be paused.

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

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

Annotations only supply readOnlyHint=false, so the description carries most of the behavioral burden. It does not say whether changes overwrite the prior script, whether they are reversible, or whether a re-render/approval step follows the change. For a mutation tool this leaves the agent without the operational context it needs.

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 short, front-loaded sentence with no filler; the verb and object come first. It is appropriately sized for the amount of information provided, though it is terse to the point of under-specification.

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 mutation tool with no output schema and minimal annotations, the description should explain how the target ad is identified implicitly, what the change affects, and what happens afterward. None of that is present, so the agent can only guess at the workflow.

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

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

The schema declares zero parameters, so the baseline is 4. However the description names three editable facets (script, language, captions) that are not represented as parameters anywhere in the schema, which leaves the actual modification target ambiguous even though there is nothing to document.

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

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

The description gives a specific verb ('Change') plus the resource ('a video ad's script') and the three mutable aspects (script, language, on-screen captions), so the agent knows what the tool does. It offers no differentiation from adjacent siblings such as clone_video_ad, clone_from_script or generate_brief, which also act on video ad content.

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

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

There is no guidance on when to use this versus clone_from_script, clone_video_ad or generate_brief, and no stated prerequisites or preconditions (e.g., whether an existing brief/clone is required first). The agent must infer usage entirely from the name.

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

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

Annotations only declare readOnlyHint=false, confirming a write. The description adds no behavioral context beyond the input sources: it doesn't say whether saving overwrites an existing brand, creates duplicates, requires prior setup, or what the effect on sibling brand data is.

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

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

A single front-loaded sentence with no padding. It is appropriately sized, though it is arguably a touch thin for a mutation tool rather than verbose.

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 a write operation with no output schema and only a readOnlyHint annotation, the description should at least state the effect of saving and how it relates to add_brand. It covers ingest sources but not outcome, so it is minimally adequate rather than complete.

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

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

The tool declares zero properties, so the description's note that the brand can come from 'your website or a short description of what you sell' is effectively the only documentation of accepted free-form input (schema is additionalProperties:true). 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?

Clear verb+resource: it persists 'your brand' from either a website or a short description of what you sell. However, it does not distinguish itself from the sibling add_brand or explain how a 'save' differs from an 'add', leaving an agent to guess between them.

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

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

Usage is only implied: the mention of 'your website or a short description' hints at acceptable inputs, but there is no explicit when-to-use statement, no when-not-to-use, and no routing to add_brand, get_my_brand, or clear_my_brand.

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 readOnlyHint=true annotation already establishes this as a safe read operation, lowering the disclosure bar. The description adds that retrieval is concept-driven rather than keyword- or ID-driven, which is a genuine behavioral trait, but says nothing about result volume, ordering, or pagination.

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 conveys the verb, resource, and filter dimension with two illustrative examples. No filler and nothing deferred to a later sentence.

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

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

With no input properties and no output schema, the description carries the burden of explaining what comes back and what to supply, and it only partially does so. It never says whether the return is a list of ad creatives, how many, or how the 'idea' argument is passed.

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?

Zero parameters means the baseline is 4, but the description implies an 'idea' input that is not modeled anywhere in the schema (empty properties, additionalProperties true). That hint is useful directionally yet ambiguous about the actual calling shape, so it neither fully earns the no-params baseline nor leaves the agent stranded.

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 (Search) and resource (a brand's ads) and adds the distinguishing filter dimension (by idea), with concrete examples 'before and after' and 'social proof'. It stops short of naming or contrasting with the sibling get_brand_ads, which also retrieves brand ads, so an agent must guess how the two differ.

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 when-to-use guidance is given — nothing says when to pick this over get_brand_ads, search_brands, or get_instagram_content. The 'by idea' phrase hints at a use case but never states prerequisites or 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?

The readOnlyHint annotation already tells the agent this is a safe read, and the description adds nothing beyond that — no information about what is returned, result size, pagination, or whether an ad account/campaign identifier is required. Since annotations cover the safety profile, the description needed to contribute the remaining behavioral context and does not.

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

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

A single front-loaded sentence with no repetition or filler. It is appropriately short, though the trailing example list is the only content beyond a restatement of the name, so it sits just below the top of the scale.

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

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

For a zero-parameter, read-only lookup the description is nearly adequate, and it does characterize the output categories (interests, locations, audiences). However, with no output schema and no parameter documentation, it should say more about what the lookup returns or what input context (e.g. a campaign) it implicitly relies on.

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

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

The tool takes zero parameters, so the baseline is 4. The description's mention of a 'campaign' scope adds a little interpretive context, but with an empty schema and additionalProperties=true there are no parameter semantics to clarify.

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

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

Names a specific verb ('look up') and resource ('targeting options for a campaign') and gives concrete examples (interests, locations, audiences). It is clearly a read operation, but it does not distinguish itself from siblings that also touch targeting, such as create_audience or update_campaign_locations.

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 like create_audience or update_campaign_locations, which appear in the sibling list and overlap in subject matter. The scope 'for a campaign' hints at context but no explicit when/when-not 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?

The readOnlyHint=true annotation already establishes this is a safe, non-mutating lookup, so the description is not the sole carrier of behavior. It adds the purpose of the lookup but says nothing about scope (platform-wide brand database vs. the user's own brands), rate limits, or result shape.

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

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

A single front-loaded sentence with no filler. Every word contributes something an agent can use.

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 carries some burden for the result, and it only gestures at it ('whether its ads are available') without saying what is returned (a boolean, a brand id, availability details). Combined with the undocumented 'name' input, the profile is adequate but incomplete.

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

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

The schema declares zero properties with additionalProperties=true, so it documents no input at all; the description fills that gap by stating the call is made 'by name'. It does not specify name formatting or matching behavior (exact vs. fuzzy), so it stops short of a 5.

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

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

Specific verb+resource: 'look up a brand by name', with the added outcome ('to see whether its ads are available'). An agent knows what it does, but it never distinguishes itself from siblings like get_my_brand, get_brand_ads, or search_ads, so it earns a 4 rather than 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?

'to see whether its ads are available' implies the intent behind the call but gives no when-to-use/when-not guidance and names no alternative. Against siblings such as get_my_brand or search_ads, the agent is left to infer which to pick.

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

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

The annotation readOnlyHint=false already declares this is a mutation, and the description is consistent with that. It adds one genuine behavioral trait beyond the annotation: the operation must follow a confirmed preview. It omits reversibility, permission requirements, and what happens to the prior budget value.

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

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

A single sentence with no filler, and the core action is front-loaded ahead of the precondition. It is efficient, though arguably thinner than a mutation tool warrants.

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

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

This is a mutating tool with no output schema and an effectively empty input schema, so the description carries nearly the whole burden. It supplies neither the arguments the agent must pass nor the effect of the change, which is inadequate for invoking a budget-changing operation reliably.

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

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

The schema declares no properties while allowing additionalProperties, so the agent has no concrete field names, types, or required keys to work with. The description conveys the conceptual inputs (which campaign, what daily budget) but no syntax, currency, or naming, leaving real ambiguity about how to form the call.

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: changing a campaign's daily budget. An agent can distinguish it from sibling mutation tools like pause_campaign or update_campaign_locations. It doesn't name a sibling it could be confused with, but the purpose itself is 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 phrase 'after you confirm a preview' implies a required workflow precondition, which is real usage guidance. However, it references a preview step no sibling tool in the list obviously provides, and it gives no when-not-to-use or alternative-selection guidance.

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

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

Annotations only declare readOnlyHint=false, so the description carries the burden of explaining this mutation. It does not say whether the update replaces the entire location set or is additive, whether it affects live/active campaigns, or what permissions are needed — meaningful omissions for a mutating tool.

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

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

One short, front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than disciplined trimming.

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 mutating tool with no output schema, only a readOnlyHint annotation, and an open-ended input object, the description omits payload shape, mutation semantics, and validation rules. An agent could not reliably invoke this correctly from the definition 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?

The schema declares zero properties with additionalProperties=true, which ironically means the agent most needs the description to learn the expected field names (campaign identifier, location list) — and it supplies none. The 0-param baseline of 4 is reduced because the free-form schema leaves the caller guessing the payload shape.

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?

"Change the places a campaign shows in" identifies a verb (change) and a resource (campaign locations/geo-targeting), but it is close to a restatement of the title "Change locations" and never uses the domain term (targeting/geo/placements), nor says whether it adds, removes, or replaces locations. It does not distinguish it from siblings like search_ad_targeting or launch_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?

There is no when-to-use guidance, no prerequisites (e.g., campaign must exist, must be editable), and no mention of alternatives such as search_ad_targeting for discovering valid locations. The agent must infer usage entirely.

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

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

Annotations only provide readOnlyHint=false, so the description carries the bulk of the behavioral burden. It does not disclose that removal is destructive/irreversible, what state keywords must be in, what permissions or account context are required, or what the call returns; 'remove' in particular deserves a warning.

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

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

A single efficient sentence with the action verbs front-loaded and no filler. It is appropriately sized for the stated purpose, though it says nothing a mutation tool of this type arguably needs.

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, shallow annotations, and an undefined parameter surface, the description omits too much: it does not explain how to target a campaign or keyword, what happens on removal, or any confirmation behavior. An agent could not reliably invoke this correctly from what is given.

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?

Zero properties are declared and the schema is an open object with additionalProperties=true, so the agent has no structured guidance on how to identify the campaign, keywords, or the action to apply. The description implies an action-plus-keyword-list shape but never specifies identifiers, formats, or whether batch input is expected.

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 specific verbs (add, pause, remove) on a specific resource (keywords) within a named platform surface (Google Search campaign). This distinguishes it reasonably from research_keywords and add_negative_keywords, though it doesn't explicitly name those siblings as alternatives.

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 when-to-use guidance, prerequisites, or comparison to adjacent tools such as add_negative_keywords or research_keywords. The agent must infer from the name alone that this mutates existing campaign keywords rather than negative or researched keywords.

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