Adsap

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool fetches an external URL, analyzes it, and stores results for cross-session persistence. This is meaningful behavioral context beyond the schema, though it does not address potential failures, permissions, or rate limits.

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

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

Three sentences with no wasted words. The description front-loads the core action and outputs, then adds storage behavior and usage guidance. Every sentence contributes useful information.

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

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

The description covers what it does, what it extracts, storage behavior, and when to use it. With no output schema, it does not detail the exact return format, but the listed extraction categories and persistence note give an agent enough context 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 100% and the single 'url' parameter is already described with the protocol requirement. The tool description adds no additional parameter meaning beyond referring to a website URL, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb-plus-resource structure: 'Fetch and analyze a website URL,' and enumerates concrete outputs (tracking scripts, product/pricing signals, value proposition, social proof, landing page quality). This clearly distinguishes it from the many creation and retrieval sibling tools.

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

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

The description gives explicit context: 'Use as the first step in onboarding to understand a user's business.' It does not state alternative tools or when not to use it, but no sibling tool appears to compete with this website analysis purpose, so the guidance is clear enough.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals that the tool defaults to PAUSED, that dry_run renders a confirmation card, that real creation is deferred until explicit user request, and that app promotion requires specific link_url and call_to_action settings. It also explains the promoted app binding comes from the ad set. This is highly transparent 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?

The description is dense but efficient. It front-loads the primary action, then delivers critical workflow instructions and app promotion specifics. Each sentence serves a purpose, though the second sentence is long and packs multiple clauses. It could be more structured, but there is no waste.

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

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

Given the tool's complexity (nested creative_spec, many required fields, low schema coverage), the description is not fully complete. It covers the most critical aspects—the dry_run workflow and app promotion requirements—but does not explain the full creative_spec structure or how to source required IDs like ad_set_id or page_id. An agent could still be uncertain about constructing a valid request beyond the highlighted patterns.

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

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

Schema description coverage is only 13%, so the description must compensate. It adds meaning for dry_run (validate and render card), link_url and call_to_action (for app promotion), and status (defaults to PAUSED). However, it does not explain many other parameters, particularly within creative_spec (e.g., page_id, headlines, primary_texts) or how to obtain required IDs. The description adds value for critical parameters but leaves many 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 clearly states the action: 'Create a Meta ad (image/video) in an ad set.' This distinguishes it from siblings like adsap_create_ad_from_ig_post (which creates from an IG post) and adsap_create_ad_sets (which creates ad sets). It also notes the default status (PAUSED), adding specificity. The purpose is unambiguous and differentiated.

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

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

The description gives explicit, actionable usage guidance: 'ALWAYS call with dry_run: true first' and details the entire workflow—validates, renders a review card, user confirms, creates paused, activates in-card. It also states when not to call the real create ('do not call the real create from chat unless the user explicitly asks in a new message'). This is exemplary usage direction, going beyond simple 'when to use' to prescribe the exact invocation pattern.

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

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

With no annotations, the description carries full responsibility and does so thoroughly. It discloses that ads are always created paused, never spend until activated, inherit budget/targeting/schedule, do not create new entities, and that dry_run defaults to true with a clear preview-then-create flow. This is far beyond minimal transparency.

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 dense but well-structured: the core operation is front-loaded, followed by inheritance behavior, paused-by-default safety, prerequisites, dry_run sequencing, and supported media types. Every sentence earns its place and 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 tool with no output schema and no annotations, the description covers prerequisites, side effects, activation path, dry-run behavior, and exclusions. An agent has enough information to successfully select and call this tool, including how to prepare required parameters and avoid accidentally spending budget.

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

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

The schema already covers 100% of parameters, so the baseline is 3. The description adds meaningful workflow context by naming the exact list tools to resolve ad_set_id, ig_media_id, and ig_account_id, and explains the inheritance behavior that affects how parameters should be interpreted. This pushes it above baseline.

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

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

The description uses a specific verb ('Turn an existing Instagram post, video, or reel into an ad') and names the exact resource ('inside an EXISTING ad set'), clearly distinguishing it from adsap_create_ad. It also explicitly states what the tool does not do: it does not create a campaign or ad set.

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

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

The description gives an explicit workflow: pick an existing ad set with adsap_list_ad_sets, get the post id from adsap_list_ig_media, and get the Instagram account id from adsap_list_meta_assets. It also clarifies when to use dry_run twice and references adsap_set_entity_status for activation, leaving little 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?

With no annotations provided, the description carries the full burden and delivers: ad sets are created PAUSED by default, dry_run renders a launch review card and disallows the real create from chat unless conditions are met, and unsupported destinations must be redirected to Meta Ads Manager. It also discloses App promotion constraints such as Live mode, advertisability, and auto-derived user_os.

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?

Long but every sentence carries an actionable constraint: max 20, paused default, destination matrix, unsupported destinations, dry_run-first protocol, prereuisites, and App promotion rules. It is front-loaded with the core action and contains no filler or schema restatement.

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

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

For a complex batch-creation endpoint with no annotations and no output schema, the description covers all operational essentials: batch cap, default state, destination matrix, unsupported list, mandatory dry_run flow, prerequisites, and App promotion specifics. The only minor gap is an explicit description of the real-create return payload, though the card/activity-log workflow mitigates 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 coverage is 100%, so the baseline is 3. The description adds workflow-level meaning beyond the schema: ALWAYS call with dry_run true first, the App-promotion promoted_object + optimization_goal requirements, and unsupported destination handling. It does not repeat the schema's already-complete field documentation.

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+scope: create one or more Meta ad sets under an existing campaign, with a batch max of 20. This clearly distinguishes it from sibling tools like adsap_create_campaign and adsap_create_ad by anchoring on 'ad sets' and 'existing campaign'.

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

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

Offers explicit usage rules: prerequisites (list_meta_assets, list_pixel_events), a mandatory dry_run-first workflow with a precise stop-after-render instruction, and a clear list of unsupported destinations with the directive never to substitute. Also prescribes App-promotion-specific requirements.

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

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

With no annotations provided, the description carries the full disclosure burden, and it meets it admirably. It reveals the default PAUSED state, the dry-run validation and launch-review-card flow, the user-confirmation requirement, the catalog-binding behavior at the campaign level, and the conversational stop rule after the card renders. This is highly transparent about how the tool actually behaves and what side effects or UI steps to 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?

The description is front-loaded with the core purpose and then packs dense, non-obvious guidance into a compact block. Every sentence earns its place: the default status, the catalog-ads constraint, the dry-run card workflow, and the stop-and-wait rule. For a tool with 20 parameters and no annotations, this level of focused detail is appropriately sized.

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 complexity, the absence of annotations, and the lack of an output schema, the description covers the most decision-critical context: the interactive launch flow, the defaulting behavior, and the catalog requirement. It does not describe the exact shape or contents of the launch-review card or the real-create response, but the schema absorbs most parameter-level detail. A small but non-fatal 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 70%, so much parameter-level detail already exists. The description adds valuable cross-parameter semantics: the PAUSED default and ACTIVE exception, the requirement to pair advantage_catalog_ads with catalog_id for Catalog/Collection ads, the fact that the ad set needs no catalog fields while the product set is chosen at the ad level, and the dry_run-first workflow. This goes beyond what individual schema descriptions convey, though it does not comment on all parameters.

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

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

The description opens with 'Create Meta campaign' — a specific verb, platform, and resource — making it immediately clear what the tool does. It also distinguishes itself from Google campaign siblings by saying 'Meta', and from adsap_create_ad and adsap_create_ad_sets by naming the campaign resource. The added context about defaulting to PAUSED reinforces the core behavior.

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

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

It gives explicit operational directives: ALWAYS call with dry_run: true first, rely on the rendered launch review card, and do not call the real create from chat unless the user explicitly asks in a new message and the card's activity log shows nothing was created. These are strong when-to-use and when-not-to-use instructions. However, it never names sibling tools like adsap_create_ad_sets or adsap_create_ad as the alternatives for creating ad sets or ads, so the versus-alternatives guidance is only implicit.

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

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

With no annotations, the descrription carries the full burden and delivvers rich behavioral context: paginated scanning across the entire days_back window, newest-first return, the window_truncaed flag semantics including which end of the window may be incomplete, and the legacy-vocabulary translation behavior with raw values preserved in object_type_raw. It also warns that extra_data is passed through untranslated, with a concrete exammple.

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 every sentence earns its place: purpose, use case, truncaion warning, then a clearly delimited VOCABULARY section. The length is justifed by the genuinely dangerous interretation trap it previents, and the critical warnings are grouped in an easily scannable structure.

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

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

For a tool with no annotations and no output schema, the descrription covers the key operational facts an agent needs: what events are returned, the ordering, the truncaion flag semantics, and the vocabulary mapping that could otherwise cause silent misanalysis. The absence of a full response-shape listing is acceptable given the descrription already surfaces every high-risk behavioral detail.

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

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

Schema coverage is 100%, setting a baseline of 3. The descrription adds genuine value beyond the schema by explaining how limit and days_back interact (scans the whole window, then returns the newest `limit` matches) and by clarifying the meaning of a returned field (extra_data.campaign_id on a create_ad event). This goes beyond the schema's per-parameter descriptions.

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

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

States a specific verb (Retrieve) plus a precise resource (change log for a Meta ad account) and enumerates the event categories (budget changes, status toggles, ad creation/deletion, billing, policy). The 'Meta' qualifier cleanly distingushes it from the sibling adsap_google_get_account_activities, and 'change log' distingushes it from get_account_summary/health.

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

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

Provides a concrete, actionable use case: correlating performance drops with specific modifications (CPA spiked after a budge increase). This tells an agent when the tool is the right choice, though it doesn't explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does state that the tool 'returns a scorecard' and lists the health dimensions, implying a read-only diagnostic. However, it does not explicitly say it makes no changes, mention required permissions, or describe account-access expectations.

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

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

The description is two sentences, front-loads the core purpose, and uses a scannable list of health dimensions. It is efficient without being sparse, although the enumerated list is slightly long.

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 health check with no output schema, the description gives enough context: what the tool returns, which areas it covers, and when it is useful. It could mention permissions or explicit read-only behavior, but the core invocation context is complete.

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

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

Schema description coverage is 100%, so the schema already documents the single ad_account_id parameter, including the act_ prefix requirement. The description adds no additional parameter semantics beyond restating that it concerns a Meta ad account.

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: a comprehensive health check on a Meta ad account that returns a scorecard. It enumerates the covered areas (account status, payment health, Pixel health, etc.), which clearly differentiates it from sibling tools like get_account_summary or get_pixel_health.

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

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

The description gives clear use context by positioning the tool as a 'foundation for audits and readiness checks.' It does not explicitly list exclusions or alternatives, but the intended scenario is evident.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It frames the operation as a 'structural snapshot' and lists read-only aggregate contents, which reasonably implies no mutation, and it adds a 30-day time window. However, it does not explicitly state read-only behavior, permission requirements, or any other operational characteristics.

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

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

Two sentences with no filler: the first enumerates the summary contents in a compact list, and the second states the intended use case. It avoids repeating schema information and is front-loaded with the most useful detail.

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

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

For a single-parameter read tool with no annotations and no output schema, the description covers what the agent can expect to receive and when to use it. The exact return format is not described, but the content list and the schema's parameter documentation are sufficient for tool selection and invocation.

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

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

Schema description coverage is 100%: the only parameter, ad_account_id, is already documented with the requirement to include the 'act_' prefix. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description names the resource (Meta ad account) and specifies the exact contents of the summary: campaign counts by status/objective, ad set counts, active ad count, budget allocation, top spending campaigns, and disapproved ads. It is clear and specific, though it does not explicitly differentiate itself from sibling getters like adsap_get_account_health.

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

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

The description gives clear usage context: use this tool to get the 'big picture before detailed audit.' It implies the tool is for high-level orientation rather than deep analysis, but it does not name alternatives or state when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the ~10 second latency, the one-ad-per-call constraint, the exact rendering behavior, and the precondition that it only works for ads the search already returned. It does not explicitly say 'read-only', but the verb 'Show' and the framing as public transparency data make this clear enough.

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 slightly longer than minimal but every sentence earns its place: it front-loads the core purpose, then covers video playback, usage timing, performance, sibling distinction, and a precondition. The all-caps emphasis is stylistic noise, but the structure is logical and scannable.

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

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

Despite no output schema, the description tells the agent what the result looks like (card with creative, copy, page name; playable video), where the input id comes from, how long the call takes, the single-call constraint, and when to use an alternative. Nothing essential to correct invocation is missing.

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

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

The input schema already covers both parameters at 100% with detailed descriptions, so the baseline is 3. The description reinforces the workflow ('pass the ad's id from the search results') and mentions 'One ad per call', but these are largely redundant with the schema or are usage constraints rather than new parameter semantics.

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

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

The description states a specific action ('Show what an Ad Library ad ACTUALLY LOOKS LIKE') and names the concrete deliverables: creative, copy, page name, and a self-contained card with playable video. It also clearly distinguishes itself from siblings, notably adsap_search_ad_library (read text vs. see) and adsap_get_ad_preview (competitor vs. own ads).

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?

Explicit usage guidance is present: 'Use this after adsap_search_ad_library whenever the user wants to SEE a competitor's ad rather than read its text' and 'for those use adsap_get_ad_preview' for own ads. It also states the prerequisite (ad id from search results) and the single-ad-per-call limit, leaving no ambiguity about when to invoke it.

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

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

With no annotations provided, the description carries the full disclosure burden and delivers: it reveals the output form (interactive card with Facebook Feed + Instagram Reels tabs), the animated clip behavior for video ads, and the expected agent behavior after rendering. The schema complements this by disclosing that include_video_source costs '2 extra Meta reads'. No annotation contradiction exists since no annotations are present.

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

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

Front-loaded with the core function, then a compact sequence of behavioral rules. Every sentence earns its place given the need to encode post-call agent behavior, though it is denser than strictly necessary and slightly repetitive about the 'All placements on Meta' button.

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

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

For a tool with no output schema and no annotations, the description covers the output experience, interaction rules, parameter selection conditions, and side effects. An agent has everything needed to invoke it correctly and behave appropriately before and after rendering.

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

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

Schema description coverage is 100%, and the schema entries are unusually rich — ad_format explains which enum values the card presents and when to deviate, include_video_source discloses cost and intent, ad_account_id explains the act_xxx scoping. The main description adds only the reinforcing rule about non-default ad_format, which largely duplicates the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The opening sentence names a specific verb ('Render') and resource ('an existing Meta ad'), and characterizes the output precisely ('pixel-accurate visual preview', 'real Meta render'). It distinguishes itself from related siblings like adsap_get_preview_clip by emphasizing the real Meta render and the self-contained interactive card rather than a bare clip.

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?

Exceptionally prescriptive: it specifies the exact post-call behavior ('AFTER THE CARD RENDERS, reply with ONE short confirmation sentence and stop'), explicit prohibitions ('NEVER mention, list, or offer any other placement... never describe the card's tabs or buttons'), and a conditional rule for ad_format ('only pass a non-default ad_format when the user explicitly names one'). It also provides an alternative path — directing the user to the card's 'All placements on Meta' button — rather than enumerating placements.

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

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

With no annotations, the description carries the behavioral burden and does meaningful work: it discloses the scope (all active, optionally paused), the aggregation behavior (counts by review status), and the filtering behavior (details only for disapproved/with issues/pending). It does not cover error behavior or exact payload structure, but the core operational behavior is clear.

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

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

Three tight sentences with no filler: scope, output shape, and use case. The most important 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?

Given only two simple parameters and no output schema, the description supplies the essential context that is missing from structured fields: output style, filtering behavior, and audit use case. It leaves minor gaps such as exact count field names and pagination, but it is sufficient for a competent agent to select and invoke the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a little meaning by mapping include_paused to 'optionally paused' and ad_account_id to account scoping, but it does not materially extend the parameter documentation.

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 operation (check review and policy status), a specific resource (ads in an account), and the exact output scope (aggregate counts plus details for problematic ads only). This clearly differentiates it from siblings like adsap_get_ad_status, which presumably covers general ad status rather than review/policy status.

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

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

States a concrete use case: 'Useful in audits to surface policy violations and delivery blockers.' It does not name sibling alternatives or exclusions explicitly, but the review/policy focus and audit purpose provide clear context for when to call it.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses an important behavioral trait: 'Sheets are read-only over MCP,' preventing inappropriate write attempts. It also states what will be returned (column schema, constraints, dependencies), though it does not detail output format 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?

The description is two sentences, front-loads the core purpose, and contains no filler or redundant restatement of the tool name. Every clause adds useful information.

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

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

For a single-parameter read-only schema getter with no output schema, the description covers the main essentials: what it retrieves, when to use it, and its read-only nature. It omits how to discover sheet_id and the exact return structure, but these are minor gaps for a tool of this simplicity.

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 for the undocumented sheet_id parameter. It only refers to 'an ad sheet,' adding no guidance on the expected format of sheet_id or how to obtain it (e.g., via list_ad_sheets). The parameter name is self-explanatory to some degree, but the description does not add meaningful semantic value beyond it.

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

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

The description names a specific action and resource: 'Retrieve column schema, constraints, and dependencies for an ad sheet.' It also clarifies the purpose as reading or explaining a sheet's structure, which clearly distinguishes it from mutation-oriented siblings like update_entity or create_ad.

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

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

The description explicitly says when to use it: 'use it to read or explain a sheet's structure.' It also sets a boundary by noting that 'rows are created and edited in the ADSAP web app,' indicating this tool is not for editing. It does not name a specific sibling alternative like list_ad_sheets for finding sheet_id, 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?

With no annotations, the description carries the full burden and does well: it discloses that data is live and uncached, what categories of information are included (parent statuses, review feedback, issues, delivery summary), and that feedback is conditional on disapproval. It doesn't cover auth or error behavior, but for a read-only status check this is solid.

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

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

Three sentences, each earning its place: the first states the core purpose, the second details return content and freshness, the third gives the use case. The description is front-loaded and free of filler.

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

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

Given no output schema, the description explains the return value at a useful level: parent ad set and campaign statuses, review feedback, active issues, and a human-readable summary. It could be more precise about exact result fields or error cases, but for a simple two-parameter read tool it is largely complete.

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

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

Schema coverage is only 50%: ad_account_id is documented but ad_id is not. The description doesn't explain how to obtain or format ad_id, nor does it add meaning beyond the parameter name. The phrase 'single Meta ad' names the resource but provides no additional parameter guidance.

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 ('Check'), resource ('a single Meta ad'), and the exact dimensions of status covered (delivery, review, effective). It clearly separates this from sibling tools like get_ad_review_status by emphasizing the broader status scope plus parent statuses and issues.

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

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

Explicitly states when to use the tool: 'monitor ads after creation or diagnose delivery problems.' It does not name alternatives or exclusions, but the use context is clear enough for an agent to select it over most siblings.

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

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

With no annotations, the description bears the transparency burden. It discloses the operation as a live read-only listing ('List all... live from Meta') and scopes what is included with concrete source categories. It could add a explicit note about pagination or response shape, but for a simple read endpoint the disclosure is adequate.

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

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

Three short sentences, all informative: primary purpose with examples, UI mapping, and use case. There is no repetition of the title or schema and 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?

The description is strong for a tool with no output schema and no annotations: it tells the agent what is returned conceptually and why to call it, while the schema fully covers required parameters and pagination. It doesn't describe exact result fields, but that is a minor gap for a simple list tool.

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

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

Schema coverage is 100%, so every parameter already has a description and the tool description adds no parameter-level detail. Baseline 3 applies because the description doesn't need to compensate for schema gaps.

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

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

The description uses a specific verb ('List') and a specific resource ('data sources connected to a Meta product catalog'), then enumerates the source types (product feeds, Batch API, Shopify/WooCommerce, smart pixel, website crawling). This makes it clearly distinct from sibling catalog tools like get_catalog_details or get_catalog_diagnostics without needing to inspect their schemas.

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

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

'Use to see how a catalog's products get ingested' and the Commerce Manager Data Sources tab reference give clear context for when to call it. It doesn't explicitly state when not to use it or name alternative tools, 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?

With no annotations provided, the description carries the full burden. It discloses that the data is fetched 'live from Meta' and enumerates the metadata fields, which is useful. However, it does not mention any side effects (though it is clearly read-only), authentication requirements beyond the ad account ID, potential error conditions, or rate limits. For a read operation this is adequate but not richly 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?

The description is exactly two sentences with zero wasted words. The core purpose and output fields are front-loaded in the first sentence, and the usage context follows in the second. It is concise and immediately actionable.

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

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

For a simple metadata-fetch tool with only two required parameters and full schema coverage, the description covers the essential context: what it returns, that it's live, and when to use it. It doesn't describe the exact return structure, but since no output schema exists and the tool is straightforward, this is a minor gap. Overall, it is complete enough for an agent to call it correctly.

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

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

Schema description coverage is 100%, and the schema already provides strong semantics: catalog_id specifies it's numeric and sourced from adsap_list_catalogs, and ad_account_id explains it's required, scopes the request, and anchors the budget check. The description adds no additional parameter detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get') and a clear resource ('Meta product catalog's metadata') with explicit fields ('name, vertical, total product count, and owning business'). It also differentiates from siblings by positioning itself as a first-step overview before drilling into products, diagnostics, or data sources, which is distinct from tools like adsap_get_catalog_data_sources or adsap_get_catalog_diagnostics.

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

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

The description explicitly says 'Use as a first step before drilling into a catalog's products, diagnostics, or data sources,' giving clear guidance on when to invoke it. It doesn't mention explicit exclusions or alternatives by name, but the context makes the intended usage unambiguous. A minor gap is not stating when NOT to use it, but the guidance is sufficient.

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

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

No annotations are provided, so the description carries the burden. It adds useful behavioral details: data is fetched 'live from Meta' and an empty list means no issues detected. However, it does not discuss auth requirements, rate limits, or explicitly confirm read-only behavior (though implied by 'get'). This is adequate but not comprehensive.

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

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

Three sentences, each earning its place: purpose with examples, empty-list semantics, and usage guidance. It is front-loaded with the core action and contains no filler.

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

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

For a read-only diagnostics tool, the description covers the essential context: what it does, when to use it, and how to interpret an empty result. It lacks output structure details, but the schema handles parameter limits and the tool is low-risk. With no annotations, it could be more thorough, but it is sufficient for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all parameters (limit default/max, catalog_id source from adsap_list_catalogs, ad_account_id scoping). The description adds no parameter-specific meaning, so the baseline 3 applies.

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

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

The description states a specific verb+resource combination: 'Get data-quality diagnostics for a Meta product catalog' with concrete examples (broken images, missing fields, policy violations). It is clearly distinct from sibling tools like get_catalog_details or get_product_details, which focus on data rather than diagnostics.

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

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

The description gives explicit when-to-use guidance: 'Use when products aren't showing in ads or the user asks about catalog health.' This is clear context, but it does not mention alternatives or specify when not to use the tool, so it falls 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?

With no annotations provided, the description carries the full disclosure burden, and it delivers real value: exact metric definitions and the fatigue algorithm basis (frequency, CPA decay, Hook Rate decline). It omits explicit read-only status, pagination, and failure behavior, but for a 'get_' tool with this much output detail, the transparency is strong.

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

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

Three dense sentences with zero filler: core purpose is front-loaded, the second sentence enumerates return metrics with formulas, and the third explains fatigue logic. Every sentence earns its place and the structure is easy to scan.

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

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

With no output schema and no annotations, the description correctly shoulders the burden of defining return semantics — metric formulas, classification values, and the fatigue basis are all present. It lacks response shape and ranking-order details, but for a read-only analysis tool the coverage is solid.

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

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

Schema description coverage is 100%, so all six parameters (ad_account_id, limit, sort_by, date_range_days, include_paused, include_asset_breakdown) are already documented by the schema. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description names a specific resource ('creative performance analysis') and a concrete verb ('Returns'), then defines a distinctive metric set with formulas (Hook Rate = 3s plays/impressions, Hold Rate = 15s/3s) and fatigue classification values. The unique output vocabulary (healthy/watch/fatigued, ad relevance diagnostics) differentiates this from any sibling without opening another 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 use case is implied by the unique metric names — an agent can infer this tool covers creative-level fatigue analysis. However, it never explicitly states when to use it over siblings like adsap_get_insights, adsap_get_insights_breakdown, or adsap_get_account_health, and no alternative or exclusion conditions 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?

With no annotations, the description carries the behavioral burden. It discloses that the data is live from Meta, that the result is only safe if empty before deletion, and notes that deleting an audience auto-pauses dependent ad sets. It could go further on rate limits or explicit non-mutation guarantees, but the 'List' verb and deletion context make the read-only nature clear.

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 carry purpose, output shape, use cases, a safety implication, and a grouping tip. There is no filler, and the primary purpose is front-loaded before the usage guidance.

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

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

For a tool with no output schema and no annotations, the description explains the return fields, the safety condition, and where to get the required ID. Pagination behavior is left to the schema, which documents it well. A brief note on the overall response format would push this to a 5.

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

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

Schema description coverage is 100%, so the baseline is 3. The description points to adsap_list_custom_audiences as the source for custom_audience_id, but the schema already says this. It adds no substantial parameter-level meaning beyond what the schema provides.

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

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

The description opens with a specific verb and resource: 'List the ads that use/target a given custom audience' and specifies the key output fields (ad set and campaign id). It clearly distinguishes this from the many sibling list/get tools by tying the result to a custom audience and adding 'live from Meta.'

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

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

The description gives explicit use cases: use before deleting an audience, and to answer 'where is this audience used?'. It even clarifies that an empty list means deletion is safe. It does not explicitly name alternative tools to avoid, so it falls just 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?

With no annotations, the description carries the behavioral disclosure burden. It transparently describes the return values (estimated daily reach, outcome ranges, audience size assessment) and implies a non-mutating read operation through 'Get' and 'Returns.' It does not discuss auth or rate limits, but for an estimation tool these are less critical.

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

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

Three sentences, each earning its place: purpose, return values, use contexts. No fluff, no repetition, and the core purpose is front-loaded.

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

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

Given the absence of an output schema, the description adequately covers what the caller gets back. Combined with a fully documented input schema, the agent has enough to invoke the tool correctly without opening schemas further.

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

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

Input schema coverage is 100%, so the schema already documents all parameters. The description adds only a high-level summary ('proposed audience and optimization configuration') and does not clarify parameter nuances beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Get Meta's delivery estimate') and clearly differentiates it from sibling tools like adsap_get_insights or adsap_get_pixel_stats by stating it returns delivery estimates and audience size assessment. This makes the tool's purpose unmistakable.

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

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

It explicitly states when to use it: 'during onboarding to validate strategies or in audits to check targeting breadth.' It does not name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description must carry behavioral disclosure. It does more than restate the title: it reveals that the import has a phase ordering ('images then videos') and that counts are reported as imported/skipped/failed. This gives useful behavioral detail beyond the bare tool name.

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

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

A single, front-loaded sentence states the action, the originating async operation, and the returned status components. Every phrase contributes information, with no filler or repetition of the title.

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

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

For a one-parameter status tool with no output schema, the description is complete: it names the required input provenance, the operation being monitored, and what the result contains. The agent has enough information to call it correctly immediately after an import is started.

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

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

The schema already fully documents `job_id` as an import job id returned by `adsap_import_account_creatives` (100% coverage), so the description does not need to add much. It reinforces the connection to the import tool, but provides no new parameter-level semantics beyond the schema, meeting the baseline.

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

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

The description uses a specific verb ('Check progress of a Meta historical-asset import') and names the exact resource and producing tool (`adsap_import_account_creatives`). It also itemizes what the status includes, which clearly distinguishes it from generic status/upload tools like `adsap_get_upload_status`.

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

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

The description clearly indicates this tool is for checking progress of imports started with `adsap_import_account_creatives`, giving the agent the relevant context. It does not mention explicit exclusions or alternative status tools, but for a single-purpose status check the usage context is clear enough.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses that data is served from a cache, automatically refreshed from Meta when stale (>6h), that no dashboard visit is required, that results and cost_per_result are objective-aware, that reach and ad recall are fetched live, and that parent filters narrow the set server-side before sort/limit/summary. These are meaningful behavioral traits beyond the schema.

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

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

The description is dense but well-structured: main purpose, caching/refresh behavior, metric semantics, then filter/ordering behavior. Each sentence earns its place and is front-loaded with the core action. For a tool with 16 parameters, this length is justified and information-dense without redundancy.

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

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

The description is thorough for a complex tool with no annotations and no output schema. It covers caching, live refresh, objective-aware results, result_type behavior, and filter composition. Gaps remain: output structure, pagination via cursor, and the per-day vs per-entity row behavior for account-level queries are not described, though some are in the schema. Overall, it is near-complete but not exhaustive.

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 63%, so the baseline is around 3, but the description adds valuable parameter semantics: it explains how campaign_ids and adset_ids act as parent filters, that rows expose adset_id/campaign_id, and that sort/limit/summary describe the filtered set. It also clarifies result_type semantics for rows. However, it does not compensate for undocumented parameters like cursor, sort_by, or date_to formatting.

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

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

The description clearly states a specific verb and resource: 'Retrieve aggregated spend and performance metrics for accounts, campaigns, ad sets, or ads over a date range.' This is unambiguous about what the tool does. However, it does not explicitly differentiate from the closely named sibling adsap_get_insights_breakdown, so the distinction is implied rather than stated.

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

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

The first sentence provides clear context for when to use the tool: when aggregated metrics are needed for any of four entity types over a date range. It also explains behavior like caching and live refresh, but it does not explicitly mention alternatives such as adsap_get_insights_breakdown or state when not to use this tool. Clear context with no exclusions, but no explicit 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?

No annotations are present, so the description carries the full burden. It provides useful behavioral context by stating 'Live Meta API call' and 'Not cached', which informs the agent that results are fresh but may be slow or subject to API failures. However, it does not disclose other significant behaviors like rate limits, pagination, or potential large result sizes.

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

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

A single, well-structured sentence that front-loads the purpose and scope. Every word earns its place without repetition or fluff. The 'Not cached' warning is a useful, distinct addition.

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 gives enough to understand the core function, but with 12 parameters and no output schema, more guidance would help—such as what the response looks like, pagination expectations, or a note about common breakdown combinations (e.g., max 2 dimensions). The schema covers parameter definitions but not the overall call context.

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

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

Schema coverage is 75%, so the schema already documents most parameters in detail. The description adds no extra meaning beyond the schema; it just mentions 'spend and performance metrics' and example dimension values, which are already listed in the parameter descriptions. It does not compensate for the remaining undocumented parameters.

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

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

The description clearly states a specific action ('get spend and performance metrics'), a resource ('Meta API call'), and the key distinguishing feature ('sliced by demographic or placement dimensions'). It immediately differentiates this tool from the sibling adsap_get_insights without requiring schema inspection.

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 'sliced by demographic or placement dimensions' implies when to use this tool (when breakdowns are needed), but it never explicitly names the alternative or states any exclusion condition. The agent must infer the choice based on the name and sibling list rather than being explicitly guided.

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?

No annotations are provided, so the description carries the burden. It clearly states it is a read operation ('Read ONE Meta Instant Form') and adds a valuable behavioral detail: 'warnings name anything the form uses that Adsap cannot recreate (e.g. conditional logic)'. It also mentions the return shape matches another tool, giving the agent a sense of the response structure. It doesn't cover error conditions or auth, but for a simple read that's acceptable.

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

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

The description is three sentences, front-loaded with what the tool reads and then immediately routing to the listing sibling. Every sentence earns its place: content scope, use cases, and an explicit alternative. No fluff or repetition.

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

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

For a read-only tool with no output schema, the description is complete: it states what is returned, how to obtain the form_id, and how to differentiate from listing. The mention of warnings and the shape reference to adsap_manage_instant_form provide sufficient context for correct invocation. Nothing critical is missing.

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

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

Schema coverage is 100% and all three parameters are clearly described in the schema. The description adds no extra parameter details beyond what the schema provides, but it does reinforce the source of form_id ('from adsap_list_meta_assets'). This meets the baseline for complete schema coverage without adding redundancy.

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 ('Read'), a specific resource ('ONE Meta Instant Form'), and enumerates the content returned (questions, intro, privacy policy, etc.). It explicitly differentiates from listing via adsap_list_meta_assets and references the shape of adsap_manage_instant_form, so an agent can distinguish it without inspecting 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 explicit use cases: 'explain a form to the user or to prepare a duplicate' and explicitly directs listing to 'adsap_list_meta_assets (asset_type instant_forms)'. This provides clear when-to-use and when-not-to-use guidance with the alternative named.

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?

No annotations are provided, so the description carries the full behavioral burden — and it handles this well. It discloses that data is fetched 'live from Meta' (not cached), explains the match_rate_approx sentinel value (-1 = not enough data yet), and enumerates returned fields. For a read-only audit tool, the disclosed behaviors are sufficient, though it doesn't cover error conditions or pagination.

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

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

The description is information-dense with no filler; it front-loads the core purpose and field list before moving to usage and sibling differentiation. It is longer than average but every clause earns its place given the absence of an output schema that would otherwise document return fields.

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

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

For a tool with no output schema, the description compensates by enumerating the returned configuration fields and their semantics inline. It covers the primary use cases, sourcing of required inputs, and sibling relationships. Minor gaps (e.g., what 'data-use setting' values look like, error behavior) are acceptable for this read-audit tool.

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

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

Schema description coverage is 100%, so both parameters (pixel_id and ad_account_id) are already well-documented in the schema. The description references getting pixel_id from a sibling tool but adds no parameter-specific meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description opens with a specific verb+resource ('Get a Meta pixel's configuration details') and enumerates the exact fields returned (automatic advanced matching, matched customer-info fields, match_rate_approx, first-party cookie status, data-use setting, last fired time, owning business). It also explicitly distinguishes itself from sibling tools by naming adsap_get_pixel_stats and adsap_get_pixel_health as complements, so an agent can clearly tell it apart.

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

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

States explicit when-to-use scenarios: 'Use to audit pixel setup / event match quality before optimizing campaigns, or to check a pixel is alive (last_fired_time).' It also instructs where to source the pixel_id (from adsap_list_meta_assets) and names complementary siblings. It lacks explicit when-not-to-use exclusions, but the guidance is clear and actionable.

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

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

Annotations are absent, so the description carries the full burden. It discloses that the check is 'live from Meta' (real-time) and that each check returns pass/fail, which sets expectations for output. It also implies a read-only diagnostic operation by describing 'health checks' and 'diagnose'—no mutation is suggested. However, it does not explicitly state that no data is modified, and it doesn't mention potential failure modes or rate limits. Given the absence of annotations, this is a strong but not perfect disclosure.

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 slightly long but every sentence earns its place: it states the purpose, lists specific checks, provides usage context, names a complementary tool, and gives parameter sourcing guidance. The most critical information (what it does and when to use) is front-loaded. It avoids fluff and is well-organized, though it could be tightened by removing the trailing 'and more' clause.

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

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

Given there is no output schema, the description explains that each check returns pass/fail, which is sufficient for an agent to understand the result shape. It covers the source of the pixel_id, the diagnostic purpose, and the complementary sibling. It does not mention error cases or permissions, but these are likely handled generically across tools. The description is complete enough for an agent to select and invoke this tool correctly in most scenarios.

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

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

Schema coverage is 100% with clear descriptions for both parameters (pixel_id and ad_account_id). The description adds extra value beyond the schema by telling the agent where to source the pixel_id ('Get it from adsap_list_meta_assets') and explaining that ad_account_id 'scopes the request and anchors the Meta budget check.' This enhances the agent's understanding without redundancy.

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

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

Description uses a specific verb ('Get'), names the exact resource (Dynamic/Advantage+ catalog-ads readiness health checks for a Meta pixel), and enumerates concrete checks (event-source match rate, missing DPA parameters, iOS 14.5+ AEM setup). It clearly distinguishes itself from siblings by naming its complementary tool (adsap_get_pixel_stats) and explicitly stating it's a diagnostic for catalog/Advantage+ ads, unlike adsap_get_pixel_details or adsap_get_pixel_stats.

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

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

Provides explicit when-to-use guidance: 'Use to diagnose why catalog/Advantage+ ads under-deliver or why events aren't matching products, before launching.' It also names the sibling that complements it (adsap_get_pixel_stats for event volume), and instructs how to obtain the pixel_id (from adsap_list_meta_assets with asset_type:"pixels"). This leaves no ambiguity about when and how to invoke it.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the data is 'live from Meta' (fresh, not cached) and implies a read-only operation via 'Get event volume.' It does not mention latency, auth requirements, or error conditions, but for a low-risk read tool this is acceptable.

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

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

The description is two sentences: the first states what the tool returns, the second states the use case and how to get pixel_id. It is front-loaded with purpose, contains no filler, and every sentence contributes distinct information.

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

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

The description explains what the tool computes (event volume by type), when to use it (pixel firing / conversion signal check), and how to obtain the key input (pixel_id from adsap_list_meta_assets). The input schema fully documents parameters, so the missing exact output structure and error behavior are minor for this read-only analytics tool.

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

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

Schema coverage is 100% for all four parameters, so the baseline is 3. The description reinforces that pixel_id comes from adsap_list_meta_assets, but that duplicates the schema text and adds no new meaning for end_time, start_time, or ad_account_id. Thus it meets but does not exceed the schema-driven baseline.

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

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

The description clearly states the specific verb and resource: 'Get event volume for a Meta pixel / dataset' and enumerates event types like PageView, Purchase, Lead. It distinguishes itself from sibling tools such as adsap_get_pixel_details and adsap_get_pixel_health by focusing on event counts, so an agent can identify the right tool 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?

The description gives an explicit when-to-use: 'Use to confirm a pixel is firing and see which conversion signals it's receiving before building a conversion-optimized ad set.' It also points to adsap_list_meta_assets as the source for pixel_id. However, it does not state when not to use this tool or mention alternative analytics tools, stopping short of full when/when-not 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?

With no annotations, the description correctly carries the burden. It discloses the asynchronous behavior ('pending' while background recording is in progress), the eventual output (signed URL), and the cost profile ('Storage-only — costs no Meta API budget'). It does not cover error cases(such as TTL expiration or failure states), but the key behavioral traits are surfaced.

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

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

Three short sentences, each adding distinct value: purpose (fetch clip after rendering), return states (signed URL vs pending), and cost/storage semantics. The key constraint is front-loaded; no filler 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?

The description is complete for a simple three-parameter polling tool: it states prerequisite, expected return states, and cost characteristics. The absence of an output schema means some return-format detail would help, but the description already covers the essential 'pending vs ready' contract, so no critical guidance is missing.

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

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

Schema coverage is 100%, so the input schema fully documents all three parameters. The description adds no detail beyond the schema (e.g., it doesn clarify format of ad_account_id or how ad_format maps to placements). Baseline 3 is appropriate because the schema already does the heavy lifting.

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

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

The description clearly states a specific verb ('Fetch') and resource ('animated placement-preview clip') and ties it to its render sibling ('previously rendered with adsap_get_ad_preview'). This makes its purpose unambiguous and distinguishes it from the many get/list siblings within the toolset.

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 prerequisite is explicit: the clip must have been previously rendered with adsap_get_ad_preview. The 'pending' status also implies it is used as a poll for an async background recording. It could have gone further and explicitly said 'use adsap_get_ad_preview when you want a static preview,' but the naming and prerequisite make the usage context 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?

No annotations are provided, so the description carries the full burden. It adds useful behavioral context ('live from Meta') and lists the returned fields, but it does not disclose error behavior, permission/access requirements, or explicitly confirm read-only behavior beyond the word 'fetch.'

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

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

Three sentences with the core purpose front-loaded, followed by a compact list of returned fields and a routing pointer. No filler, no redundant restatement of schema details.

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

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

For a simple two-parameter read tool with no output schema, it names the data source, the selector, the returned fields, and the alternative for SKUs. It only omits minor edge-case details such as not-found/error behavior, which are not essential for selecting and invoking the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the FBID-vs-retailer_id distinction and the 'live from Meta' idea, but the input schema already documents numeric FBID, the non-SKU constraint, and ad_account_id's scoping/budget-check role.

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 ('Fetch'), resource ('full details of one catalog product'), and the exact lookup key (numeric Meta product ID / FBID). It also disambiguates this tool from the sibling search tool by explicitly contrasting FBID vs retailer_id/SKU.

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 tells the agent when not to use this tool: for a merchant SKU (retailer_id), use adsap_search_catalog_products with retailer_id instead. This gives a clear routing rule between two otherwise similar catalog 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?

No annotations exist, so the description carries the full burden. It discloses that the call is live ('live from Meta'), lists the returned fields, and mentions the pagination cursor. This gives the agent a solid behavioral picture, though error handling and rate-limit implications are not covered.

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

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

Three sentences, each earning its place: the core behavior, the recommended usage, and the return fields. The most important information is front-loaded and there is no filler.

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

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

For a list-style tool with no output schema, the description covers the key return fields and pagination, and provides the proper calling context. It does not describe the exact response envelope or edge cases like empty product sets, but the schema plus description are sufficient 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 100%, so the schema already documents all four parameters in detail, including how to obtain product_set_id. The description does not repeat parameter semantics, which is appropriate; it only adds context that the response contains a pagination cursor tied to the 'after' parameter.

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

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

Description states a specific verb ('List') and resource ('products inside a Meta catalog product set'), with the added 'live from Meta' qualifier. It clearly separates this tool from siblings like adsap_search_catalog_products or adsap_get_product_details by focusing on product set membership enumeration.

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 tells the agent to use it after adsap_list_catalogs and before building a catalog, DPA, or collection ad. This is clear workflow guidance, though it does not mention alternative tools for cases like searching products by query.

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

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

With no annotations provided, the description carries the full burden and exceeds it: it discloses the two-array structure that must never be merged, enumerates all alert/finding types, specifies ordering priority, describes returned contents (evidence numbers, money at risk, weekly summary), and gives presentation rules ('suggest the action, never promise results', label AI summaries). This is rich, actionable behavioral disclosure.

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

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

The description is long but every sentence earns its place: the critical two-array constraint is front-loaded, followed by item taxonomies, ordering rule, contents, account_id behavior, and response language guidance. Density is justified by the complexity of the output contract.

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 no output schema and 5 parameters, the description fully covers output shape, item semantics, ordering, included fields, and how to phrase the response. The un-documented parameters are simple enums/defaults, so nothing an agent needs to invoke the tool correctly is materially 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 low (20%, only account_id documented), and the description adds no new parameter meaning beyond repeating the account_id omission guidance already in the schema. However, the remaining parameters (limit, status, platform, include_dismissed) are largely self-explanatory through their types, enums, and defaults, so the gap is a clear but not severe shortfall.

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

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

The description states a specific verb+resource ('Verified recommendations AND alerts computed by ADSAP's daily/weekly checks') and immediately distinguishes the two output arrays (alerts vs findings) with concrete item types. This clearly separates it from the many sibling get_* tools, which focus on raw metrics, health, or assets.

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

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

The description gives clear context on when the data is relevant (daily/weekly checks from the client's own data) and explicit handling guidance ('When both are present lead with the alerts', 'Omit account_id for a whole-workspace view'). It does not explicitly name alternatives or state when-not-to-use, but the unique recommendations/alerts scope makes the intended use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it returns processing state and creative_asset_id, but it does not clarify whether this is a read-only poll, how long uploads may remain in processing, what error conditions might occur, or whether the returned creative_asset_id is always present only after processing completes. This is a meaningful gap for an async status tool.

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

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

Two sentences with no filler. The first sentence states the action and resource, and the second sentence states the return value. This is appropriately sized and front-loaded.

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

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

This is a simple one-parameter polling tool, but with no output schema and no annotations, the description is thin. It lacks guidance on when the status is 'complete', how to interpret states, how to obtain job_id, and whether the creative_asset_id is production-ready. A minimal viable description for an async poller should include at least the status values or a pointer to the upload tool.

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

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

Schema description coverage is 0%, so the description must compensate. It names no parameter details beyond the schema's job_id definition. Since there is only one parameter, a UUID, the schema already conveys the basic meaning. The description adds the context that job_id refers to an async upload job, but it does not explain how to obtain the job_id or how it relates to sibling upload tools.

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

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

The description uses a specific verb ('Check') with a clear resource ('status of an async video upload') and distinguishes this status-check operation from other status tools by naming the async video upload context and the returned 'creative_asset_id'. It clearly tells an agent what this tool does.

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

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

The description implies the tool should be used after initiating an async video upload, by mentioning 'async video upload' and 'Returns processing state'. However, it does not provide explicit when-to-use guidance or name alternatives like adsap_get_import_status or adsap_get_ad_review_status, so the agent must infer the exact workflow context.

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

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

With no annotations provided, the description carries the full behavioral burden and delivers extensively: atomicity, safe PAUSED defaults, ENABLED override behavior based on campaign status, the fact that a group without an ad will not serve, dry_run validation semantics, and verification that the campaign/ad group exists. This is exemplary transparency for a mutating tool.

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

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

The description is long, but the length is justified by three channel variants and two operation modes. The core purpose is front-loaded in the first sentence, and the content is organized into clear labeled clusters: channel rules, SAFETY defaults, per-channel requirements, EXISTING-GROUP MODE, and dry_run. Slightly dense, but every portion earns its place.

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

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

For a highly complex tool with no output schema and no annotations, the description is remarkably complete: it covers required inputs, defaults, valid modes, unsupported campaign types, cross-parameter constraints, and safe invocation via dry_run. An agent has enough context to call the tool correctly across all supported channels.

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?

Even though schema coverage is high at 86%, the description adds substantial meaning: mutual exclusivity of ad_group vs ad_group_id, channel-specific field requirements, geo being required at ad group level for Demand Gen, keyword optionality with the warning that Search gets no traffic without them, and ad shape variants per channel. It goes well 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 opens with a specific verb and resource: add an ad group to an EXISTING Google Ads campaign, and clarifies it covers Search, Display, or Demand Gen. It explicitly distinguishes itself from create-campaign tools, so an agent can immediately tell it apart from adsap_google_create_search_campaign and similar siblings.

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

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

The description states exactly when to use this tool: to add structure to an already-created campaign, and when not to: PMax, App, and Shopping are unsupported. It also names the alternative context via EXISTING-GROUP MODE and points to adsap_google_list_campaigns for IDs, leaving no ambiguity about selection.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden and does so thoroughly. It discloses that campaigns are 'ALWAYS created PAUSED', that the ad links to the store listing automatically with no URL input, that no app ownership is required, that v1 only optimizes for INSTALLS, and that missing conversion tracking returns a warning. It also calls out the 50x target_cpi budget recommendation and the dry_run validation behavior.

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

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

The description is dense but every sentence earns its place: core behavior, targeting, budget semantics, text constraints, media options, unsupported goals, warnings, dry-run workflow, and sibling routing. The most decision-critical facts are front-loaded ('ONE atomic request', 'ALWAYS created PAUSED', 'no URL input, ever').

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 complexity of this tool and the absence of annotations and output schema, the description is remarkably complete. It covers prerequisites, required and optional inputs, validation behavior, unsupported features, warnings to relay, and exact alternatives. An agent has all context needed to select, invoke, and sequence this 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 only 29%, so the description must compensate — and it does. It explains app_id formats for Android and iOS, clarifies target_cpi and daily_budget are plain numbers in account currency rather than micros, points media asset IDs to adsap_google_upload_asset, references adsap_google_search_geo_targets for location IDs, and specifies that ad_account_id is a bare 10-digit customer ID. This adds substantial meaning beyond the raw schema.

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

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

The description states a specific verb and resource: 'Create a complete Google App campaign in ONE atomic request' and enumerates exactly what is included (budget, campaign, targeting, ad group, ad). It also differentiates from sibling tools by clarifying that this is for Google App campaigns with app_link auto-generated, and explicitly names alternatives for website and Meta campaigns.

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

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

The description gives explicit when-to-use guidance: 'App campaigns promote a mobile app across Google Search, Google Play, YouTube, Discover and the Display Network.' It also provides clear exclusions and alternatives: 'For website campaigns use adsap_google_create_search_campaign / adsap_google_create_pmax_campaign; for Meta app ads use adsap_create_campaign with an app objective.' The recommended dry_run-first workflow is also actionable 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?

With no annotations provided, the description carries the full behavioral burden, and it delivers: ALWAYS created PAUSED, dry_run validates the whole chain without creating anything, atomic request semantics, bidding_strategy 'auto' resolves based on conversion tracking, target_roas requires conversion history, and budget has a hard floor. This goes well beyond what the name or schema 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 long but every clause carries essential operational information. It is front-loaded with the atomic create and PAUSED behavior, then proceeds logically through dry_run, ad types, budget, channels, bidding, account ID, and alternatives. No filler or repetition.

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

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

Given the tool's high complexity, nested objects, seven parameters, and no output schema, the description covers all important invocation decisions: what the tool creates, how to validate safely, per-type ad requirements, channel selection semantics, bidding behavior, budget floor, and sibling routing. An agent can correctly select and call this tool with very little left to guess.

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

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

Schema description coverage is only 29%, so the description must compensate, and it does extensively: ad types with exact asset counts and dimensions, required long headlines for video_responsive, budget not in micros, channel booleans, bare 10-digit ad_account_id, dry_run meaning, and geo targeting at ad-group level. The prose explains constraints and relationships the schema only hints at.

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 very specific verb and resource: create a complete Google Ads Demand Gen campaign in one atomic request, enumerating exact surfaces (YouTube, Discover, Gmail, Maps, Display). It also distinguishes itself from siblings at the end ('For Search use adsap_google_create_search_campaign, for Performance Max use adsap_google_create_pmax_campaign; for Meta use adsap_create_campaign'), so the agent can tell it apart from nearby campaign-creation 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 tells the agent when to use this tool vs alternatives (Search, PMax, Meta), and gives a mandatory invocation workflow: run dry_run: true first, show the plan, get confirmation, then execute. It also warns that campaigns are ALWAYS created PAUSED and should be activated later with a named sibling tool, which is concrete, actionable 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: campaign is ALWAYS created paused, the request is atomic, dry_run validates without creating, Display is being migrated into Demand Gen, and every response carries a heads-up. Bidding constraints and eligibility gates are explicitly 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?

The description is front-loaded and organized into scope, context, ad requirements, bidding, and workflow. It is dense and necessary for the tool's complexity, though it partially repeats constraints already present in the schema and uses emphatic formatting that adds length without much semantic value.

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

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

For a highly nested campaign-creation tool with no output schema, this covers all critical preconditions: asset provenance, mandatory image classes, bidding eligibility, dry-run validation, and relationship to sibling tools. An agent has enough to retrieve the right inputs and invoke the tool correctly.

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

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

Schema coverage is only 29%, and the description compensates by clarifying budget units (plain number, not micros/cents), that image/video fields are asset IDs from adsap_google_upload_asset, image size/aspect requirements, exact long_headline count, bid-strategy pairings, and the bare 10-digit ad_account_id format.

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

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

States a specific action and resource: creates a classic standalone Google Display campaign as one atomic request encompassing budget, campaign, targeting, ad group, and ad. It explicitly differentiates this from Demand Gen by naming the sibling and the account-parity rationale.

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?

Tells the agent that for new builds it should consider adsap_google_create_demand_gen_campaign instead, and that this tool is for classic account-structure parity and full Display bid control. It also prescribes the workflow of dry_run first, then execution, and directs activation to adsap_google_set_entity_status.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: atomic creation, ALWAYS paused, dry-run semantics, enforced asset minimums, optional video auto-generation, auto bidding resolution with a preflight warning, retail Merchant Center behavior, and ad_account_id format. It discloses far more than a generic create statement.

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 dense but every clause earns its place: core behavior and safety workflow first, then enforced constraints, then sibling disambiguation. It is front-loaded and avoids 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 complex nested tool with no annotations and no output schema, this is exceptionally complete: it covers prerequisites, validation flow, creation-time behavior, constraints, failure modes, and alternatives. An agent has what it needs to call the tool correctly and safely.

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

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

Schema description coverage is only 38%, but the description compensates for the most decision-critical parameters: dry_run, bidding_strategy auto resolution, retail merchant link attachment, ad_account_id format, and image dimension eligibility. It does not narrate every nested field, but the schema itself documents those with detailed descriptions, so the combination is strong.

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

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

The description states a specific action ('Create a complete Google Ads Performance Max campaign in ONE atomic request') and enumerates the bundled components: budget, campaign, targeting, and one asset group. It also routes away from siblings by explicitly naming adsap_google_create_search_campaign for Search and adsap_create_campaign for Meta.

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 a concrete workflow: run with dry_run: true first, show the validation plan, get confirmation, then execute. It also names prerequisites (images via adsap_google_upload_asset), the post-create activation step via adsap_google_set_entity_status, and the correct sibling tools for Search and Meta campaigns.

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?

No annotations are provided, so the description carries the full disclosure burden. It reveals critical behavioral facts beyond the name and schema: atomicity, ALWAYS created PAUSED, dry_run validates without creating, bidding_strategy 'auto' resolves via conversion-tracking preflight, and language targeting may be dropped by Google with a server retry and warning. This is far more transparent than typical tool definitions.

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 dense but every sentence earns its place: purpose, atomicity, dry-run workflow, paused-by-default, bidding behavior, location source, ID format, and sibling routing. It is appropriately front-loaded with the core action and critical caveats before operational details.

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

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

For a complex nested-object create tool with no output schema and no annotations, the description covers workflow, dry-run, activation, data source, bidding override, asset automation constraints, and language-targeting caveat. It could briefly state what the successful response contains in non-dry-run mode, but the available context is otherwise unusually complete.

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

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

Schema description coverage is low at 29%, but the description compensates well for key parameters: ad_account_id is a bare 10-digit customer ID, bidding_strategy includes default resolution logic, dry_run semantics are explained, and location IDs are sourced from a specific sibling tool. Some nested parameters like ad_group, rsa, and geo are left mostly to the schema, which prevents a 5, but the most consequential parameters get meaningfully enriched.

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 complete Google Ads Search campaign in ONE atomic request'. The scope is precisely defined and the description distinguishes it from the Meta path by saying 'For Meta campaigns use adsap_create_campaign instead', and the word 'Search' differentiates it from sibling Google campaign creators like display, PMax, or Shopping.

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

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

Provides explicit when-to-use and how-to-use guidance: dry_run: true first, then confirm and execute; campaigns are always paused and activated later with adsap_google_set_entity_status; location IDs come from adsap_google_search_geo_targets; and the Meta alternative is named. This gives the agent a complete decision and invocation sequence.

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 zero annotations, the description carries full responsibility for behavioral disclosure. It reveals the campaign is always created PAUSED, that a Merchant Center link is required (with a clean error if absent), that merchant_id auto-resolves when exactly one link exists, that dry_run validates without creating, and that campaign_priority only arbitrates within the account's own standard Shopping campaigns. It even notes that language targeting does not exist for Shopping. This is comprehensive behavioral transparency.

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

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

The description is long but every sentence earns its place. It front-loads the core creation scope, then flows naturally into prerequisites, dry_run workflow, bidding nuances, and sibling alternatives. The information is dense but structured logically, making it easy for an agent to parse and act on.

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

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

For a complex tool with five parameters, nested objects, no output schema, and no annotations, this description covers essential context: the atomic one-shot nature, the always-paused behavior, the Merchant Center prerequisite, the dry_run flow, bidding strategy constraints, feed label handling, and explicit sibling comparisons. Nothing an agent needs to call it correctly is missing.

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

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

The description adds crucial meaning beyond the schema: ad_account_id must be a bare 10-digit ID, daily_budget is in plain currency not micros, bidding_strategy 'auto' means Maximize Clicks while 'manual_cpc' requires cpc_bidcher, feed_label must match exactly and is case-sensitive, and campaign_priority's interactions with PMax are explained. With schema coverage at only 20%, this compensating detail is vital for correct invocation.

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: 'Create a complete standard Google Shopping campaign in ONE atomic request.' It then enumerates the exact components (budget, campaign, ad group, product ad, listing group), and distinguishes itself from PMax and Meta catalog siblings by naming them explicitly. This is a model of purpose clarity.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: it instructs to dry_run first DB, says to use adsap_google_create_pmax_campaign for PMax and adsap_create_campaign for Meta catalog ads, and explains the trade-offs between bidding strategies (manual_cpc as the reason to prefer Shopping over PMax). This is far beyond minimum viability.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses the returned data shape, the 30-day retention limit, propagation lag, and ID format. It does not explicitly state read-only behavior or auth requirements, but the read-only nature is strongly implied by 'change history' and 'Returns'.

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

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

The description is compact and front-loaded, opening with the core purpose before adding qualification details. Each sentence contributes a distinct fact: return fields, retention window, lag, and ID format, with no filler.

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

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

For a read-oriented tool with no output schema and no annotations, the description covers the essential return values, retention limits, latency, and required ID format. Pagination or response envelope details are not mentioned, but that is a minor gap given the moderate complexity.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description mainly reinforces the ad_account_id bare-ID constraint and the 30-day cap rather than adding new parameter semantics. Baseline 3 is appropriate.

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

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

States it returns Google Ads account change history: who changed what, when, with editor email, surface, operation, and changed fields. The Google Ads scoping and 10-digit customer ID clearly distinguish it from the sibling adsap_get_account_activities.

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

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

Clearly frames the tool for recent account edits and explicitly warns that history is only retained for 30 days, directing older lookups to the Google Ads UI. It also flags the ~3-minute lag. It does not explicitly contrast with sibling tools, but the Google-specific context is enough.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly explains what the tool returns per action, how the level parameter changes row granularity, and the key Google limitation that cost is not split by conversion action. It stops short of explicitly stating auth requirements or error behavior, but the read-oriented wording and return-column breakdown make the tool's behavior clear.

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 every sentence earns its place: user-intent triggers, returned fields, level semantics, the no-cost limitation, and the ID format. Despite its length, it is tightly structured and avoids redundant repetition of 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?

For a tool with no output schema and no annotations, the description is thorough: it defines the expected output columns, explains both levels, calls out the missing cost dimension, and directs users to the sibling tool for that data. No essential call-time ambiguity remains.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningfully beyond the schema. It clarifies that ad_account_id is a bare 10-digit customer ID, that rows are ordered by all_conversions descending, that campaign_id forces campaign level, and why there is no spend/CPA column. This gives an agent practical calling context the schema alone does not.

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

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

The description uses a specific verb and resource, 'Break a Google Ads account's conversions down BY CONVERSION ACTION', and gives concrete examples (Purchase vs Lead vs Sign-up vs phone call). It also distinguishes itself from the lumped-total view and from adsap_google_get_insights by explicitly noting what it does not include.

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

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

It explicitly states when to use the tool: when the user asks which conversions the account is getting, whether a specific action is firing, or why All conversions is far above Conversions. It also names the alternative tool for cost/CPA data, giving an agent clear selection criteria.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: cache-first with auto-refresh, previous-period comparison, only entities with impressions appearing, PMax lacking ad groups/keywords, Search-network-only competitive metrics reading 0 elsewhere, search_lost_is_budget being campaign-level-only with the key ABSENT elsewhere, quality_score being keyword-only with nulls, and the approximate-share note when Google caps days.

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

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

The description is long, but nearly every sentence earns its place by adding metric semantics, level-specific caveats, or routing guidance. It is front-loaded with the core purpose and return shape; however, the dense wall-of-text format with semicolon-heavy metric lists reduces scannability and could benefit from bullets or structured sections.

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

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

There is no output schema and no annotations, yet the description covers the return structure, the metrics on summary and rows, per-level availability, id formats and downstream usage, and the Meta alternative. The only minor omission is explicit cursor/pagination semantics, but limit/cursor are already in the schema and the tool is otherwise fully specified for an agent to invoke correctly.

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

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

Schema coverage is high (82%), but the description meaningfully exceeds the schema: it explains that ad_group/keyword levels share the cached sync with no extra API budget, that refresh spends Google API budget, the exact source of ad_account_id, the distinction between conversions and all_conversions, and the level-specific availability of quality_score and competitive metrics. This is far beyond what the schema provides.

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

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

The description opens with a precise verb-resource pair: "Get Google Ads performance insights for an account, at campaign, ad-group, or keyword level." It names concrete return components (account summary, previous-period comparison, sortable per-entity table, optional timeseries) and explicitly distinguishes the closest sibling by saying "For Meta insights use adsap_get_insights."

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 tells when to use the alternative (Meta insights via adsap_get_insights), explains the cache-first behavior and that refresh="Spends Google API budget", notes that ad_group/keyword levels "ride the same cached sync — no extra API budget," and tells where the ad_account_id comes from and how keyword ids should be passed onward. This is explicit when/when-not/alternative guidance.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses the return contents (average monthly searches, competition, top-of-page bid range in account currency) and the account-id formatting requirement. It does not mention pagination behavior or potential rate limits, but for a read-style research tool the disclosure is solid.

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

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

The description is compact and front-loaded: the core function appears in the first sentence, followed by return value, usage guidance, account-id clarification, and platform exclusion. Every sentence adds actionable information with no filler or redundancy.

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

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

For a 7-parameter tool with no output schema, the description covers the key inputs (keywords/URL, geo, language, ad_account_id) and output fields. It misses explicit pagination guidance and any mention of page_size limits, though these are encoded in the schema. The workflow pointer to the campaign-creation tool helps complete the context.

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

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

Schema coverage is high (86%), so the baseline is 3, but the description adds meaning beyond the schema: it explains why geo_target_ids and language_id matter (volume consistency), clarifies ad_account_id format, and connects output to adsap_google_create_search_campaign.ad_group.keywords. It also reinforces the keywords/URL combination without repeating exact schema rules.

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

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

The description uses a specific verb ('Get') plus a precise resource ('keyword suggestions with search volume from Google Keyword Planner') and ties it to a Google Search campaign context. It clearly distinguishes itself from Meta's world with the explicit 'Google-only — Meta has no keyword-planner analog.'

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

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

The description explains how to use the tool: seed with keywords and/or a URL, pass geo_target_ids and language_id for target-matching volumes, and feed outputs into adsap_google_create_search_campaign. It also gives an exclusion ('Google-only — Meta has no keyword-planner analog'), though it doesn't explicitly name a competing sibling or state 'use this instead of X.'

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

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

With no annotations, the description carries the behavioral disclosure burden. It conveys that this is a read-only listing operation, specifies the output shape, and explains that the returned customer ID should be reused as ad_account_id in downstream tools. It does not cover pagination or empty/error behavior, but the core behavior is clearly 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?

Every sentence earns its place: action+scope, return fields, selection behavior, Meta alternative, and the critical platform rule. It is front-loaded with the core purpose and wastes no words, even though the PLATFORM RULE section is typographically emphatic.

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

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

With no output schema or annotations, the description supplies most of the contract: output fields, downstream ID reuse, user interaction rule, and cross-platform routing. It falls just short of complete because it omits limit/cursor pagination semantics and what to do when zero accounts are returned, but for typical invocation it is sufficient.

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

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

Schema description coverage is 0%, so the description needed to explain limit and cursor. It does not mention either parameter, leaving an agent to infer limit only from numeric bounds/default and cursor as an opaque string. The description adds no parameter-level meaning beyond what the raw schema already shows.

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

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

The description states a specific verb+resource: 'List Google Ads accounts linked in this workspace' and details the returned fields (10-digit customer ID, name, currency, timezone, status). It clearly distinguishes itself from adsap_list_ad_accounts for Meta accounts, so an agent can tell the tools apart.

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 (to pick a Google Ads account, ask the user if several), names the alternative for Meta accounts (adsap_list_ad_accounts), and provides a platform rule to call it alongside the Meta tool when no platform is named. This is exemplary routing 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that templates are saved/wizard-created and explains the portable vs. account-bound scoping, but it does not explicitly state that this is a read-only operation, nor does it describe the response or pagination behavior.

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

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

The description is three focused sentences with no filler. Each sentence adds distinct value: what the tool lists, how the payload can be used, and the portability distinction between template types.

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 list tool with no output schema and no annotations, the description should more fully explain the return shape and pagination semantics. It covers the domain content well, but an agent still lacks a concrete sense of the response structure and how cursor/limit drive paging.

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

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

Schema description coverage is 50%, so the description partially compensates: it clarifies customer_id behavior (portable plus bound templates) and mentions channel-level organization. However, cursor is never explained, and limit has only schema constraints with no semantic description.

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

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

The description uses a specific verb and resource: 'List saved Google campaign templates.' It also explains the template contents and distinguishes these as wizard-saved Google templates, which separates them from the non-Google adsap_list_ad_templates sibling.

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

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

The description gives a downstream use case ('feed it back to a user as a starting point or compare setups') but does not state when to choose this tool over alternatives like adsap_google_manage_ad_template or adsap_list_ad_templates. No explicit when-not-to-use or sibling differentiation is provided.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly explains what the tool returns (Audience resources and UserLists with approximate sizes), what those IDs are used for, and what format ad_account_id must take. It does not cover pagination or rate limits, but for a read-only list operation the behavioral disclosure is strong.

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 dense but every sentence earns its place: it defines the two output categories, explains the relationship to campaign creation tools, gives the primary use cases, clarifies the parameter format, and names the sibling tool for the Meta case. No filler or redundancy.

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

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

With no output schema, the description reasonably explains what will be returned: Audience resources, UserLists, and approximate sizes. It also covers the only input parameter and the use cases. It could add more detail about the exact response shape, but the description gives an agent enough context to call the tool correctly and interpret the result at a high level.

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

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

Schema coverage is 100%, and the schema already documents ad_account_id as a bare 10-digit customer ID with no dashes or act_ prefix. The description mostly repeats this, adding only the helpful hint that the ID comes from adsap_google_list_ad_accounts. This is a small increment above the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ('List a Google Ads account's audiences'), and distinguishes two audience types: Audience resources and UserLists. It also ties the result to use in adsap_google_create_pmax_campaign / adsap_google_create_demand_gen_campaign, which differentiates it from siblings like adsap_list_custom_audiences.

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

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

The description explicitly says when to use the tool: resolving audience names to IDs before creating PMax or Demand Gen campaigns, or reviewing existing remarketing lists. It also names the Meta equivalent (adsap_list_custom_audiences) as the alternative, leaving no ambiguity about which tool to select.

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

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

With no annotations, the description carries the behavioral disclosure burden. It goes beyond the schema by disclosing cache-first behavior with a 1-hour auto-refresh and listing the returned fields. It could mention error conditions or pagination behavior, but it provides meaningful context for a read-only listing tool.

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

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

The description is three focused sentences with no filler. It front-loads the core action and cache behavior, then adds return fields, parameter source, and the Meta alternative. Every sentence earns its place.

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

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

The description is adequate for a basic call: it explains the core purpose, cache behavior, return fields, and ad_account_id source. However, with no output schema and five parameters, it omits pagination mechanics, status_filter meaning, and any API-budget or error context. It is not fully complete for sophisticated use.

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

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

Schema description coverage is only 40%, so the description needs to compensate for the undocumented parameters. It enriches ad_account_id by pointing to the sibling tool, but it does not explain limit, cursor, or status_filter semantics. Pagination and filtering behavior are left entirely to the schema's 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?

The description states a specific verb and resource: 'List Google Ads campaigns in a Google Ads account.' It also names the returned fields and explicitly differentiates itself from the Meta tool adsap_list_campaigns, so an agent can distinguish it from siblings.

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

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

The description explicitly says 'For Meta campaigns use adsap_list_campaigns instead,' and tells the agent that ad_account_id comes from adsap_google_list_ad_accounts. It also explains the cache-first behavior, which helps the agent decide when the call will hit Google's API.

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

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

Annotations are absent, so the description carries the behavioral burden. It discloses the downstream consequence of empty results (bidding failure/silent fallback) and clarifies the expected ID format ('bare 10-digit customer ID'). It doesn't cover pagination or rate limits, but for a read-only list tool the provided context is strong.

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 slightly longer than absolutely necessary, but it is front-loaded with the core purpose and every sentence adds value: usage timing, consequences, diagnostic role, parameter clarification, and sibling alternatives. The information density is high with no fluff.

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

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

Despite having no output schema, the description lists the returned fields and covers prerequisites, failure modes, and alternative tools. It gives an agent everything needed to decide when to call it and how to interpret a zero-result scenario. No critical selection or invocation context is missing.

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

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

Schema coverage is 100%: both ad_account_id and include_removed have clear descriptions. The tool description only restates the ID format and adds no new parameter-level meaning. Baseline 3 is appropriate because the schema already documents the parameters fully.

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-resource pair: 'List a Google Ads account's conversion actions' and enumerates the exact fields returned (name, type, category, status, etc.). It also contrasts itself with Meta conversion tools by naming adsap_get_pixel_details and adsap_list_custom_conversions, so an agent can distinguish it from sibling tools 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?

Explicitly says when to use it ('BEFORE creating campaigns with conversion-based bidding') and what failure modes occur if zero enabled actions exist ('bidding modes will fail or a Search campaign will silently fall back'). It also names the Meta alternatives for pixels/conversions, providing clear when-not 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?

With no annotations, the description carries the full behavioral disclosure burden and does so thoroughly: assets are account-scoped, immutable, and cannot be deleted; stopping serving requires removing links; usage_for_asset_id returns usage in campaigns, ad groups, PMax asset groups, account-level links, and inside ads. This adds rich context well beyond the schema.

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

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

The description is longer than two sentences, but every sentence earns its place: output breakdown, immutability and deletion constraint, removal path, usage pre-flight, integration with create tools, and ad_account_id format. The purpose is front-loaded and the structure flows logically from what the tool does to how to use it.

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

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

For a tool with no annotations and no output schema, the description covers the full invocation context: scope, output categories, immutability, deletion restrictions, usage lookup, reuse in create tools, filtering semantics, and ID formatting. An agent has enough information to select and correctly invoke this tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: ad_account_id is specified as a bare 10-digit customer ID from adsap_google_list_ad_accounts, usage_for_asset_id is explained as returning usage locations instead of the list, and asset_type omission is clarified as returning all three types. These additions justify a 4.

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

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

States a specific verb and resource: lists Google Ads account library creative assets, enumerating IMAGE, YOUTUBE_VIDEO, and TEXT with details such as dimensions, slot fit, video id, and title. It distinguishes itself from the generic sibling adsap_list_creative_assets by explicitly scoping to a Google Ads account and describing Google-specific output semantics.

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

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

Gives clear context on when to use the tool: as a pre-flight via usage_for_asset_id to decide whether an asset can stop serving, and as a source of asset ids for create tools. It names adsap_google_manage_extension as the alternative for removing extension links and notes asset-group edits are pending, though it does not explicitly contrast against the generic list 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?

With no annotations provided, the description carries full behavioral burden and meets it well. It discloses account-level row semantics, the read-mostly nature of Google-automated extensions, the absence of performance metrics in v1, the fact that image assets are never updatable, and the exact ad_account_id format. These are meaningful behavioral details beyond what the schema alone provides.

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 dense but every sentence earns its place, covering filters, account-level behavior, automated extensions, downstream use, and platform context. The first sentence is somewhat heavy with parentheses, but overall the text is well-structured and free of 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 tool with no annotations and no output schema, the description is close to complete: it explains what is listed, how filtering works, what the account-level rows mean, when mutation is appropriate, and which identifier format to use. It could add more about the exact return row shape or pagination, but the limit schema and asset_id mention cover the main invocation concerns.

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 75%, so the baseline is already solid. The description adds valuable semantics: campaign_id filters campaign links only, ad_account_id must be a bare 10-digit Google Ads customer ID, and field_type maps to the seven named extension types. It does not discuss limit, but the schema's default/min/max are sufficient for that 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 opens with a clear verb-resource-scope statement: 'List the extensions ... linked to Google Ads campaigns AND at account level.' It names all seven extension types and explicitly references the managing sibling tool, making it obvious that this is the read/list counterpart to adsap_google_manage_extension rather than a mutation tool.

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

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

It states optional filters ('Optionally filter to one campaign_id ... and/or one field_type'), clarifies that account-level rows with campaign_id null apply to all eligible campaigns, and warns against editing AUTOMATICALLY_CREATED extensions. It also routes modification use cases to adsap_google_manage_extension, though it does not use explicit 'use this when' phrasing.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does well: it explains the sync lag on a fresh link, interprets an empty list (no link, no products, or pending sync), and tells the agent to say which is likely. It also flags case-sensitivity of returned labels. It doesn't describe the return payload shape or pagination, but for a list tool that's a minor gap.

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

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

The description packs purpose, usage guidance, edge-case interpretation, and parameter note into a few efficient sentences, front-loading the main purpose. It is longer than minimal but every sentence earns its place by adding actionable guidance rather than fluff.

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

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

For a single-parameter, read-only list tool with 100% schema coverage and no output schema, the description covers the essential context: when to use it, how to interpret results, and the parameter format. The main omission is the exact return structure, but it's reasonably inferable for a label-list tool.

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

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

Schema coverage is 100% — ad_account_id is fully documented in the schema ('Bare 10-digit Google Ads customer ID... No dashes, no act_ prefix'). The description repeats 'ad_account_id is the bare 10-digit customer ID', confirming but not adding meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the distinct Merchant Center feed labels') and scopes it to products synced via the Merchant Center link. The description also ties it to the shopping-campaign workflow, which distinguishes it from the many sibling list tools like adsap_google_list_ad_accounts or adsap_google_list_campaigns.

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

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

Explicitly says to use it 'before adsap_google_create_shopping_campaign when the user wants to restrict a standard Shopping campaign to one feed' and instructs to pass the returned feed_label exactly as-is. It implies the alternative (omitting feed_label targets all feeds) and names the condition, but does not explicitly name a sibling alternative tool for when you don't need feed labels.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses the dry_run default TRUE and the required two-call confirm-then-apply flow, the null-removes-field merge semantics for payload_patch, the account-binding behavior for asset-bearing payloads, the validation against the exact wizard shape, and the non-destructive relationship to live campaigns. This is exactly the kind of behavioral context an agent needs beyond the schema.

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

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

The description is dense but well-organized: the first sentence establishes the core purpose, the middle sentences cover update semantics and account-binding, and the final sentences cover the dry_run workflow and the safety guarantee. Every sentence earns its place, though the length is at the upper edge of what an agent can parse quickly. The structure front-loads the most important scoping information.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description is remarkably complete. It covers the create/update/delete modes, the channel constraint, the validation behavior, the dry_run workflow, the customer_id requirement, the merge semantics, and the safety boundary with live campaigns. An agent has everything needed to call this tool correctly and to know what will happen before and after the call.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description adds meaningful semantics on top: it explains the dry_run two-call workflow, the top-level merge semantics of payload_patch (null removes a field), the account-bound vs portable distinction for customer_id, and the fact that a template never changes channel. The only minor gap is that the description doesn't spell out that action is the sole required parameter, but the schema already does that clearly.

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 phrase — 'Create, update, or delete a saved Google campaign template' — and immediately distinguishes the resource from the sibling reader adsap_google_list_ad_templates. It enumerates the per-channel wizard content (budget, bidding, geo, languages, ad text, extensions, asset picks) and the six channels, so an agent can tell exactly what this tool manages and how it differs from nearby create-campaign tools.

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

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

The description gives explicit when-to-use guidance: it names the sibling reader (adsap_google_list_ad_templates) as the source of template shapes and IDs, explains the dry_run default workflow ('preview, confirm with the user, then call again with dry_run:false'), and states the account-bound vs portable distinction that determines when customer_id is required. It also clarifies that templates are launch presets only and deleting one never touches live campaigns, which prevents a dangerous misuse.

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

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

With no annotations, the description carries full disclosure burden and does so exceptionally: atomic create_and_link, account-scoped update side effects, Google's AD_IMAGE allowlist gate, non-mutability of image assets, and all-or-nothing error semantics are all stated explicitly. This goes far beyond a generic 'manage' statement.

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?

Long but information-dense; every sentence earns its place, and the most decision-relevant facts (scope, ops, account-scoped update warning, AD_IMAGE gating) are front-loaded. The length is proportionate to the tool's complexity.

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

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

Covers operations, levels, prerequisites, constraints, and failure modes thoroughly. The only notable omission is the response/return format, and there is no output schema to fill that gap — minor for a mutation tool against otherwise excellent coverage.

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

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

Schema coverage is 94%, so the schema already documents most fields. The description adds genuine meaning beyond it by explaining op behavior, the level distinction, the 20-item cap, asset-id provenance, and the bare 10-digit ad_account_id format — slightly redundant with schema in places but clearly additive.

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

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

The description names a specific resource (Google Ads extensions), enumerates all six supported types, the campaign/account scope, and the four operations. It clearly distinguishes itself from sibling tools like adsap_google_list_extensions and adsap_google_upload_asset without merely restating the title.

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

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

Explicitly instructs the agent to call adsap_google_list_extensions first, route image bytes through adsap_google_upload_asset, and use dry_run:true before create. It also explains that unlink is the only way to stop an extension serving since assets cannot be deleted — strong when-to-use and prerequisite 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?

No annotations are provided, so the description carries the full burden, and it discloses high-impact behavior: atomic batch adds, atomic replace because Google text/match type are immutable, new id and performance-history reset on replace, status/bid carryover, and campaign-level negative scope. It also explains the composite ID format and where IDs come from.

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 well structured; each sentence covers an operation, a constraint, or a sibling-routing decision. The op labels make it scannable, and there is no filler.

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

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

Despite no annotations and no output schema, the description gives enough to invoke correctly: per-op semantics, parameter applicability, ID provenance, side effects, and alternatives. It even tells the agent to run dry_run first, which compensates for the absent safety annotations.

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

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

Schema coverage is high (78%) and the schema already documents fields such as cpc_bid currency and match-type enum. The description adds operation-level meaning beyond the schema: it specifies which parameters apply per op, explains that add is atomic, and tells the agent where keyword IDs come from and that add ops return created IDs. A small gap remains for the dry_run return behavior despite the 'always dry_run first' instruction.

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 exact resource (Google Ads Search keywords) and operation family ('Manage ... AFTER creation'), then enumerates four explicit operations (add, add_negative, replace, remove) with concrete effects. It differentiates from siblings by naming the tools for pause/enable and bid-only changes, so an agent can select it correctly.

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 routing: use this for keyword lifecycle operations after creation; pause/enable should go to adsap_google_set_entity_status and standalone bid changes to adsap_google_update_entity. It also tells the agent to 'Always dry_run: true first' and ties each operation to its required parameter (ad_group_id, campaign_id, keyword_id, campaign_negative_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?

With no annotations, the description carries the full disclosure burden and succeeds. It reveals critical behavioral traits: criteria are immutable and must be removed then re-added, geo/language criterion ids equal constant ids while audience criterion ids must be captured from the add response, Google's default mode is targeting when no mode is set, and dry_run should always be true first. These go far beyond any schema and fully inform the agent of side effects and response expectations.

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

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

The description is long but information-dense with no filler. Every sentence adds a distinct constraint, example, or routing rule. The most important scoping statement is front-loaded, and dense clauses like 'GEO, LANGUAGE and AUDIENCES' are immediately followed by operation-specific rules. This is justified complexity for an 11-parameter tool.

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

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

For a complex tool with no output schema, the description covers all invocation-critical aspects: ops, levels, combination constraints, product-type restrictions, Demand Gen exceptions, removal id mechanics, immutability, dry-run guidance, and sibling routing. It even references the add response field created_criteria[].entity_id, giving the agent the information needed to capture audience criterion ids for later removes. Nothing necessary for correct invocation is missing.

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

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

Although schema description coverage is high (82%), the description adds substantial meaning beyond the schema: the difference between user_list_id and audience_id (Demand Gen), the composite criterion_id format '<parent_id>:<criterion_id>', the rule that audiences cannot combine with geo/languages in one call, and the fix for search-language targeting deprecation. It also ties parameters to sibling tools like adsap_google_list_audiences and adsap_google_search_geo_targets, making parameter values reliably discoverable.

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-resource pair ('Manage a Google Ads campaign or ad group's targeting AFTER creation') and names the exact scope: GEO, LANGUAGE, and AUDIENCES. It clearly distinguishes itself from the sibling adsap_google_manage_keywords by explicitly routing campaign negative keywords to that tool, so an agent can select the right tool 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?

The description gives explicit when-to-use guidance: after campaign creation, for add/remove of geo/language/audience criteria, and with channel-specific rules (Search/Shopping, Display, Performance Max, Demand Gen, Video). It also provides an explicit when-not-to-use by stating 'Video supports no audience edits' and directing campaign negative keyword removal to adsap_google_manage_keywords op 'add_negative'.

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