Adbloop Meta Ads

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

The description adds key behavioral details beyond the readOnlyHint=false annotation: 'Created PAUSED' and 'WRITES live'. This informs the agent that the ad will not run immediately and that the operation is a write. No contradiction with annotations.

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

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

The description is extremely concise with three sentences, each serving a purpose: what the tool does, a key behavioral note (paused), and input options. No unnecessary words or repetition.

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

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

Given 11 parameters, no output schema, and a write operation, the description covers the core function and a critical behavioral trait (paused). However, it lacks details on return values, error scenarios, or additional context like required permissions, making it minimally adequate.

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

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

With only 27% schema description coverage, the description compensates by grouping parameter options (creative_id, image_hash, or ad copy fields). However, it does not explain individual parameters like 'cta', 'ad_name', or 'website_url' in detail, leaving 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 clearly states it adds a new ad with creative to an existing ad set ('Add a NEW ad to an EXISTING ad set'). It distinguishes itself from bulk creation tools by implying single ad creation, but does not explicitly name sibling alternatives. The verb 'Add' and resource 'ad to ad set' are specific.

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 input options ('accepts either an existing creative_id, a library image_hash, or ad copy fields'), but does not specify when to use this tool versus alternatives like 'bulk_create_campaigns' or 'list_ads'. No explicit when-not or exclusion criteria are provided.

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

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

The description adds significant behavioral context beyond the minimal annotation (readOnlyHint=false). It discloses that the tool writes live, is rate-limit-safe, validates inputs, honors plan limits and spend guardrails, and auto-selects assets. No contradiction with annotations.

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

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

The description is four sentences, each adding essential information. No extraneous words, and key details are front-loaded. Every sentence earns its place.

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

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

For a complex bulk creation tool with no output schema, the description covers purpose, behavioral traits, and one parameter. Missing details on return values, prerequisites (e.g., authentication), and several parameters. Adequate but with clear gaps.

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 some meaning for parameters (e.g., imageUrl format, auto-use of Page/Instagram/pixel) but does not explain many top-level parameters like confirm, page_id, pixel_id, or catalogId. Given 0% schema coverage, the description partially compensates but is incomplete.

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

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

The description clearly states the tool creates many Meta campaigns on one account, with specific verbs ('Create', 'WRITES') and resource ('Meta campaigns'). It distinguishes from siblings like 'bulk_create_multi_account' by specifying 'on ONE account'.

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

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

The description provides clear context: single-account usage, rate-limit-safe, and respects plan limits. However, it does not explicitly exclude usage for multi-account scenarios or compare with alternatives like 'validate_campaigns' or 'estimate_bulk_create'.

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

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

Beyond the readOnlyHint: false annotation, the description discloses key behaviors: currency-aware guardrails, capacity checks, skipping throttled accounts, and correct per-account setup. The 'WRITES live' warning is explicit.

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

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

Two sentences, front-loaded with the most critical information. No unnecessary words; every part adds value.

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

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

While the description covers core behavior, it lacks details about the return value or success/error states. For a write tool with no output schema, this information is important for the agent to interpret results.

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

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

Schema coverage is 33% (only account_ids described). The description adds context about per-account handling but does not elaborate on the confirm parameter or campaigns structure beyond the schema's own detailed field descriptions.

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

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

The description clearly states the tool's purpose: launching the same campaign set across multiple ad accounts. It specifies the limit of 5 accounts and mentions chaining for more, differentiating it from siblings like bulk_create_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 provides usage guidelines: up to 5 accounts, chain for more, and that throttled accounts are skipped. It implicitly advises against using for fewer accounts (use single-account tool) but does not explicitly name alternatives.

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

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

Annotations already declare readOnlyHint=true, and the description adds the specific return values (GO/TIGHT/SPLIT/WAIT_OR_SPLIT/WAIT + utilization + regain minutes). This gives concrete behavioral insight beyond the annotation.

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

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

Two sentences, no wasted words. The first sentence states purpose and timing, the second adds return details. Front-loaded and efficient.

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

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

For a simple check tool, the description covers purpose, timing, and return format. Minor gaps: no explanation of parameters nor error conditions, but overall adequate given the tool's 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 coverage is 0% and the description does not explain the parameters (meta_account_id, campaign_count). It implicitly suggests meta_account_id is the account, but campaign_count remains unexplained. Given low coverage, the description should compensate but 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 clearly states the verb 'check' and the resource 'ad account's current Meta API rate-limit headroom', with context 'BEFORE a bulk run'. It distinguishes itself from sibling tools that perform create/update/delete operations.

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 advises using this tool before a bulk run, providing a clear when-to-use context. It does not mention when not to use or list alternatives, but the sibling set makes the intent 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?

The description adds behavioral context beyond annotations: campaign is created paused, counts toward monthly limit, and is free-plan friendly. Annotations only indicate readOnlyHint=false, so the description enriches 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 very concise—two sentences and a note—yet conveys the core purpose, usage context, and a key requirement. Every sentence adds value.

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

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

Despite good purpose clarity, the description lacks detail on return values, parameter semantics for most fields, and constraints beyond the free plan. With 15 parameters and no output schema, more completeness is needed for effective 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 7%, so the description should compensate but only explains imageUrl. Most parameters (e.g., useCBO, cboBudget, headline) lack explanation, leaving the agent without guidance on their meaning or use.

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

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

The description clearly states it creates a single Meta campaign in paused state, and distinguishes from bulk_create_campaigns. The verb 'Create' and resource 'Meta campaign' are specific, and sibling differentiation is explicit.

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

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

The description tells when to use this tool (single campaign) and offers an alternative for bulk creation. It also notes the need for imageUrl for image ads. However, it does not explicitly exclude other scenarios, so not a perfect 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?

Discloses that deletion is permanent and irreversible, and requires confirmation. This adds meaningful context beyond the annotations (destructiveHint: true) by specifying the irreversible nature and the confirm flag.

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

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

Extremely concise: two front-loaded sentences that contain all essential information with no 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 simple deletion tool, the description covers the key behavioral aspects (permanence, confirmation). It lacks details on return value or error states, but given the simplicity and lack of output schema, it's largely sufficient.

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

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

The description adds context for campaign_ids ('by ID') and confirms the purpose of the confirm parameter. However, the meta_account_id parameter is not mentioned in the description, and with only 33% schema coverage, the description does not fully compensate.

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

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

Clearly states 'PERMANENTLY delete campaigns/ad sets/ads by ID' – a specific verb and resource. The description distinguishes from sibling tools like pause_campaigns by emphasizing irreversibility.

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 'Use pause instead if unsure', providing a clear alternative. Also notes the requirement for confirm:true, guiding the agent on when to use this tool.

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

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

Annotations already provide readOnlyHint: true, and the description reinforces this with 'Read-only'. The description adds behavioral context by specifying it is an estimation rather than actual creation, but it does not discuss auth needs, rate limits, or potential side effects beyond the read-only nature.

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

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

The description is extremely concise with two short sentences, no redundant information, and all content is relevant. It is front-loaded with the core purpose.

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

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

For a tool with one parameter and no output schema, the description is adequate but lacks detail on the return format (e.g., time in seconds/minutes) or any contextual prerequisites. It covers the basics but leaves room for clarification.

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

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

Schema description coverage is 0% for the single parameter 'count'. The description only indirectly implies that 'count' is the number of campaigns via 'for N campaigns', but does not specify units, valid range, or format. This minimal addition is insufficient given the low coverage.

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

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

Description clearly states it estimates time for bulk creation, with a specific verb 'estimate' and resource 'bulk creation'. It distinguishes itself from the sibling tool 'bulk_create_campaigns' which actually performs the creation. The 'Read-only' tag further clarifies it is a simulation.

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

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

No explicit guidance on when to use this tool versus alternatives like 'bulk_create_campaigns'. The description does not mention prerequisites, such as needing to call this before actual creation, nor does it provide context for when to use it instead of other estimation or validation tools.

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

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

Annotations declare readOnlyHint=true, and description states 'List' which is consistent. Description adds value by detailing what specific fields (Page NAME, Instagram username, pixel) are returned, going beyond the annotation.

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

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

Two concise sentences: first specifies action and output, second gives use case. No filler, perfectly front-loaded and efficient.

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

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

For a simple list tool with no parameters and no output schema, the description adequately covers purpose, output fields, and use case. No critical gaps given the 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?

No parameters exist, so baseline is 4. The description explains the purpose without needing parameter details, adding meaning beyond the empty 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?

Description clearly states verb 'List' and resource 'Meta ad accounts connected to this Adbloop user', and specifies output fields (Page NAME, Instagram username, pixel). No sibling tool lists accounts, so it distinguishes well.

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

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

Description explicitly says 'Use this to resolve a spoken account/page name to IDs', providing clear context. While it doesn't mention when not to use, the use case is well defined and alternatives are not needed as no sibling tool serves the same purpose.

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

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

Annotations already declare readOnlyHint=true, so the description's 'Read-only' adds no new safety info. It does add 'Full tree' clarifying the hierarchical nature, but lacks details on potential behavioral traits like pagination, error handling, or size limits.

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

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

The description is extremely concise with two short statements. The key action 'Full tree of one campaign' is front-loaded. Every word serves a purpose.

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

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

Given no output schema and 0% parameter descriptions, the description is insufficient for an agent to confidently invoke the tool. It does not describe the output structure or parameter semantics, leaving critical gaps.

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

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

With 0% schema description coverage, the description is entirely responsible for explaining parameters. It provides no information about campaign_id or meta_account_id beyond names and required status. The agent gets no help on format, source, or usage.

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

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

The description clearly states the tool returns the full hierarchy of a campaign including ad sets and ads, using specific verbs ('Full tree') and identifies the resource (campaign). It distinguishes from siblings like list_campaigns and list_adsets which return flat lists.

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

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

The description includes 'Read-only' which implies safe usage, but does not explicitly state when to use this tool versus alternatives like list_adsets or list_ads. No exclusions or comparative guidance is provided.

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

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

The description states 'Read-only,' which is consistent with the annotation readOnlyHint=true. It adds a note about compatibility with other tools, but does not disclose behavioral traits like pagination, rate limits, or the effect of the 'limit' parameter. Since annotations already cover the safety profile, the description adds limited new behavioral insight.

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

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

The description is extremely concise: two sentences plus a note. The main action is front-loaded, and every sentence serves a purpose without unnecessary verbosity.

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 is simple (one optional parameter, no output schema), the description should explain the parameter and the return format. It explains neither. The note about image_hash/imageUrl hints at output fields but does not fully describe the structure, leaving the agent with gaps.

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

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

The input schema has one parameter 'limit' with no description (0% coverage). The tool description does not mention this parameter at all, failing to add any meaning beyond the schema. With low schema coverage, the description must compensate, but it 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 clearly states the tool's purpose: 'List the user's saved creatives.' This is a specific verb+resource, and it distinguishes this tool from sibling tools (e.g., list_ads, list_campaigns) by focusing on 'creatives.'

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 includes a note about how the output (image_hash vs. imageUrl) relates to other tools (add_ad_to_adset, bulk_create_campaigns), providing some usage context. However, it does not explicitly say when to use this tool versus alternatives or mention any prerequisites.

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

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

The description confirms the read-only nature stated in annotations (readOnlyHint=true) and adds extra behavioral context: 'Editable only by the owner in Adbloop settings.' This discloses what happens beyond the tool itself (editing is external). No contradictions with annotations.

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

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

The description is extremely concise—only two sentences that directly state purpose and an important usage note. No superfluous words, and key information is front-loaded. 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?

Given the tool's simplicity (one parameter, no output schema, read-only), the description covers the core purpose and a behavioral constraint. However, it lacks details about what exactly 'spend safety limits' are, the structure of the response, and whether meta_account_id is required. For a minimal tool, this is adequate but leaves gaps.

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

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

The input schema has one parameter (meta_account_id) with no description (coverage 0%). The description does not mention or explain the parameter at all, leaving the agent to infer its meaning from the name alone. The description should have clarified what value is expected for meta_account_id.

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

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

The description clearly states the tool's function: 'View the spend safety limits for an account. Read-only.' It specifies a verb ('View') and resource ('spend safety limits'), and the read-only nature distinguishes it from any mutation tools. No sibling tool appears to have the same purpose.

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

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

The description provides some usage guidance by stating that limits are 'Editable only by the owner in Adbloop settings,' implying this tool is for viewing only. However, it does not explicitly state when to use this tool versus alternatives or provide when-not-to-use conditions. The guidance is implied but not thorough.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces 'Read-only' and adds 'Rate-limit-safe', which provides additional behavioral context beyond annotations (safety from rate limits). However, no other behaviors (e.g., pagination, output format) are 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 a single concise sentence that is front-loaded with key information. It is efficient, though could benefit from additional context about parameters.

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 7 parameters, no output schema, and no parameter descriptions, the description is insufficient. It does not explain how to use parameters or what the tool returns, leaving agents with significant ambiguity for a tool with 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?

The input schema has 7 parameters with only types/enums and 0% description coverage. The description does not elaborate on any parameter meanings or usage, failing to add value beyond the schema. The metrics list in the description hints at what the tool returns but not how parameters affect results.

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

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

The description clearly states the tool retrieves Meta performance metrics (spend, impressions, clicks, etc.) and specifies it is read-only. It distinguishes itself from sibling tools like list_ads or list_campaigns by focusing on insights/metrics.

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

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

The description mentions 'Rate-limit-safe' hinting at safe usage, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No 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?

The description adds 'Read-only' which aligns with the readOnlyHint annotation, but does not provide additional behavioral details beyond that. With annotations already covering this, the description offers minimal extra value.

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

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

The description is extremely concise at two sentences, front-loading the purpose and scope without any unnecessary words.

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

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

Given that there is no output schema and parameter descriptions are missing, the description is incomplete for a list tool. It does not explain return values or parameter specifics, leaving gaps for an AI agent.

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

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

Schema coverage is 0%, meaning the description should explain the parameters. It only hints at page_id via 'on a Facebook Page' but provides no details about the format or the purpose of meta_account_id. This is insufficient compensation for the lack of schema descriptions.

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

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

The description clearly states the verb 'List' and the resource 'lead-gen forms', and specifies the scope 'on a Facebook Page' and context 'for OUTCOME_LEADS campaigns'. This makes the tool's purpose highly specific and distinguishable from 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 explicitly mentions the campaign type (OUTCOME_LEADS) where this tool is applicable, providing clear context for when to use it. However, it does not mention when not to use it or suggest alternatives, 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?

Annotations declare readOnlyHint=true, and description explicitly says 'Read-only' and adds that it includes creative preview info. This adds behavioral context beyond the annotation without contradiction.

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

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

Two short sentences, front-loaded with the core action. Every sentence provides value with no wasted words.

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

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

For a simple read-only list tool, the description covers scope and a notable feature (creative preview). It lacks explanation of the limit parameter, but overall is adequate for basic usage.

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

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

The description explains that adset_id filters to a specific ad set and meta_account_id specifies the account, adding meaning beyond the schema. However, the limit parameter is not explained, and with 0% schema description coverage, more detail is needed for full clarity.

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 'List ads' with scope across account or inside one ad set, and mentions creative preview info. It distinguishes from sibling tools like list_adsets (lists ad sets) and add_ad_to_adset (creates 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?

Provides clear context for when to use: across account or by ad_set_id. However, it does not explicitly exclude alternatives or mention when not to use it, such as when detailed filtering is needed.

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

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

The description adds 'Read-only' which is consistent with the readOnlyHint annotation. It also discloses the returned fields, adding some behavioral context beyond the annotation. However, it does not mention pagination, rate limits, or other traits that would further enhance 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 two concise sentences with key information front-loaded. Every word adds value, and there is no unnecessary 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?

The description partially covers the return format by listing a few fields, but without an output schema, it should more thoroughly describe the response. It also lacks mention of pagination or filtering behavior, though the param 'limit' hints at it. Given the tool's moderate complexity, this is a noticeable gap.

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

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

The input schema has three parameters (limit, campaign_id, meta_account_id) with no descriptions, and the tool description provides no explanation of their meaning, valid values, or defaults. The description should compensate for the 0% schema coverage but fails to do so.

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 ('list ad sets'), the scope ('across the account or inside one campaign'), and key data fields returned ('budget, optimization goal, status'). It distinguishes itself from sibling tools like 'list_ads' and 'list_campaigns' by specifying the resource (ad sets) and unique fields.

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

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

The description implies usage context (listing ad sets with optional campaign filtering) and declares read-only behavior. It does not explicitly state when not to use this tool or name alternative tools, but the sibling list provides implicit differentiation.

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

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

Annotations already declare readOnlyHint=true; the description reinforces 'Read-only' and adds columns returned. However, it does not disclose pagination, rate limits, or behavior beyond what annotations cover.

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 short sentences with no unnecessary words, efficiently conveying purpose and safety.

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 lack of output schema, 0% parameter coverage, and presence of sibling listing tools, the description is insufficient. It omits details on sorting, default values, and parameter usage.

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

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

Schema description coverage is 0%. The description does not explain any of the four parameters (after, limit, status_filter, meta_account_id), leaving the agent without crucial guidance for filtering or pagination.

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 verb 'list' and resource 'campaigns', and mentions specific fields returned (status, budget, effective status). It is distinct from sibling tools like add_ad_to_adset or delete_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?

No guidance on when to use this tool versus alternatives like list_ads or list_adsets. The description only marks it as read-only, but fails to provide context or exclusion 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?

Annotations already provide readOnlyHint; description reinforces read-only and adds detail about file type (images/videos) and output format. No contradictions.

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

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

Three concise sentences front-load the action, then provide key details and use case. 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?

Simple tool with one parameter; description covers input, output, and use case. Missing details on pagination or error handling, but adequate for basic usage.

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

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

Schema coverage is 100% with a clear parameter description. The description adds marginal context ('Google Drive folder link (or bare folder ID)') but doesn't significantly enhance beyond 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?

Clearly states verb 'List', resource 'images/videos inside a PUBLIC Google Drive folder', and output 'name and Drive URL'. Distinguishes from siblings by specifying public folder requirement and use with bulk_create_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?

Provides specific precondition (must be public) and ideal use case ('create one campaign per image'). Lacks explicit when-not-to-use or alternatives, but 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?

Annotations already indicate idempotent and mutation. Description adds 'Reversible' which is useful behavioral context, but omits details on side effects, permissions, or immediate effect.

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

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

Extremely concise: two short phrases with no wasted words. Front-loaded with key action and resources.

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

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

For a simple mutation tool with no output schema, description covers basic purpose and reversibility but lacks parameter details and behavioral specifics like error conditions.

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?

Description does not explain the two parameters (campaign_ids, meta_account_id) beyond 'by ID'. With 0% schema coverage, this is insufficient 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?

Clearly states action (Pause) and resources (campaigns, ad sets, ads) with 'by ID' implying targeting. Differentiates from siblings like resume_campaigns and delete_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?

Mentions 'Reversible' indicating temporary nature, but lacks explicit guidance on when to use vs alternatives like resume_campaigns or delete_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?

Annotations indicate a mutation (readOnlyHint=false) and idempotence (idempotentHint=true). The description adds value by specifying the behavioral effect 'turns spend ON' and targeting paused entities, which is not stated in annotations. No contradictions.

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

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

The description is extremely concise with two sentences, no redundant information, and key action words front-loaded. Every word adds value.

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

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

Given no output schema and limited parameters, the description does not address return values, error conditions, or permission requirements. It covers the core action but leaves gaps for a user unfamiliar with the system.

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 has two parameters (campaign_ids required, meta_account_id optional) with 0% description coverage. The description only mentions 'by ID' and does not clarify campaign_ids format, limits, or the purpose of meta_account_id. This insufficiently compensates for the missing schema descriptions.

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

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

The description clearly states the verb 'resume' (activate) and the resource 'paused campaigns/ad sets/ads', and it specifies the effect 'turns spend ON'. This distinguishes it from the sibling tool 'pause_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 implies usage for resuming paused entities, but it does not explicitly state when to use this tool versus alternatives like 'pause_campaigns' or provide prerequisites (e.g., valid IDs, account access). The context is clear but lacks explicit 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?

Discloses return fields (names, IDs, audience sizes) and explicitly states 'Read-only', consistent with readOnlyHint annotation. Adds value beyond annotations.

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

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

Two concise sentences with no superfluous words. Information is front-loaded and efficient.

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

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

For a simple keyword search tool with no output schema, the description adequately covers purpose, usage, and return fields. No additional context needed.

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

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

Describes the 'query' parameter via 'by keyword', but fails to explain the 'meta_account_id' parameter despite 0% schema coverage. Major gap in 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 clearly states the tool searches Meta's targeting interests by keyword, with specific examples ('yoga', 'small business owners'). It distinguishes itself from sibling tools that focus on campaign/ad operations.

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 usage context ('useful when planning campaigns') and example keywords, but does not specify when not to use or mention alternatives.

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

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

Adds 'WRITES live' and guardrail check beyond annotations (readOnlyHint: false). Discloses that writes affect live data and requires account for budget validation.

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

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

Three concise sentences, each critical: purpose, guardrail requirement, and write behavior. No wasted words.

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

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

Covers purpose, required parameters, guardrails, and write behavior. Lacks note about optional fields being updatable individually, but sufficient for most use cases.

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%, baseline 3. Description adds meaning to meta_account_id by linking it to guardrail check, providing context 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?

Clearly states verb 'Change', specific resources 'campaign or ad set', and fields 'daily budget (and/or rename)'. Distinguishes from sibling tools that create, delete, pause, etc.

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

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

Provides context about account requirement for guardrail check, but does not explicitly say when not to use or name alternatives. Still clear for the intended use.

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

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

Annotations declare readOnlyHint=true, and the description confirms 'Read-only', adding context about per-row verdicts and spend guardrails. No contradictions. The description enriches with behavioral details beyond annotations, though it doesn't specify 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?

Two sentences with no filler. The first sentence front-loads the core purpose and read-only nature. The second adds verdict and optional parameter behavior. Every word is justified.

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

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

No output schema exists, but the description adequately describes the return (per-row verdicts). It covers the main input (campaigns) and optional meta_account_id. For a validation tool with these parameters, the description is fairly complete, though it could mention error handling or prerequisite setup.

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 (reported 0% coverage but actually includes detailed descriptions for nested fields) already explains sub-parameters well. The description adds that meta_account_id is for spend guardrails, but does not detail the campaigns array beyond its role. Given high schema coverage, description adds marginal value, earning a baseline 3.

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

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

The description clearly states the tool validates campaign rows before creation, using a specific verb ('check') and resource ('campaign rows'). It distinguishes from sibling tools like bulk_create_campaigns by focusing on validation rather than creation. The per-row verdicts (will_create, etc.) add 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 advises using this tool 'BEFORE creating', providing clear usage timing. It also notes that passing meta_account_id enables spend guardrail checks. While it doesn't explicitly state when not to use or list alternatives, the context from siblings implies this is for pre-flight validation.

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