Honeyfield Marketing MCP

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that assets are merely attached (additive, not replacing the group's contents), but says nothing about what happens on duplicate field_type conflicts, partial failures, or whether repeated calls are idempotent — meaningful gaps for a mutation 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?

Three dense sentences, front-loaded with the action and followed by the two non-obvious parameters. The long comma-separated field_type list is slightly unwieldy but every element is load-bearing 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?

An output schema exists, so return values need not be described. Still, for a mutation tool with 0% schema coverage the description omits the ordering/precondition story (assets must be uploaded first, asset group must exist, field_type must match the group's campaign type), which is exactly the context an agent needs before calling 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?

Schema description coverage is 0% and the assets array is typed only as a free-form object, so the description carries the full load — and it does: it documents the {"asset_id", "field_type"} shape and enumerates all nine valid field_type values, which the schema does not. workspace is explained as an optional customer slug; only asset_group_id is left to the agent's obvious reading of the name.

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 German sentence 'Bestehende Assets an eine Asset Group hängen' gives a specific verb (attach) and resource (existing assets → asset group), which is unambiguous. It does not, however, distinguish itself from closely related siblings such as ads_link_asset, ads_create_text_assets, or ads_upload_image_asset, so an agent still has to infer the boundary.

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

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

'Bestehende Assets' implies prerequisites (assets must already exist, asset group must exist), but this is left implicit — no explicit when-to-use, when-not, or named alternative is given. With ~80 sibling tools in the ads_* family, this leaves the agent to infer the workflow rather than routing 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?

Adds behavior the annotations do not carry: Google-side rejections surface as exceptions rather than an {error} payload, and the 25-search-theme cap is a Google limit that is not validated in advance. Short of a full return-shape or partial-failure description, but well beyond the readOnly/destructive hints.

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

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

Front-loaded with the action and both signal types before the caveats; each clause carries information (limit, wrong-ID warning, error mode). It runs as one dense block without line breaks, which makes the workspace note at the end easy to skim past.

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

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

An output schema exists, so return values need no prose, and the description covers the realistic failure modes and the sibling hand-off. It does not say what happens if neither search_themes nor audience_id is supplied, which matters given only asset_group_id is required.

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

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

Schema description coverage is 0%, so the description must carry the load and largely does: audience_id's provenance (Google Ads UI → Zielgruppen-Manager) and its explicit exclusion of user_list_id are exactly the disambiguation the bare schema lacks, and workspace's optionality rule is stated. search_themes only gets the count cap, not string format or semantics, and asset_group_id is left implicit.

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 and resource ('Signale an eine PMax-Asset-Group hängen') and enumerates the two signal types it accepts (Search Themes und/oder eine Audience). An agent can distinguish it from ads_add_audience_signal and ads_add_asset_group_assets purely from this text.

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

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

Explicitly routes the agent: audience_id uses audience resources, while user_list_id from ads_list_audiences must NOT be passed here — use ads_add_audience_signal at campaign/ad-group level instead. It also gives the rationale ('Ohne Signale lernt PMax blind'), which clarifies when the call is worth making 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 readOnly=false, destructive=false, openWorld=true; the description adds the operationally critical facts: the tool neither reads nor sets observation-vs-targeting mode, and if the list is targeting it immediately restricts reach to its members. That is a real side effect not derivable from annotations, plus a pre-check 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?

Front-loaded with the primary rule and the exclusion, then the supply chain for the ID, then the risk caveat — a sensible order. It runs slightly long with some overlap between the first two sentences about campaigns/ad groups, but no sentence is pure filler.

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

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

With an output schema present, return values need no explanation, and the description covers everything else an agent needs: target selection constraint, ID provenance, PMax diversion, and the delivery-impact warning. Nothing required for a correct call is missing.

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

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

Schema coverage is 0%, so the description carries the full burden and does: it explains the mutually exclusive campaign_id/ad_group_id pair, the source system for user_list_id, and the optionality of workspace when only one workspace exists. All four parameters gain meaning beyond their bare names.

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 (attach an audience list to a campaign or ad group, creating a user-list criterion) and scopes it to Search/Display. It explicitly excludes PMax and names ads_add_asset_group_signal as the alternative, so an agent can distinguish it from siblings without opening schemas.

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

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

Gives the exact use condition (exactly one of campaign_id or ad_group_id), the negative case (NICHT für PMax), and the replacement tool. It also routes the agent to ads_list_audiences / ads_list_customer_match_lists for obtaining user_list_id.

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

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

Goes well beyond the annotations (readOnly=false, destructive=false) by explaining that a keyword in a live ad group starts spending immediately and only takes effect after an explicit status update — real side-effect disclosure for a mutation tool. It also notes cpc_bid_eur is a no-op under Smart Bidding, which prevents a silent misconfiguration.

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

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

Front-loaded with the action and defaults, then the reasoning; every clause is actionable. Some rhetorical flourish about spending money could be trimmed, but the emphasis is on point for a spend-risk mutation.

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 6-parameter mutation with an output schema, the definition covers defaults, side effects and the follow-up tool, so an agent can call it correctly. Missing pieces are minor: no pointer to ads_bulk_add_keywords for multi-keyword insertion and no keyword string format guidance.

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

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

With 0% schema description coverage the description must carry the burden, and it does for match_type (BROAD/PHRASE/EXACT), status (default PAUSED, override ENABLED), cpc_bid_eur (MANUAL_CPC only) and workspace (optional with a single workspace). It says nothing about ad_group_id or the expected keyword string format (e.g., whether bracketed/exact syntax is accepted).

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 ('Keyword zu einer Ad Group hinzufügen') plus the allowed match types, so the agent knows exactly what is created and where. It is distinguishable from read-only siblings like ads_list_keywords and from ads_remove_keyword.

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

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

Gives clear conditional guidance: default PAUSED for safety, enable later via ads_update_keyword_status(..., 'ENABLED'), or pass status='ENABLED' deliberately. It does not mention the sibling ads_bulk_add_keywords, so the single-vs-bulk decision is left to inference.

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

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

Annotations already mark this as a non-destructive mutation with open-world behavior. The description adds meaningful context beyond that: it explains that the keyword blocks searches, details how EXACT/PHRASE/BROAD affect matching, warns that broad match types can block relevant searches, and clarifies that the negative is campaign-owned.

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 purpose is front-loaded, and the subsequent match-type explanation, warning, alternatives, and workspace note all earn their place. It is dense but not 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?

An output schema exists, so return values need not be described. The description covers the main behavioral risks, match-type semantics, workspace handling, and sibling alternatives; the main remaining gap is keyword format guidance.

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

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

Schema description coverage is 0%, so the description must compensate. It extensively explains the match_type values and notes that workspace is optional for single-workspace accounts, but it does not explain keyword formatting or add much detail about campaign_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?

The description states a specific verb and resource: adding a negative keyword to a campaign, with the effect of blocking search queries. It also distinguishes campaign-level negatives from shared and account-level negatives by naming the relevant alternative tools.

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

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

It explicitly says when to use this tool (campaign-owned negative keywords) and when to use alternatives for multiple campaigns or account-wide negatives. It also warns that PHRASE and BROAD should only be chosen deliberately and disclosed to the user before creation.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious behavior: a hard top-20 cap, cost-based ranking, the yesterday cutoff, and the silent exclusion of zero-cost ads — all things an agent would otherwise get wrong.

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

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

Front-loaded with the core statement, then caveats, then the parameter note — a sensible order. The field enumeration is somewhat long and partly duplicates the output schema, but it stays readable and earns most of its space.

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

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

For a two-parameter read-only report with an output schema, the description covers scope, ranking, time window, exclusions, and the alternative tool. The only gap is the undocumented 'days' parameter default/limits.

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

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

Schema description coverage is 0%, so the description must compensate. It explains workspace well (slug, optional when only one workspace), but only alludes to the days parameter ('letzten N Tage') without naming it, stating its default, or clarifying valid ranges.

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 precisely what the tool returns: the top 20 ads ranked by cost over the last N days up to yesterday, with an explicit field list. It also distinguishes itself from ads_list_ads (full list) and implicitly from ads_campaign_performance / ads_keyword_performance by scoping to ad level.

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

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

Gives clear usage boundaries: today is excluded, ads without cost are omitted, and ads_list_ads is named as the route for a complete list. It does not compare against sibling performance tools (campaign/keyword), but the when-to-use context is otherwise explicit.

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

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

Annotations already cover read-only and open-world, so the description is free to add genuinely new behavior: the aggregation window ends yesterday with today excluded, results are sorted descending by cost, output is capped at 200 rows, and headline/landing-page dimensions are structurally unavailable via the API. That last point is important negative information an agent could not otherwise know. It does not discuss rate limits or empty-result 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?

Compact and front-loaded: the source split and its purpose come first, then the metric list, then window/sort/limit, then the per-parameter notes. It is one dense paragraph with telegraphic punctuation and some run-on clauses, but nearly every sentence carries information an agent 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 read-only reporting tool with an output schema, the essentials are present: what is returned, how it is aggregated and sorted, the row cap, the unavailable dimensions, and all four filters. Minor gap: it does not point to where headline/landing-page data can instead be obtained, which would help an agent recover from that limitation.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely meets it: days is defined as the aggregation window ending yesterday (today excluded), campaign_id as an optional single-campaign filter, min_cost_eur as a cost threshold that hides combinations below it, and workspace as a customer slug that is optional when only one workspace exists. The only gap is that the days=30 default and the exact semantics of the 200-row cap interaction with min_cost_eur are left to the schema.

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

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

States a specific operation: a source split per search term × campaign returning the official source (KEYWORD / AI_MAX_KEYWORDLESS / AI_MAX_BROAD_MATCH / BROAD_MATCH) plus metrics. It also declares its analytical purpose ('Deckt Off-Target-Streuung der AI-Max-Expansion auf'), which differentiates it from ads_search_terms and ads_performance-style siblings in substance. It stops short of naming a sibling it is not, so 4 rather than 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?

Usage is implied rather than stated: the reader can infer this is the tool for AI Max keywordless/broad-match spillover analysis, and the note that headline/landing page data is NOT available is a useful scope exclusion. There is no explicit 'use this when / use X instead' routing against ads_search_terms or ads_pmax_search_insights, and no prerequisites are mentioned.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds concrete substance beyond that: recommendations can alter budgets, bids and targeting, and explicit user confirmation is required — a real workflow constraint rather than a restatement of annotations.

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

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

Three short lines, with the action and the confirmation warning front-loaded before the parameter note. No filler, though the workspace hint could be trimmed since the schema already marks it optional with a null default.

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 two-parameter mutation with an output schema, the definition covers source of input, safety consequence, and required confirmation. Return-value explanation is unnecessary given the output schema, so nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: resource_name's provenance (ads_list_recommendations) and workspace's meaning (client workspace slug, optional when only one workspace) are both explained. It stops short of showing the resource-name format, which keeps it from 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?

States a specific verb (anwenden/apply) and resource (Google Ads recommendation), and points to the exact sibling (ads_list_recommendations) that supplies the resource_name. An agent can distinguish this from ads_dismiss_recommendation without opening either schema.

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

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

'Nur nach ausdrücklicher Bestätigung anwenden' gives an explicit precondition for invocation, and the parenthetical tells the agent to obtain resource_name from ads_list_recommendations first. It doesn't explicitly contrast with the sibling dismiss tool, but the usage context is clear.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds useful behavioral detail: the date window means the last N full days up to yesterday and excludes today, results are sorted by cost descending, and workspace is optional when only one workspace exists. It does not discuss authentication or rate limits, but for a read-only reporting tool the added context is substantive.

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

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

The description is front-loaded with the main purpose and then supplies date interpretation, returned fields, sorting, and workspace notes. It is reasonably efficient, though listing every returned field is somewhat redundant given that an output schema exists.

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

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

With an output schema present and read-only annotations provided, the description covers the essential context: what is measured, over what date window, how results are sorted, and the workspace condition. The main remaining gap is campaign_id semantics, but overall it is complete enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the days parameter well (last N full days, excluding today) and explains workspace as a slug that is optional when there is only one workspace. The campaign_id parameter is only implied by 'optional je Kampagne' and its format or exact role is not clarified.

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

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

The description states a specific resource and metric domain: performance of PMax asset groups over the last N days, including impressions, clicks, cost, conversions, and Ad Strength. It makes clear that this is asset-group-level performance, which is distinguishable from sibling tools such as ads_campaign_performance or ads_ad_performance.

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

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

It specifies the reporting window and that campaign filtering is optional, which implies the usage context. However, it does not explicitly say when to use this tool instead of sibling performance tools like ads_campaign_performance or ads_list_asset_groups, leaving the agent to infer the choice from the resource 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context: the fixed 7-day window, how avg_daily_spend handles younger campaigns, how the utilization ratio is computed, and how shared budgets are attributed — none of which is in the annotations.

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

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

Front-loaded with purpose and window before formulas and field list; every sentence carries information. It is dense and formula-heavy but not padded, and the field enumeration is somewhat redundant given an output schema exists.

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

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

With an output schema present, return values need not be explained, yet the description lists them anyway; combined with the window, formulas, and parameter note, an agent can invoke this correctly. Slight redundancy rather than a completeness gap.

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

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

Schema description coverage is 0% for the single workspace parameter, so the description must compensate, and it does: it defines workspace as the customer workspace slug and notes it is optional when only one workspace exists. That is the meaningful semantic an agent needs for the only parameter.

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

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

The description names a specific verb/resource combination (daily budget, actual spend, utilization per campaign) and pins down the exact reporting window (last 7 complete days, excluding today). It also lists the returned metrics, so an agent knows precisely what this tool answers versus generic performance tools.

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

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

It explicitly routes the agent to budget_pacing for the monthly course, which gives a clear positive alternative. It also explains the shared-budget caveat, but does not state exclusions relative to ads_campaign_performance or ads_update_campaign_budget beyond that single pointer.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false; the description goes beyond them by disclosing the PAUSED default, the budget-risk reasoning behind it, and the two-step create-then-activate pattern. It also notes that cpc_bid_eur has no delivery effect under Smart Bidding, which is real behavioral context. It stops short of covering duplicate-keyword handling, batch-size limits, or error 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?

Front-loads the action in the first clause, then the safety default, then the parameter details — a sensible order. The safety rationale runs a bit long for what it conveys, but every sentence carries operative information rather than filler.

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

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

With an output schema present and annotations covering the safety profile, the description supplies what is missing: the mutation's default state, the activation follow-up, and the nested keyword object semantics. It would be complete with a note on duplicate handling or per-call limits for a bulk mutation.

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

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

Schema coverage is 0%, so the description carries the full burden and largely does: it spells out the keywords item shape (keyword, match_type enum with BROAD default, optional cpc_bid_eur with its MANUAL_CPC caveat) and explains workspace as an optional slug when only one workspace exists. Only ad_group_id is left undocumentedly explained, which is the main remaining gap.

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

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

States a specific verb and resource — creating multiple keywords in an ad group — plus the scope differentiator 'ein API-Call statt N', which separates it from the singular ads_add_keyword sibling. It also names ads_bulk_update_keyword_status as the follow-up, so the agent knows exactly where this tool sits in a workflow.

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

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

Explains the safety rationale for the PAUSED default (avoiding unintended ad spend on a live ad group) and explicitly routes the agent to ads_bulk_update_keyword_status with all criterion_ids for activation. What is not stated explicitly is the boundary versus the single-keyword tool ads_add_keyword — it is only implied by 'Mehrere Keywords'.

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

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

Annotations already mark this as a non-read-only, non-destructive, open-world mutation. The description adds useful behavioral context beyond the annotations: it explains how match types block searches, why EXACT is the safe default, and warns that PHRASE/BROAD should only be used deliberately after user notification.

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

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

The description is front-loaded with the core purpose and then adds relevant match-type guidance. The match-type explanation is somewhat lengthy, but it earns its place because the schema does not document those semantics elsewhere.

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 tool has three parameters, two required, and no schema descriptions; the description covers `keywords` and `workspace` but omits the required `campaign_id`. An output schema exists, so return values need not be explained, but the missing required-parameter meaning is a meaningful completeness gap for a mutation tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does well for `keywords` by documenting the object shape, match_type values, defaults, and blocking behavior, and it explains that `workspace` is optional when only one workspace exists. However, it never explains the required `campaign_id` parameter, leaving one of three parameters undocumented.

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: creating multiple negative keywords in a campaign, with the efficiency rationale "ein API-Call statt N". This clearly distinguishes bulk negative keyword creation from single-add and bulk positive-keyword tools, although it does not explicitly name 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?

Usage is implied by "Mehrere negative Keywords" and "ein API-Call statt N", which suggests using this tool when adding multiple negatives rather than calling a single-add tool repeatedly. It gives strong guidance for match_type selection, including a safe default and a warning to tell the user before creating PHRASE/BROAD terms, but it does not explicitly compare this tool with sibling tools.

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

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

Beyond the annotations, the description discloses atomic execution ('entweder alle oder keines'), the 1000-ID limit, duplicate handling, cross-ad-group behavior, and side benefits around quota and journal entries. These are meaningful operational traits that the annotations do not convey.

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

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

The description is front-loaded with purpose and alternative, then moves into parameter guidance. It is efficient overall, though the quota/journal rationale is slightly more verbose than strictly necessary for tool 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?

Given that an output schema exists, the description need not explain return values, and it covers all behavioral and parameter details an agent needs. The only minor gap is that ad_group_id is inferred rather than explicitly defined, but the surrounding text makes its role unambiguous.

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?

Although schema description coverage is 0%, the description compensates fully: it explains criterion_ids constraints and source (ads_list_keywords, same ad group), status values (ENABLED/PAUSED), and workspace optionality. ad_group_id is not defined in a standalone sentence but is clearly implied by the ad-group scoping throughout.

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

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

The first sentence states a specific verb and resource ('Mehrere Keywords einer Ad Group aktivieren oder pausieren') and immediately distinguishes the tool from per-keyword updates by noting it is one API call instead of N. The scope and the sibling it replaces are both clear without opening the schema.

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

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

It explicitly names when to use this tool: after ads_bulk_add_keywords, and instead of ads_update_keyword_status per keyword. It also states the multi-ad-group case ('je Ad Group einmal aufrufen'), so the agent knows both the primary use case and the boundary condition.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's job is to add semantics — and it does: it defines the exact date window (excludes today), defines which conversion type is counted (primary/bid-relevant, matching the 'Conversions' column), and notes the additive property across campaigns. It does not discuss limits on data volume or freshness beyond the day boundary.

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

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

Three sentences, front-loaded with the metric list, then the time-window rule that matters most for correct invocation. No filler, though the conversions-definition sentence is dense and could be split for readability.

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

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

With an output schema present, the description need not explain return shape, and it covers the two things the schema does not: the reporting window semantics and the workspace scoping rule. An agent has everything required 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?

Schema description coverage is 0%, so the description must carry both parameters — and it does: 'days' is defined as N complete days ending yesterday (today excluded), and 'workspace' is explained as the client workspace slug, optional when only one workspace exists. Only the default value of 7 is left to the schema.

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

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

States a specific resource (campaign performance) and enumerates the exact metrics returned (Impressions, Clicks, Cost, CTR, CPC, Conversions). An agent can distinguish this campaign-level report from ad-level or keyword-level siblings by the metric scope, though the description never names those siblings 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 implied rather than stated: the time-window rule ('N vollständige Tage bis gestern, heute nicht enthalten') and the note that summing all campaigns yields account totals give a sense of when the tool applies. There is no explicit guidance on when to prefer ads_ad_performance, ads_keyword_performance, or ads_device_performance instead.

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

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

Annotations already cover the read-only/open-world profile, and the description adds real operational context on top: a hard 29-day retention limit that expires daily and newest-first ordering. It does not mention rate limits, pagination, or result volume beyond the limit cap.

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

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

Four short sentences, front-loaded with the resource definition before the retention caveat and the two parameter notes. Dense but no filler; the only drag is that the parenthetical field list and the retention clause slightly overlap in intent.

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

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

With an output schema present, return values need no explanation, and the read-only profile comes from annotations. What remains for the description — retention window, ordering, the two optional parameters — is mostly covered, with the 'days' parameter range the only clear omission.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain 'limit' (1–200, newest first) and 'workspace' (optional with a single workspace), but 'days' is never named or bounded — the 29-day cap is stated only as a Google constraint, not as the valid range for the days parameter (default 14).

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 ('Änderungshistorie des Kontos') and enumerates the returned dimensions (User, Ressource, Operation, Felder). No sibling tool in the ads_* family covers change auditing, so the agent can distinguish it immediately from performance/list 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?

Usage is implied through the 29-day retention constraint ('das Fenster schließt heute ein'), which tells the agent when data is still retrievable, but it never says when to prefer this tool over alternatives or what it is not for (e.g., vs. ads_campaign_performance for metric history).

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/openWorldHint, and the description adds substantial non-obvious behavior: all dates are CONVERSION-dated, offline imports count on the event day, a same-day import lowers last_gap_days, and the window ends yesterday with last_gap_days >= 1. That is real interpretive context beyond the safety flags; only request-size/rate-limit style details are absent.

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

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

Front-loaded with what is measured and what is returned, then the caveats. It is dense but not padded, though the conversion-date explanation is restated twice (date basis and the import/last_gap_days consequence), costing some 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?

With an output schema present, the description needn't explain the return shape, yet it usefully names the key metrics. It covers the crucial semantic traps (conversion-date basis, all_conversions scope, yesterday cutoff) that would otherwise cause misreading; the only real gap is the days parameter's default and bounds.

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

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

Schema coverage is 0%, so the description must compensate: it documents the workspace slug including the single-workspace fallback, and 'letzten N Tage' implicitly defines days. However, the days default (30) and valid range are never stated, leaving half the parameters only loosely covered.

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

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

States a specific measurement ('Conversion-Performance pro Aktion der letzten N Tage') plus the returned fields and daily breakdown, and explicitly distinguishes itself from the campaign-level tools by noting it counts all_conversions including secondary actions. An agent can tell what it computes and how it differs from ads_campaign_performance without opening a schema.

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

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

Gives a concrete use case ('Prüft so, ob Offline-Importe (z.B. HubSpot-Uploads) tatsächlich ankommen') and names the alternative family it is not comparable to (click-dated campaign conversions). It doesn't spell out a when-not-to-use case, but the comparison guidance is 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 description adds substantial behavior beyond the annotations: every ad is pre-validated against Google, validation_failed means nothing is created, the default status is PAUSED for safety, validate_only performs a dry run, and repeated policy violations can suspend the ad account. These are exactly the high-stakes operational details an agent needs before invoking a creation tool.

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

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

The description is front-loaded with the core action and then organized around Google constraints, validation behavior, safety defaults, and policy risks. The compliance list is somewhat lengthy, but it earns its place given the account-suspension risk and the tool's high-stakes creation behavior.

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

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

The description is strong on validation, policy risk, safety defaults, and the main ad copy fields, and the output schema means return values need not be explained. However, with 9 parameters and 0% schema description coverage, it leaves meaningful gaps around required ad_group_id and optional path1/path2 semantics.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It supplies critical constraints for headlines, descriptions, final_urls, status, validate_only, and workspace, including counts, character limits, allowed status values, default PAUSED, and the optional workspace case. It still omits semantics for ad_group_id, path1, and path2.

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

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

The description opens with a specific verb and resource: 'Responsive Search Ad anlegen.' It makes clear this creates a Google Responsive Search Ad, which distinguishes it from update/remove/list tools and from non-Google ad creation siblings. The Google-specific requirements further reinforce the exact resource being created.

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

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

The description implies when to use the tool through its creation constraints, default PAUSED status, and validate_only dry-run mode. However, it does not explicitly route the agent against alternatives such as ads_update_ad, ads_replace_ad, or ads_create_text_assets, nor does it state when not to use this tool.

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

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

Annotations only say the tool writes and is non-destructive; the description adds genuinely new behavior: entities are created PAUSED for safety and require manual activation, and cpc_bid_eur is inert under Smart Bidding. That is real context an agent cannot get from the annotations. It stops short of stating return payload, duplicate-name behavior, or whether creation is idempotent (an output schema exists, so returns are partly excused).

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

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

Five short lines, purpose front-loaded followed by one line per non-obvious parameter. The repetition of the PAUSED default is justified because the description attaches the safety rationale the schema default alone cannot convey.

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 6-parameter mutation tool with an output schema, this covers creation scope, default state, conditional bid behavior, and workspace resolution — enough to call it correctly in the common case. Missing pieces are secondary: campaign_id validity requirements, name constraints, and error behavior. The German-only text alongside an otherwise English catalog is a minor consistency gap rather than a completeness one.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does for four of six parameters: type_ with concrete values, cpc_bid_eur with a conditional-effect rule, workspace with a single-workspace exception, and the status default with rationale. Only name and campaign_id are left undefined, though both are self-evident from their keys.

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

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

The opening line gives a specific verb and resource ("Neue Ad Group in einer Kampagne anlegen"), so an agent immediately knows this creates an ad group inside an existing campaign. It does not name or differentiate against any sibling (e.g. ads_create_ad, ads_create_campaign, openai_ads_create_ad_group), but the noun is distinctive enough that confusion risk is low.

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: a campaign must already exist and type_ should match it ("passend zur Kampagne"). The PAUSED-by-default note hints at a follow-up activation workflow, but there is no explicit "use this when... / use ads_create_campaign instead when..." routing or statement of prerequisites such as campaign existence or permissions.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses that creation is atomic with mandatory minimum assets and that new groups default to PAUSED — both meaningful safety-relevant traits. It says nothing about failure/partial-failure behavior or permission requirements, so it is strong but not complete.

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

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

Front-loaded and dense — every clause carries information an agent needs. The long parenthetical list and em-dash chaining make it a run-on that slows parsing slightly, but little could be cut without losing semantics.

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 16-parameter, 10-required mutation tool, the description covers the asset prerequisites, their source tools, the extra-assets escape hatch, dry-run mode and the default status. With an output schema available and annotations covering the safety profile, nothing essential for a correct call is missing.

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

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

With 0% schema description coverage, the description must carry the load: it gives cardinality (3 headlines, 2 descriptions), maps nearly every required asset-ID parameter to its asset type, documents extra_assets' item shape and a YOUTUBE_VIDEO example, explains validate_only and the workspace slug rule. campaign_id, name, final_url, path1 and path2 remain undocumented, keeping it below 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?

States a specific verb+resource (create an asset group for a PMax campaign) and adds the decisive scope detail that creation is atomic with Google's minimum asset set. This clearly separates it from siblings like ads_add_asset_group_assets, which attach assets to an existing group.

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

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

Explicitly routes the agent to ads_create_text_assets and ads_upload_image_asset for obtaining required asset IDs, and names validate_only=True for a dry run. It never states exclusions (e.g. that the campaign must already exist or that this isn't for adding incremental assets), so it stops short of a 5.

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

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

Beyond the annotations (destructiveHint=false), it discloses that the campaign defaults to PAUSED, that budget is newly created, that unsupported channels return {error: unsupported_channel, hint}, that PMax final-URL-expansion cannot be disabled via API, and that campaigns are created without EU political advertising. These are exactly the side effects and limitations an agent 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?

Every sentence carries operational information and the critical facts (purpose, default PAUSED status) are front-loaded. It is dense and somewhat run-on in the network/PMax paragraph, which slightly hurts scanability, but nothing is filler.

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

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

For an 11-parameter mutation tool with an output schema present, the description covers the full lifecycle: creation semantics, default state, per-parameter constraints, rejection behavior, and required follow-up calls for PMax. An agent can call this correctly without consulting anything else.

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

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

Schema coverage is 0%, so the description must carry all parameter meaning — and it does: enumerated channel_type values with SHOPPING exclusion, bidding_strategy options with the PMax constraint, the fact that target_cpa_eur/target_roas are ignored outside their matching strategies, defaults for the three network flags, and the PMax caveat that networks don't apply.

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

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

The first sentence states a specific verb and resource ('Neue Kampagne anlegen') and adds the important detail that a campaign-owned budget is created with it. It is clearly distinguishable from sibling tools like ads_update_campaign_settings or ads_create_ad_group.

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

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

It gives concrete conditional guidance: SHOPPING is rejected before the API call, PMax requires calling ads_create_asset_group + ads_add_asset_group_signal afterwards, and workspace may be omitted when only one exists. It stops short of explicitly naming when to use update vs. create alternatives, but the creation context is unambiguous.

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

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

Annotations already establish write (readOnlyHint=false), non-destructive, open-world. The description adds genuinely non-obvious behavior: setting default_value forces always_use_default_value and causes supplied tag/upload values to be ignored, plus the dry-run semantics of validate_only. It does not mention permissions or whether duplicates are rejected, which keeps it below 5.

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

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

Front-loads the purpose and the downstream-linkage in the first two lines, then one line per parameter — dense and scannable. It is longer than average, but nearly every line contributes enum or constraint information that the schema lacks; only the trailing workspace note is filler-ish.

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?

Seven parameters with zero schema coverage and a real create operation; the description covers six of them with values and side effects, explains the dry-run flag, and a rich output schema exists so return shape needn't be restated. An agent has what it 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?

Schema description coverage is 0%, so the description must carry the parameter burden and largely does: it enumerates category values (QUALIFIED_LEAD, LEAD, PURCHASE, SIGNUP, SUBMIT_LEAD_FORM), type values (UPLOAD_CLICKS/WEBPAGE), counting_type values, and explains the default_value/always_use_default_value interaction. Only 'name' is left undocumented, which is partly implied by the example but is the single required parameter.

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

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

States a specific verb+resource ('Legt eine neue Conversion-Aktion an') with a concrete example, and immediately ties the output artifact (resource name/ID) to the follow-up tool ads_upload_conversions. That distinguishes it from ads_update_conversion_action and ads_list_conversion_actions without requiring the schema.

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

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

Gives actionable when-to guidance for two parameters: default_value should be omitted when real per-conversion values are booked via ads_upload_conversions, and validate_only=True is the dry-run path. It does not explicitly name ads_update_conversion_action as the alternative for modifying an existing action, so it stops short of full alternative routing.

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

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

Annotations declare non-read-only, open-world, non-destructive. The description adds real context beyond that: the account must be eligible for Customer Match (policy/history prerequisites) and the tool returns a user-list ID and resource name. It doesn't detail failure modes or rate limits, but for a create-list tool this is substantial 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?

Front-loaded with the core action and return, then purpose, then prerequisites, then params. Well organized with no filler, though it is on the longer side; the parameter list is arguably redundant with a well-described schema but necessary here given 0% coverage.

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 4-param create tool, it covers purpose, alternatives, prerequisites, all parameters including a constraint, and return identifiers. An output schema exists, yet the description still names the returned ID/resource — an agent has everything needed to call it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning — and it does: name (display name), description (optional), membership_life_span_days (with the max 540 constraint not in the schema), and workspace (optional when only one workspace). All four parameters are explained, compensating fully for the schema gap.

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

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

States a specific verb (legt... an = creates) and resource (CRM-basierte Customer-Match-Userliste), names the CONTACT_INFO type, and even discloses the return values (User-List-ID + Resource-Name). It explicitly distinguishes itself from ads_list_customer_match_lists by directing users there to find existing lists.

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?

Explains the purpose of Customer Match, states that the resulting ID serves as 'audience_id' for ads_upload_customer_match_members and ads_remove_customer_match_members, points to ads_list_customer_match_lists for lookup, and gives the eligibility prerequisite. When-to-use and alternatives are all explicit.

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

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

Annotations only say it's a non-read-only, open-world, non-destructive write. The description adds real behavioral detail beyond that: pre-validation of character limits, the specific error code text_too_long, the partial-failure mode link_failed that still returns an asset_id, and the correct recovery action. It also notes workspace may be omitted when only one exists.

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

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

Dense but front-loaded: creation and linking rule first, then constraints, then response and failure recovery. Every sentence carries information, though restating the response fields (status/asset_id/linked_to) is slightly redundant given an output schema exists.

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 6-parameter mutation with zero schema documentation coverage, the description supplies limits, level selection, partial-failure semantics, and recovery routing. An agent can invoke this correctly and handle the main failure mode without further exploration.

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

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

Schema description coverage is 0%, so the description carries the burden and largely meets it: max lengths for link_text and description1/2, the meaning of campaign_id (omitted = account level), and the semantics/default of workspace. The one gap is final_url, whose expected format (full URL with protocol, landing page requirements) is not explained anywhere.

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 a sitelink asset) plus the scope decision (link to campaign via campaign_id, otherwise account level). This cleanly distinguishes it from ads_update_sitelink (modify) and ads_link_asset (link-only, which it explicitly names).

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

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

Gives the branching rule for campaign vs account level ('Ohne campaign_id Konto-Ebene') and an explicit alternative path: if only linking fails, call ads_link_asset(asset_id, 'SITELINK') rather than recreating. That is exactly the when/when-not/alternative guidance an agent needs.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so safety is partly covered. The description adds genuinely non-obvious behavior: per-asset character limits (30/90) that act as validation constraints, and the fact that the asset carries no role until linked — context an agent would otherwise get only after a failed call.

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/paragraphs with zero padding: the core action and limits come first, the workspace caveat second. Both sentences carry information not present elsewhere.

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

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

For a two-parameter mutation tool with an output schema and safety annotations, the description covers the essential unknowns (what counts as a valid text, when workspace is required, that role assignment happens later). Only batch-size and duplicate handling are absent, which is minor.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the workspace parameter as a slug that is optional when only one workspace exists, and the character limits implicitly constrain the texts array, but it never says how many texts can be passed per call or whether duplicates are rejected.

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 (anlegen/create) and resource (wiederverwendbare Text-Assets) and adds the distinctive constraint that role is only assigned later via field_type at linking, which separates it from role-specific siblings like ads_create_ad. It does not name a sibling tool directly, 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?

The note that field_type is set when linking implies this tool must be followed by a linking step (ads_link_asset / ads_add_asset_group_assets), but no explicit when-to-use/when-not guidance or named alternative is given. Usage is inferable rather than stated.

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

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

Annotations only supply readOnlyHint/openWorldHint; the description adds substantial behavior beyond them: only campaign types with ad groups are included (Search/Display/Video), PMax is excluded, today is excluded from the day range, and totals are explicitly NOT account totals. It also documents the report shape and the UNDETERMINED bucket semantics — rich context an agent cannot get from the annotations.

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

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

Front-loaded with purpose, then scope constraints, then return shape. Dense but each line carries information; the return-structure detail is partly redundant given an output schema exists, which keeps it from a 5.

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

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

For a read-only analytics tool with two params, it covers scope limitations, exclusion of PMax, alternative for account totals, and bucket semantics. Even though an output schema exists, the added explanation of UNDETERMINED buckets and non-account-total sums is decision-critical and 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 0% schema description coverage, the description must carry the burden and does: 'days' is defined as last N days excluding today, and 'workspace' as the customer workspace slug, optional when only one workspace exists. Both parameters gain meaning beyond their bare types, though exact date anchoring for days could be sharper.

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

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

States the specific resource (performance by age and gender) and its intended use (basis for B2B exclusions), then immediately distinguishes it from ads_campaign_performance for account totals. An agent can differentiate it from device/geo/schedule performance siblings by the dimension named.

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

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

Explicitly names the alternative for account-level totals (ads_campaign_performance) and states the use case (B2B exclusions). However, it does not state when to prefer this over ads_device_performance or ads_geo_performance when an agent wants a broad breakdown, so a small inference gap remains.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds real value on top with the reporting-window rule (complete days only, today excluded) and the definition of Conversions as primary/bid-relevant conversions. It says nothing about latency, rate limits, or empty-result behavior, so it is not fully transparent.

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

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

Three compact sentences, front-loaded with the resource and metrics before the time-window and workspace caveats. The nested parentheticals make it dense 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 read-only, two-parameter report with an output schema, the description covers what an agent needs: which dimension is broken out, which metrics come back, how the date window behaves, and how to resolve the workspace. Return-value structure is correctly left to the output schema.

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

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

Schema coverage is 0%, so the description must carry the load and largely does: it explains the `days` window semantics (last N complete days, today excluded) and defines `workspace` as a customer-workspace slug that is optional when only one workspace exists. The default value of 30 for `days` is never mentioned, leaving a small gap.

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

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

The description names a specific report and its breakdown dimension ("Performance nach Gerätetyp (Mobile, Desktop, Tablet)") plus the exact metrics returned, which implicitly separates it from ads_campaign_performance, ads_demographic_performance and ads_geo_performance. It never names a sibling or states which one to pick instead, so it stops short of the top score.

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 implied by the window definition ("letzten N Tage, vollständige Tage bis gestern, heute nicht enthalten") and the note that workspace is optional for single-workspace accounts. There is no explicit when-to-use/when-not guidance and no routing to alternative performance tools for other breakdowns.

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 flag destructiveHint=true and openWorldHint=true, so the safety profile is carried by structured data. The description adds the workspace-optionality rule but says nothing about irreversibility, whether a dismissed recommendation can be restored, or permission requirements — modest value on top of annotations.

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

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

Two short lines, zero filler, with the core action first and the parameter notes second. Nothing could be removed without losing 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?

Only two parameters and an output schema exists, so return values need no explanation; both params are covered in the text. For a destructive mutation the description could still say more about consequences, but annotations cover the safety signal.

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

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

Schema coverage is 0%, so the description must carry both parameters, and it does: resource_name is sourced from ads_list_recommendations, and workspace is described as optional when only one workspace exists. It lacks any format/identifier detail for resource_name beyond the source tool.

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

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

States a specific verb ('verwerfen'/dismiss) plus a specific resource ('Google-Ads-Empfehlung'), so an agent knows exactly what the tool does. It doesn't explicitly contrast with the natural sibling ads_apply_recommendation (accept instead of dismiss), which keeps it 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?

Points the agent to ads_list_recommendations as the source of resource_name, which is real workflow guidance rather than none. It never states when to dismiss vs. apply a recommendation or any prerequisite, so the exclusion side is only implied.

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

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

Annotations already cover safety (readOnlyHint) and open-world scope, so the bar is lower; the description still adds real behavioral context: the window means full days through yesterday with today excluded, results are sorted by cost, and 'Conversions' means primary bid-relevant conversions. That is exactly the kind of semantic detail annotations cannot express.

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

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

Front-loaded with the resource and grain, then the time-window rule, sort order, conversion definition, and the parameter note — no filler. Slightly dense and parenthetical-heavy, but every clause carries information an agent 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?

With an output schema present, return shape need not be described; combined with the readOnly annotation and both parameters explained, an agent has enough to call this correctly. The only gap is no disambiguation from sibling performance tools or geo-targeting 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?

Schema description coverage is 0%, so the description carries the load and does compensate: 'days' is defined as the last N full days ending yesterday (today excluded), and 'workspace' is explained as the client workspace slug, optional when only one workspace exists. Only the default of 30 days is left to the schema.

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

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

States a specific resource and grain: Google Ads performance broken down by country ('nach Standort (Land)'), with the metric set enumerated. An agent can tell it is a geo reporting tool, distinct from siblings like ads_get_geo_targeting, though the description never explicitly names that distinction.

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 by the reporting nature (get metrics per country over a window) and the workspace note explains when the workspace param can be omitted. However, there is no explicit 'use this instead of X' routing versus ads_campaign_performance, ads_device_performance, or ads_get_geo_targeting.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing a hard limitation (proximity/radius targets are not returned), warning that locations=[] does not imply worldwide coverage, and prescribing a verification path. These are exactly the caveats that prevent an agent from drawing a wrong conclusion from an empty result.

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

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

Front-loaded with the resource and its two components, and every clause carries information. The dense parenthetical plus em-dash asides make it slightly harder to parse than it needs to be, but nothing is padding.

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

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

An output schema exists, so return shape is covered elsewhere; the description still covers filter behavior, the coverage limitation, and the workspace parameter. The remaining hole is campaign_id format and multi-campaign behavior, which an agent needs in order to call it correctly.

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

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

Schema coverage is 0%, so the description must carry the burden. It does well for workspace ('Slug des Kunden-Workspace, optional bei nur einem Workspace') but only alludes to campaign_id via 'Optional auf eine Kampagne gefiltert' without saying whether it takes the numeric ID, resource name, or a list.

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 resource and scope: per-campaign geo targeting, covering both the location criteria and the PRESENCE vs PRESENCE_OR_INTEREST setting. It clearly reads settings rather than performance (unlike ads_geo_performance) and clearly does not write (unlike ads_update_geo_targeting), though it never names those siblings explicitly.

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

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

Gives real usage context: the campaign filter is optional, PRESENCE_OR_INTEREST is flagged as the usual cause of geo-leakage, and the agent is told to cross-check in the Google Ads UI when in doubt. No explicit when-not-to-use or named alternative tool, so not a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a non-obvious result-set behavior: campaigns without any language criterion (= all languages) are omitted entirely, and an empty array under a campaign_id is genuinely ambiguous (all languages OR unknown campaign). That is exactly the kind of trap an agent needs warned about before interpreting output.

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

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

Front-loads the action, then the filtering caveat, then the ambiguity warning, then the parameter note. Every sentence adds decision-relevant information with no padding.

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

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

Output schema exists, so return values need no explanation here; the description instead covers the things structured fields cannot: omission semantics, ambiguity of empty results, and workspace optionality. Nothing needed to call or interpret it correctly is missing.

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

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

Schema coverage is 0%, so the description carries the burden: it explains that workspace is a customer-workspace slug and optional when only one workspace exists, and it explains campaign_id's filtering semantics plus the ambiguity of []. It stops short of giving the identifier format for campaign_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+resource ('Sprach-Targeting je Kampagne lesen') with explicit scope (per-campaign, optionally filtered). It is clearly distinguished from the sibling ads_update_language_targeting by the read framing, and from ads_list_campaigns which is named as a different tool for verification.

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

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

Gives clear context for when to call it (reading language criteria, optionally per campaign) and names ads_list_campaigns as the cross-check when an empty result is ambiguous. It does not explicitly say when to prefer a different tool (e.g., ads_update_language_targeting for writes), but the usage context is unambiguous.

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

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

Annotations already mark this readOnly/openWorld, and the description layers substantial extra context: the window excludes today, deleted campaigns/ad groups/keywords are filtered out on all levels, lost_to_budget_pct is rejected above campaign level, hitting limit returns a result+warning object instead of the full list, and Google caps values (10.0 = '<10%', 90.0 = '>90%', null when unavailable). That is exactly the kind of behavior an agent cannot get from the schema.

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

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

Front-loaded with the single-sentence definition, then per-parameter blocks — each block earns its place and the error codes are actionable. It is long, and the capping rule is stated twice (once in prose, once by noting the repeated `note` field), which is mild redundancy but defensible as reinforcement.

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 7-parameter analytics tool with an output schema, everything an agent needs to call it correctly is present: valid level values, filter preconditions and their error identifiers, truncation semantics, aggregation caveat, and value capping. Return-field documentation goes beyond what the output schema alone would convey.

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

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

Schema description coverage is 0%, so the description must carry all seven parameters — and it does: level with its three literal values and default, keyword as a case-insensitive substring with a worked example and the invalid_keyword_filter guard, limit with per-level defaults (all campaigns vs 100 vs max 200), campaign_id/ad_group_id scoping with their error codes, and workspace optionality for single-workspace accounts. Only the `days` parameter is described implicitly ('letzten N Tage') rather than by name.

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

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

States a precise resource and scope: Search-network-only impression share (explicitly excluding Display/PMax) for the last N days up to yesterday, segmented by campaign, ad group, or keyword. It also enumerates the exact metrics returned (impression_share_pct, top/abs-top IS, lost_to_rank_pct, etc.), which makes it unmistakable against generic siblings like ads_campaign_performance or ads_keyword_performance.

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

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

Gives clear conditional guidance: ad_group_id only works from level='ad_group' (else ad_group_needs_finer_level), keyword requires level='keyword' (else keyword_needs_keyword_level), and it explicitly instructs to query level='campaign' for a correct aggregate because averaging keyword rows is invalid. It never names a sibling tool as the alternative, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description goes beyond them with the top-50-by-cost cap, the exclusion of today from the window, the quality_score 1-10/'N/A' semantics, and the definition of conversions as primary/bid-relevant. These are exactly the behavioral facts an agent needs. It stops short of describing pagination or ordering ties.

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

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

The description leads with what the tool returns and the time window, then adds caveats, alternatives, and parameter notes. It is dense but every sentence carries information. Some subject changes (QS scale, conversions definition, workspace) make it a bit choppy and it mixes German and English.

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

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

With an output schema present, the description need not enumerate return fields, and it still covers the key semantics (top-50 ranking by cost, QS range, conversions meaning). Combined with the annotations and sibling routing, an agent has enough to call it correctly, though the default day count is missing.

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

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

Schema coverage is 0%, but the description compensates: 'days' is explained as the last N days through yesterday (today excluded) and 'workspace' as the customer workspace slug that is optional when only one workspace exists. Neither parameter has a schema description, so this added meaning is valuable. A 5 is held back only because the default (14) is not acknowledged.

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 with scope: 'Top 50 Keywords nach Kosten der letzten N Tage bis gestern', listing what is included (Quality Score, CPC, Conversions). It distinguishes itself from ads_list_keywords by explicitly saying it is not a complete dump. An agent can tell exactly what this returns.

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

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

Explicitly names the alternative for full coverage ('für alle Keywords ads_list_keywords') and routes QS component questions to ads_keyword_quality. The 'bis gestern (heute nicht enthalten)' boundary clarifies when the window applies.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond the annotations: only keywords in ENABLED campaigns, restricted to the 100 highest-impression keywords, and the reporting window excludes today. This materially changes what results an agent should expect.

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

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

Front-loaded with the metric components, followed by scope, return fields, and parameter notes — every block earns its place. The line-wrapped pseudo-structure makes it slightly harder to scan than a clean sentence flow, but there is no filler.

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

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

For a two-parameter read-only reporting tool it covers everything an agent needs: population filters, time window semantics, per-parameter meaning, and result shape (quality_score 1-10, three enum components, impressions, clicks) even though an output schema already exists. Nothing essential to calling it correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely does: 'days' is defined as a lookback period with default 30 and today excluded, and 'workspace' is described as a customer slug that can be omitted when only one workspace exists. Minor gaps remain (no upper bound on days, no format example for the slug).

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 resource (Quality-Score-Komponenten je Keyword) plus the three metric components and the analytical intent (Landingpage-Arbeit). An agent can tell this is a keyword-level quality diagnostics tool rather than a mutation or listing tool. It does not, however, differentiate itself from the closely related ads_keyword_performance 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 'für gezielte Landingpage-Arbeit' implies the intended use case, and the scope line (only ENABLED campaigns, top 100 by impressions) hints at when the tool fits. But there is no explicit when-to-use/when-not framing or a named alternative such as ads_keyword_performance or ads_list_keywords, which an agent must infer.

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

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

Annotations already establish that this is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description's job is to add link semantics. It does clarify that the operation reuses an existing asset rather than creating one, and that the target can be the account rather than a campaign, but it says nothing about idempotency, what happens if the link already exists, or what permissions are required.

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 text is short and front-loaded: the core action and the duplicate-avoidance rationale come first, followed by field_type examples and the workspace note. A few parenthetical asides and a line break inside a sentence slightly interrupt the flow, 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?

There is an output schema, so return values need not be described, and the safety profile comes from annotations. However, for a 4-parameter mutation with 0% schema coverage, the omission of what asset_id expects and the explicit rule for when campaign_id should be omitted leaves a real gap for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it only partially compensates: it explains field_type with concrete enum-like examples and explains that workspace is optional when there is a single workspace. It never explains asset_id, and it only implies (rather than states) that campaign_id is optional and that omitting it links at the account level.

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 ('Bestehendes Asset ... mit einer Kampagne oder dem Konto verknüpfen') and adds the key differentiator, 'statt ein Duplikat anzulegen', which distinguishes it from the create-style siblings such as ads_create_sitelink. It does not name the closest siblings (ads_unlink_asset, ads_create_sitelink) explicitly, so the differentiation is implied rather than spelled out.

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

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

The description implies when to use it (reuse a shared asset instead of duplicating it) and gives examples of valid field_type values, but never states an explicit when-not-to-use condition or names the alternative tools. An agent still has to infer that it should use ads_create_sitelink when no asset exists.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful structural behavior beyond that: account negatives are returned as shared-set lists with a keywords array, and it distinguishes criterion_id from shared_criterion_id. It does not mention pagination or auth constraints, but with annotations and an output schema the burden is lower.

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

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

The description is short and front-loads the purpose. Each sentence adds useful information about the data model, sibling distinction, or parameter, though the telegraphic phrasing and line breaks make it slightly less polished.

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

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

Given the presence of an output schema and annotations covering the read-only/open-world behavior, the description supplies everything essential: purpose, data-model interpretation, sibling pointer, and the sole optional parameter. 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?

There is only one parameter, workspace, and schema description coverage is 0%. The description fully compensates by defining it as the customer workspace slug and stating it is optional when there is only one workspace.

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: reading account-wide negatives. It also differentiates the tool from campaign/shared-list contexts and explains the key data model, so an agent can identify it without opening the schema.

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

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

It gives some usage context by noting it is for account-level negatives and points to ads_manage_shared_negative_list for distinction. However, it does not clearly name ads_list_negative_keywords for campaign-level negatives or ads_manage_account_negatives as the write counterpart, and the one alternative it names may be confusing.

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 already declaring a safe read, the description adds real behavioral context: removed ad groups and groups of removed campaigns are filtered out, and campaign_status is returned to signal inherited campaign state (an ENABLED group under a PAUSED campaign is not running). That is non-obvious semantics an agent could not infer from the schema.

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

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

Five short sentences with no filler, front-loaded with the purpose and filter, followed by the filtering caveat and parameter note. Tight and readable, though the campaign_status remark reads slightly like a data-model aside rather than invocation 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?

An output schema exists so return values need not be described, and the description covers purpose, filtering, hidden records, the campaign_status nuance, and the workspace parameter. The main residual gap is not naming campaign_id as the filter input and its format.

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

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

Schema coverage is 0%, so the description must carry the load. It explains the workspace parameter well (customer workspace slug, optional when only one workspace exists), but campaign_id is only implied by 'nach Kampagne filtern' — its name and accepted format are never stated.

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 ('Ad Groups auflisten') plus the scoping capability ('optional nach Kampagne filtern'), which distinguishes it from write siblings like ads_create_ad_group. It does not explicitly differentiate from other list tools such as ads_list_campaigns or ads_list_ads, but the resource 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?

Usage is implied: use it to enumerate ad groups, optionally narrowed by campaign. There is no explicit statement of when to prefer this over ads_list_campaigns or ads_list_ads, and no prerequisites or exclusions beyond the note that removed groups are hidden.

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/openWorldHint; the description adds substantial behavior: a hard 100-ad limit with no truncation indicator, silent hiding of REMOVED ads and ads under removed groups/campaigns, and that ad_group_status/campaign_status reveal paused parents that keep an ENABLED ad from serving. These are exactly the traps an agent needs disclosed.

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

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

Front-loaded with the resource and returned fields, and every sentence carries operational information. It is dense and packs several facts per sentence, making it slightly harder to scan, but nothing is filler.

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

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

An output schema exists, so return values need no explanation, and the description still covers the field set, the result cap, filtering strategy, removal/parent-status edge cases, and the PMax exception. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the burden and does explain all three parameters: workspace is a customer slug optional when only one workspace exists, and campaign_id/ad_group_id are scoping filters for large accounts. It stops short of stating ID formats or precedence when both filters are supplied, which is the remaining gap.

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

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

States a specific verb and resource ('Anzeigen auflisten') and enumerates the returned fields (Headlines, Descriptions, URLs, Status, Approval). It explicitly distinguishes itself from the sibling ads_list_asset_groups for PMax campaigns, so an agent can tell the two apart without opening a schema.

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

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

Gives concrete when-to-use guidance: narrow with campaign_id or ad_group_id on larger accounts because of the 100-ad cap. It also names the alternative tool for PMax (ads_list_asset_groups) and the condition that selects it, plus the workspace-optional case.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by naming the returned dimensions (status, ad strength, per-field_type asset coverage) and by explaining the single-workspace default for the workspace argument. No contradiction with annotations.

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

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

Two short sentences: the core action and returned fields come first, then the filter and workspace caveat. Every clause carries information and nothing is 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?

An output schema exists, so return shape need not be specified, yet the description still previews the key fields. For a two-optional-parameter read-only listing tool with annotations covering safety, the definition is sufficient; only the campaign_id format remains underspecified.

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

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

Schema description coverage is 0%, so the description carries the burden and largely meets it: it explains workspace as a customer slug that may be omitted when only one workspace exists, and frames campaign_id as an optional campaign filter. The remaining gap is that the expected campaign_id format (bare ID vs. resource path) is never stated.

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 ('Asset Groups (PMax) ... auflisten') and enumerates what comes back (status, ad strength, asset coverage per field_type), which separates it from ads_list_assets and ads_create_asset_group. It stops short of explicitly contrasting itself with the closer analytics siblings such as ads_asset_group_performance.

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

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

The clause 'optional auf eine Kampagne gefiltert' gives a usable context hint for the main optional parameter, and the workspace note explains when it may be omitted. There is no explicit when-to-use versus ads_asset_group_performance or ads_create_asset_group, so the routing guidance is only implied.

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

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

Annotations already mark this as read-only, but the description adds important behavioral detail beyond them: which asset types return text fields, which only return linking metadata, and the caveat that an empty linked_to does not mean unlinked because ad-group links are not included. It also discloses that each link carries ENABLED/PAUSED/REMOVED status.

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

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

The first sentence front-loads the core operation, and every subsequent line adds useful filtering, return-shape, or linking semantics. There is no filler.

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

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

Although an output schema exists, the description still provides important context about result differences by asset_type and linked_to caveats. Combined with the annotations, an agent has enough information to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden. It lists all asset_type values and explains the workspace parameter's optional behavior when only one workspace exists, adding meaning not present in the schema.

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

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

The description states a specific verb and resource: listing extension assets with approval status and links. It also names the tool whose toggled status values are exposed (ads_set_asset_link_status), helping separate this read operation from link-management siblings.

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

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

It clearly explains the asset_type filter values and notes that workspace is optional when only one workspace exists. It also links the returned status values to ads_set_asset_link_status, giving practical context for follow-up actions, though it does not explicitly state when not to use this tool versus other list tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral scope: what is included, what is excluded, and the limitation that PMax asset-group signals currently have no reading tool and must be checked in the Google Ads UI.

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 purpose is front-loaded, followed by relevant exclusions, then the workspace note. The parenthetical about PMax is slightly long but earns its place by preventing a likely wrong-tool 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?

The tool is low-complexity with one optional parameter, read-only annotations, and an output schema. The description covers the resource scope, exclusions, the missing PMax-read path, and the only parameter, leaving no major gap for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the burden for the single optional parameter. It explains that workspace is the customer workspace slug and that it is optional when only one workspace exists, which adds meaning beyond the schema.

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

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

The description names the specific resource (Zielgruppenlisten/User Lists) and the exact granularity (USER_LIST criteria at campaign/ad group level). It also distinguishes the tool from adjacent audience categories and PMax signals, so an agent can identify what data this tool returns.

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

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

It gives explicit exclusions for PMax asset-group signals and interest/in-market/custom audiences, and points to ads_add_asset_group_signal for writing PMax signals. It does not explicitly contrast with ads_list_customer_match_lists, but the main use/not-use boundaries are clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral context about what the read returns (biddable flags per category, optional custom goal), but says nothing about error behavior when no custom goal exists or rate/permission constraints.

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 compact sentences front-load the purpose, with the parameter note last – well ordered and free of filler. Mixing German prose with an otherwise English toolset slightly taxes parsing but does not add length.

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

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

An output schema exists, so return values need no explanation, and the tool is read-only. Still, with zero schema description coverage, leaving campaign_id undefined and omitting how the read behaves when no custom goal is configured leaves an agent to infer too much.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the workspace parameter (customer workspace slug, optional when only one workspace exists), but campaign_id is never described in prose and only inferable from the tool name.

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: read a campaign's conversion goal configuration, including standard goals (biddable per category) and any set custom goal with its actions. This clearly distinguishes it from the mutating sibling ads_set_campaign_conversion_goals, though that sibling is never named.

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: this is the read counterpart to the setter, and the workspace note hints at a pre-readstep. There is no explicit 'use this when…' or 'do not use for modifying goals – use ads_set_campaign_conversion_goals' guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description goes beyond that by disclosing the implicit status filter (REMOVED suppressed) and a cross-tool consistency guarantee with ads_list_ad_groups/ads_list_keywords/ads_list_ads. It says nothing about result volume, pagination, or cost/rate behavior for a live Google Ads API call, which is the remaining gap.

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

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

Three sentences, front-loaded with the action and returned fields, then the status filtering rule, then the cross-tool consistency note, then the parameter. No sentence is redundant and no padding is present.

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

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

An output schema exists, so return-value shape need not be explained; the description covers scope, filtering, cross-tool consistency and the only parameter. What remains unstated is whether results span all campaigns in the account/workspace on a single call or require paging — minor for a read-only list tool but relevant to agents planning a full inventory.

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

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

Schema description coverage is 0%, so the description must carry the meaning of the single parameter — and it does: 'workspace: Slug des Kunden-Workspace (optional bei nur einem Workspace)' explains both the value format (slug) and the optionality condition. That is meaningful compensation for the schema gap, though it does not explain resolution behavior when multiple workspaces exist.

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

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

States a specific verb and resource (list all Google Ads campaigns) and immediately enumerates what comes back (name, status, budget, channel type, bidding strategy). It is clearly distinguishable from sibling list tools such as ads_list_ad_groups, ads_list_ads and ads_list_keywords because it explicitly defines the parent/child relationship 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?

Gives concrete inclusion/exclusion rules: ENABLED and PAUSED are returned, REMOVED campaigns are hidden — exactly the question an agent asks before calling a list endpoint. It also explains how results line up with the child-list tools. It does not name alternatives (e.g. ads_campaign_performance for metrics, ads_list_experiments), so routing guidance is clear but not exhaustive.

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

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

Goes well beyond readOnlyHint/openWorldHint: it discloses the data window (last N days up to yesterday, today excluded), the counting basis (all_conversions by conversion date, offline imports attributed to the conversion day rather than the click day), the dynamic field naming conversions_{N}d, and that import/app conversions return None for conversion_id/label.

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

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

Front-loads purpose, then the counting caveat, then the ID/label hand-off to other tools — the ordering is sensible and sentences are information-dense. It is somewhat overloaded, mixing GTM tag setup guidance into a listing tool's definition, and the stray line break adds noise.

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?

Even though an output schema exists, the description supplies the semantics an agent needs to interpret it (which counting basis, what None means, how the dynamic field is named) plus the workspace requirement. Nothing material 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?

Schema description coverage is 0%, so the description carries the burden and does so: 'days' is defined by the window semantics (up to yesterday, today excluded) and echoed in the output field naming, and 'workspace' is explained as an optional customer slug when only one workspace exists. Only the default of 30 is left implicit via the conversions_30d example.

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 ('Alle Conversion-Aktionen') and enumerates returned fields (Status, Typ, Kategorie, Conversions, letztes Conversion-Datum). It also scopes the time window, which distinguishes it from the campaign-level conversion tools in the sibling list.

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

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

Explicitly frames the use case ('deckt totes Tracking auf') and warns that the click-dated numbers from the campaign tools are not directly comparable, which effectively routes the agent. It also names the downstream consumers (ads_update_conversion_action, ads_upload_conversions, gtm_create_tag) but stops short of saying when another listing tool should be preferred instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the returned field set (id, name, type, Display/Search size, membership duration), but says nothing about pagination, result limits, or permissions beyond what annotations and the output schema already provide.

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

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

Front-loaded with the purpose, then the return contents, then the one parameter — a sensible order. It is compact, with only mild redundancy in restating field names the output schema likely 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 single-parameter read-only listing with an output schema, the description covers purpose, returned fields, and the parameter's optionality. Missing only pagination/volume expectations, which are minor here.

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

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

Schema coverage is 0%, so the description carries the burden and does so: it explains that workspace is a customer-workspace slug and that it may be omitted when only one workspace exists. That is genuine meaning beyond the bare string type, though no format example or failure behavior is given.

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: listing the account's CRM-based Customer Match user lists. It also gives a downstream intent (locating 'audience_id' for up-/downloads), which implicitly separates it from ads_list_audiences and ads_create_customer_match_list, though no sibling is named 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?

The description makes the use case clear: find the audience_id needed before uploading or removing members. It also notes the workspace param is optional when only one workspace exists, which is real invocation guidance. It stops short of explicitly excluding alternatives such as ads_list_audiences.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read nature is covered. The description adds that returned experiments include status and runtime, which gives useful return context beyond the annotations. It says nothing about pagination, empty results, or permissions, so it only modestly adds 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?

Two short sentences with no filler and the purpose front-loaded. However, it is sparse to the point that no real usage or behavioral context is provided — the brevity is as much under-specification as efficiency.

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

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

Output schema exists, so return values needn't be fully explained, and the single parameter is addressed. Still missing scope (all experiments in the account vs. per campaign) and any sibling differentiation for an agent navigating a very large toolset.

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

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

Schema description coverage is 0%, so the description must carry the one parameter — and it does: 'workspace: Slug des Kunden-Workspace (optional bei nur einem Workspace).' That explains what the param is and its optionality condition, compensating for the schema gap. It doesn't give format examples or how to discover the slug, keeping it at a solid 3.

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

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

Written in German, it uses a clear verb+resource: it lists campaign experiments (A/B tests) with status and runtime. There is no sibling tool for experiments, so no disambiguation is needed among the 180+ siblings. Lacks scope detail (which campaign, whole account), preventing 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?

No indication of when to use this versus ads_list_campaigns or the other list tools, no prerequisites, no exclusions. The agent must infer from the name alone whether listing experiments is the right action.

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

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

Beyond the readOnly/openWorld annotations, the description discloses the truncated response shape ({result, warning}) and what triggers it, that removed groups'/campaigns' keywords are hidden, that ad_group_status/campaign_status reveal paused parents (so the keyword is not serving), and that ad-group negatives appear with negative=true. This is exactly the sort of behavior an agent cannot infer from schema or annotations.

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

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

Front-loaded with the core action and filter, followed by edge-case behavior in priority order (limit, truncation, negatives, hidden entities, workspace); nearly every clause carries information. It is dense and somewhat run-on, and the German prose sits against English tool naming, which adds minor parsing overhead.

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

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

With an output schema present, the description needn't restate return fields, yet it still explains the exceptional truncated shape, which the schema likely doesn't capture. For a zero-required-parameter list tool this is close to complete; only pagination/ID-format details are absent.

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

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

Schema coverage is 0%, so the description carries the full burden and covers all four parameters: limit (default 200, max 1000, with truncation semantics), campaign_id/ad_group_id as filters, and workspace as the customer slug that is optional when only one workspace exists. It only lacks ID format conventions (e.g., raw numeric vs. resource path).

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?

"Keywords auflisten" gives a clear verb+resource, and the mention that ad-group negatives are included (flagged negative=true) implicitly delineates it from ads_list_negative_keywords. It stops short of naming sibling alternatives explicitly, so differentiation is inferable 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?

Useful operational guidance is given for the truncation case (narrow by campaign_id/ad_group_id or raise limit), which tells the agent how to recover. However, there is no explicit statement of when to prefer this tool over ads_list_negative_keywords or ads_keyword_performance, or which filter to use first.

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

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

Beyond the readOnlyHint annotation, it discloses two important behaviors: results are truncated at the limit and, when truncation occurs, the tool returns an object with 'result' and 'warning' instead of a plain list. It also explains why the limit exists (accounts accumulate hundreds of negatives, full dumps crowd out the agent's context), which is genuine operational context not present in the annotations.

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

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

Front-loaded with the core purpose and scope exclusions, then parameter notes. It is somewhat wordy (the rationale for the limit spans several clauses) but every part is informative and nothing is redundant with the schema.

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

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

An output schema exists, so return values need not be restated, and the description still adds the non-obvious truncation/warning return shape. Combined with scope exclusions, alternative tools, and parameter notes, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning: it explains 'limit' (max entries, default 200, truncation consequence) and 'workspace' (customer workspace slug, optional when only one workspace) well. 'campaign_id' is only covered implicitly through 'optional nach Kampagne filtern' – the role is clear but the parameter is not named and no format is given.

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 ('Negative Keywords auflisten') and immediately narrows scope to campaign-owned negatives only. It explicitly names the sibling tools that handle the excluded cases (ads_manage_shared_negative_list, ads_list_account_negatives), so an agent can distinguish this tool from its neighbors without opening schemas.

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

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

Gives explicit routing: use this for campaign-level negatives, use ads_manage_shared_negative_list for shared-list metadata (and notes list contents are UI-only), use ads_list_account_negatives for account-wide negatives. The optional campaign filter and the limit guidance make the intended usage conditions unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that only *open* (unresolved) recommendations are returned and that resource_name is the handle for apply/dismiss, which is genuinely useful chaining context, though return-shape detail is largely redundant against the existing output schema.

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

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

Two compact sentences: purpose and returned fields first, parameter note second. No filler, and the most decision-relevant information is front-loaded.

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

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

For a one-optional-parameter read tool with annotations and an output schema, the description covers purpose, follow-up chaining, and the only parameter's meaning. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 0%, so the description must carry the single parameter, and it does: workspace is the customer workspace slug, optional when the account has only one workspace. That adds format and optionality semantics the bare string|null schema lacks.

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

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

States a specific resource and scope: open Google Ads recommendations for the account, and names the fields surfaced (type, affected campaign, resource_name). An agent can distinguish this from ads_list_campaigns or ads_change_history without opening the schema.

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

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

The parenthetical ties the output to the follow-up tools ads_apply_recommendation and ads_dismiss_recommendation, making this the discovery step in that workflow. It does not state explicit exclusions, but no sibling competes for the same listing job.

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

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

Beyond the destructive/openWorld annotations, the description discloses substantial side-effect semantics: auto-creation of 'Kontoweite negative Keywords (MCP)' with created_list=true, reattachment of a detached list with note=reattached_existing_list, rejection with error+foreign_lists when only a manager-account list exists, dedup via skipped, and partial_add_result notes. This is rich context the annotations cannot convey.

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

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

It is dense but front-loads the core purpose and each sentence adds distinct behavioral detail (removal semantics, auto-behaviors, dedup, error cases). Slightly long and the fields-on-return notes could be terser, but little is pure filler.

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

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

For a destructive, multi-mode mutation tool, the description covers side effects, error/edge cases, and even references the return note values (created_list, reattached_existing_list, skipped, foreign_lists), which is more than needed given an output schema exists. An agent has everything required to call it safely and interpret results.

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

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

With 0% schema description coverage, the description carries the full burden and mostly delivers: it explains the format sharedSetId~criterionId for remove_keyword_ids, the BROAD/PHRASE/EXACT values for match_type, and that workspace is optional with a single workspace. add_keywords is only implied ('beim Hinzufügen') and not described in detail, so it falls just short of complete.

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

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

The description states a specific resource (account-wide negative keywords) and the concrete operations (add, remove whole list assignment, remove individual keywords, auto-reattach, auto-create). It explicitly distinguishes itself from the sibling ads_manage_shared_negative_list for campaign-level lists, so an agent can route correctly without opening either schema.

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

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

It gives explicit when-to-use guidance for the two removal paths (remove_criterion_ids vs remove_keyword_ids), states both auto-behaviors must be announced before the call, and points to the alternative tool for campaign lists. The conditions selecting each behavior are spelled out, not implied.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds genuinely non-obvious behavior: it resolves names against Google's brand database, reuses an existing BRANDS list of the same name, and – critically – falls back to the first prefix match when there is no exact hit. It also tells the agent to verify the mapping in brands[] and to check unresolved, which the annotations could never convey.

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

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

Front-loaded with the action and purpose, then the surprising fallback behavior, then per-parameter notes – a sensible order with no filler. It is dense (German compound phrasing) and the parameter notes are appended without visual separation, but every sentence carries 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?

An output schema exists, and the description goes further by naming the exact fields to inspect (brands[], unresolved, list_created) rather than restating the return shape. For a destructive, open-world mutation with four undocumented parameters, this covers what an agent needs to call it safely and verify the result.

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

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

Schema coverage is 0%, so the description has to carry all meaning. It explains list_name (BRANDS shared set, reuse semantics, list_created flag) and workspace (optional with a single workspace), and implies brand_names/campaign_id through the resolution and attachment flow. campaign_id itself is never explicitly described, leaving one of four parameters undocumented.

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 in the first clause ('Marken als Ausschluss an eine Kampagne hängen') and adds the actual use case (PMax brand cannibalization). It implicitly separates itself from account-level siblings by scoping to a campaign and mentioning the BRANDS shared set, but it never names ads_manage_account_negatives or ads_manage_shared_negative_list as the counterpart tools.

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

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

Gives a clear use context (PMax against brand cannibalization) and explains the workspace parameter is optional when only one workspace exists. It does not state when NOT to use it – e.g. account-wide brand exclusions or editing an existing shared list – which is the main gap.

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