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

With no annotations provided, the description fully discloses behavior: it is a WRITE (BULK) operation, runs a pre-flight ads_volume check, returns warnings, and starts spend immediately. This is adequate transparency for safe usage.

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, each serving a purpose: purpose, behavioral detail, and usage guideline. No unnecessary words, and the most important 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 no output schema and no annotations, the description covers the key aspects: what it does, the pre-flight check, warnings, and user confirmation. It could mention response format or error handling, but it is sufficient for a batch tool.

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

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

The description explains the skip_preflight parameter and the pre-flight process, adding context beyond the schema. The campaign_ids parameter is implied to be the list of campaigns to activate. Schema description coverage is 50%, but the description compensates well.

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 starts with 'Activate many campaigns in one Batch API call,' which is a specific verb+resource+mode. It clearly distinguishes from siblings like 'pause_campaigns_batch' and individual 'update_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?

It explicitly states 'Agents MUST confirm with the user before calling this (activation starts spend immediately).' This provides clear when-to-use guidance. However, it does not mention when not to use or suggest alternative tools like individual activation.

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, description carries full burden. It discloses write behavior, prerequisites (video_id, image_hash), critical constraint that image hashes are per-account, and Instagram placement condition. Lacks rate limits or error details but 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?

Five sentences, front-loaded with purpose, each sentence adds value. No redundancy, and the important note about image hashes is included without bloating.

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 the main use case and key constraints well given 13 parameters and no output schema. Could mention return value (e.g., created creative ID) but not essential for selection; the description enables 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?

Adds significant meaning beyond schema: explains the two data type branches (video_data vs link_data), maps specific parameters to each, clarifies conditional use of instagram_user_id, and notes image hash scope. Schema coverage is 77%, but description compensates richly.

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-text ad creative from an object_story_spec, distinguishes from sibling create_ad_creative_with_asset_feed, and explicitly marks it as a WRITE operation.

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 conditions for when to use: pass page_id plus ONE of video_data or link_data, and instagram_user_id if page not linked to Instagram. Does not explicitly exclude the asset feed sibling but the context implies this is for single-text creatives.

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. It discloses that Meta will auto-combine and optimize text combinations, and requires the parent ad set to be dynamic. However, it does not mention potential rate limits, authentication needs, or any side effects beyond creation. The behavior is adequately described for a creation tool.

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

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

The description is extremely concise with only two sentences. It leads with 'WRITE:' to signal action, then clearly states the tool's unique behavior and prerequisites. Every word serves a purpose 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?

Given 12 parameters and no output schema, the description covers the core mechanism (dynamic creative) and a key prerequisite. However, it does not explain what the tool returns (likely a creative object), nor does it address parameters like url_tags or instagram_user_id. It is adequate but not fully comprehensive.

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 42%, but the description adds value by grouping text arrays (bodies, titles, descriptions) and stating the requirement to provide either video_ids or image_hashes. This clarifies the relationship among parameters. However, it does not explain parameters like url_tags or instagram_user_id, leaving some ambiguity.

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 DYNAMIC (multi-text) creative using asset_feed_spec, which distinguishes it from the sibling create_ad_creative tool. The verb 'create' and resource 'ad creative' are specific, and the dynamic nature is emphasized.

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 that the parent ad set MUST have is_dynamic_creative=true, providing a crucial prerequisite. It also instructs to pass arrays of texts and either video or image identifiers, guiding parameter selection. However, it does not explicitly say when to use this vs. non-dynamic creative creation, though the dynamic distinction is implied.

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

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

Discloses default status (PAUSED), field semantics (targeting is Meta spec, bid_amount in cents), and conditional behavior (is_dynamic_creative required for multi-text). No annotations provided, so description carries the burden; covers key behaviors well.

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, zero waste. Front-loaded with purpose and default status, then field explanations, then critical constraint. Each 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?

Covers purpose, default behavior, key field semantics, and a crucial constraint. No output schema, so return value is not explained, but for a create operation this is acceptable. Could mention what is returned (e.g., ad set ID) for completeness.

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?

Adds value beyond the input schema for targeting (explains it includes geo_locations, interests, etc.), bid_amount (minor units), and is_dynamic_creative (must be true for multi-text). Schema coverage is 60%, but description fills gaps for important 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?

Description starts with 'WRITE: Create an ad set under a campaign', clearly stating the verb and resource. It distinguishes from siblings like 'update_adset' by focusing on creation and adding specific details like default status and field 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?

Provides clear guidance on when to use (create ad sets) and includes important constraints (e.g., is_dynamic_creative must be true for multi-text ads). Does not explicitly mention when not to use or contrast with update_adset, but the context of sibling tool names makes it adequate.

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 burden. It discloses default status, budget behavior, and required field nuances. It does not mention return values or error conditions, but the creation behavior is well explained.

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

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

Four concise sentences, front-loaded with 'WRITE: Create a new campaign.' Every sentence adds value without redundancy. Ideal length for a creation 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?

Given the complexity (9 parameters, budget strategies, required special categories), the description covers the essential workflow. It could mention return format, but without an output schema, this is acceptable. Slightly incomplete for full autonomy.

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 89% coverage, but the description adds significant meaning: clarifies the CBO/ABO budget distinction, recommends PAUSED over ACTIVE, and explains special_ad_categories usage. This goes beyond the schema's inline 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 explicitly states 'WRITE: Create a new campaign,' clearly identifying the verb and resource. It distinguishes from sibling tools such as update_campaign, delete_campaign, and activate_campaigns_batch.

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 explicit guidance: recommends PAUSED as default, explains when to pass budgets for CBO vs ABO, and notes that special_ad_categories is required. It gives clear context on when and how to use this tool effectively.

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, but the description clearly states it's a hard-delete (irreversible write operation), which is sufficient for a simple 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 concise sentences front-loading the action and providing usage guidance with no extra 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?

Adequately covers purpose and usage for a simple delete tool with one parameter and no output schema, though could mention return behavior.

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

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

The single parameter ad_id is self-explanatory from the tool name and description, but no additional semantic details are provided 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 clearly states 'Hard-delete an ad' with a specific verb and resource, distinguishing it from sibling tools like update_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?

Provides explicit guidance: 'Prefer update_ad status=ARCHIVED to keep history' indicates when to use an alternative.

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

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

Despite no annotations, the description discloses the destructive nature ('hard-delete') and that ads are also deleted. It is fairly transparent for a delete operation, though could mention irreversibility.

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, front-loaded with the action, no wasted words. Structure is efficient and clear.

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

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

For a simple one-parameter deletion tool, the description covers the core action and provides usage guidance. It does not explain return values, but that may be acceptable for a delete operation. Minor gap: no mention of idempotency or reversibility.

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

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

Schema description coverage is 0%, and the description adds no additional semantics beyond what the schema already provides for the 'adset_id' parameter. The parameter is not even explicitly mentioned.

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 'Hard-delete an ad set (and its ads)', using a specific verb and resource, and distinguishes itself from the sibling 'update_adset' tool by recommending an alternative.

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 advises to prefer 'update_adset status=ARCHIVED to keep history', providing a clear when-to-use vs. when-not-to-use recommendation with a specific alternative.

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

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

Discloses hard-delete and cascade behavior. Without annotations, description carries the burden and covers key destructive aspects, though could mention irreversibility or permissions.

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 'WRITE:' to signal mutation. No fluff, 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 simplicity, description covers purpose, behavior, and usage guidance. Completeness is adequate without output schema.

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

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

Single parameter campaign_id is implied but not described in detail. With 0% schema coverage, description should add format or constraints, but the purpose is clear.

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 it hard-deletes a campaign and cascades to ad sets/ads. Distinct from sibling update_campaign for soft deletion.

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

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

Explicitly recommends using update_campaign with ARCHIVED status for preserving historical data, providing clear when-not-to-use 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, description says it returns creative, issues, and preview link, which helps set expectations. However, it omits details like error handling, auth needs, 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?

Single sentence with front-loaded action and key results. Every word earns its place.

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

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

Template-level tool with no output schema; description gives high-level return info but lacks details on parameter format, error cases, and edge behavior.

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 0% description coverage; description only explains ad_id implicitly but completely ignores the 'fields' parameter, leaving its purpose and format 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?

Clearly states verb 'Get' and resource 'single ad by ID', distinguishing it from list_ads and other get tools. Also specifies return contents: creative, issues, preview link.

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

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

Implies usage when an ad ID is known, but provides no explicit guidance on when not to use it or alternatives like list_ads or get_creative.

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 burden. It implies a read-only operation but doesn't explicitly state safety or side effects, which is acceptable for a get 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 efficiently convey purpose, fields, and usage hint without any 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?

The description lists return fields, compensating for the missing output schema, and is adequate for a simple retrieval tool, though it omits 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?

Schema description coverage is 100%, so the description adds no additional parameter details beyond what is already in the schema.

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

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

The description clearly states 'Get detailed info for a single Ad Account' and lists specific fields, distinguishing it from siblings like list_ad_accounts.

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 advises 'use this for deep inspection of one account', providing clear context but not explicitly excluding alternatives or detailing when not to 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?

No annotations are provided, so the description must cover behavioral traits. It only states 'pull performance metrics,' which implies a read operation but does not disclose caching, rate limits, or other important behaviors.

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, with the first stating the core purpose and the second providing usage guidance. No redundant information, extremely concise 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?

Given the tool has 10 parameters, no output schema, and is a read operation, the description covers core purpose and sibling comparison but lacks details on return format, pagination, or limits. It is 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?

Schema description coverage is 70%, and the description adds no additional meaning beyond the schema. It neither explains nor contextualizes the parameters beyond their names and basic 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 explicitly states it pulls performance metrics for one ad, and distinguishes from get_campaign_insights by specifying individual-ad level comparison. This is specific and clear.

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 to use this for comparing creative performance at the individual-ad level, implying when to use. It contrasts with campaign-level insights, but does not elaborate on when not to use or all 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?

With no annotations, the description carries full burden. It mentions return of default fields plus custom fields, which is helpful but vague about what default fields are, response structure, or any side effects (none expected for a read). Not misleading but incomplete.

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 concise with two short sentences, no redundancy. However, it could benefit from slightly more detail without becoming verbose.

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

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

Given no output schema, the description omits return structure, pagination hints, or error handling. It covers the core functionality but leaves gaps for a tool with low schema coverage and no 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 0%, and the description only clarifies that the 'fields' parameter customizes output. It does not explain the expected format (e.g., comma-separated string) or the meaning of 'adset_id.' Minimal added value.

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 'Get a single ad set by ID,' specifying the verb (Get), resource (ad set), and unique identifier. It distinguishes from sibling list tools like list_adsets by emphasizing retrieval of a single entity.

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 retrieving a specific ad set by ID but lacks explicit guidance on when to use this versus alternatives (e.g., list_adsets for multiple) or any exclusions. It provides no when-not-to-use 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?

No annotations are provided, so the description must carry the burden. It only says 'Pull performance metrics' with no details on pagination, rate limits, authorization requirements, or any side effects. The scope 'ONE ad set' is clear but minimal behavioral context.

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

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

Two sentences, no filler. Front-loaded with verb 'Pull' and immediately specifies scope 'ONE ad set'. Every word earns its place.

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

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

Tool has 10 parameters, no output schema, no annotations. The description is too brief: it does not explain the return format, default time range, or handle pagination, which are essential for a data-fetching tool with such 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?

Input schema has 10 parameters with 70% coverage. The description does not add any parameter-specific meaning beyond the schema; it only references get_campaign_insights for fields/breakdowns. With high schema coverage, the baseline is adequate.

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 'Pull performance metrics for ONE ad set', distinguishing from sibling tools like get_ad_insights (ad-level) and get_campaign_insights (campaign-level). The reference to similar fields/breakdowns reinforces 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 says 'ONE ad set' indicating when to use, and references get_campaign_insights for comparable fields. However, it does not explicitly state when not to use (e.g., for multiple ads) or mention alternatives like get_ad_insights.

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?

Describes as a pre-flight check (implied non-destructive), details the shared limit behavior, and specifies output format. No annotation provided, but description compensates well. Lacks explicit read-only declaration.

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

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

Four sentences, front-loaded with 'PRE-FLIGHT CHECK'. Every sentence adds value: purpose, limit explanation, usage guidance, output description. 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 read tool with one parameter and no output schema, description explains output format ('one row per Page actor'), shared limit behavior, and usage context. Comprehensive given 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 covers the parameter fully with description. Tool description does not add new parameter details beyond the schema. Context about shared limits is behavioral, not parameter-specific.

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 it gets per-Page ads-running-or-in-review counts and limits. Distinct from sibling tools by specifying 'pre-flight check' and explicit return structure.

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 to call before bulk activation to avoid silent failures, and explains why (shared per-Page limit). Provides clear when-to-use 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?

No annotations provided, so description must cover behavior. It states returns default fields plus `fields` parameter. It does not mention idempotency, error handling, or authentication, which is acceptable for a simple read tool but leaves minor gaps.

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: first states purpose, second adds capability and usage guidance. No unnecessary words; 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?

Adequately covers purpose, parameters, and usage guidance. No output schema, but the return format is implied. Could mention error handling but not critical for a simple GET-like 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% with descriptions for both parameters. Description adds 'anything in `fields`', clarifying that arbitrary fields can be requested, which adds value beyond the schema's 'Override default field list'.

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

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

The description clearly states 'Get a single campaign by ID', which is a specific verb+resource. It distinguishes from siblings like list_campaigns by focusing on a single campaign and deep 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?

Explicitly says 'Use this for deep inspection of one campaign', implying it's for detailed view vs. list. Does not mention when not to use, 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?

With no annotations, the description must disclose behavioral traits. It covers default fields, date range, and breakdowns but omits important details like pagination behavior (via limit/after), authentication needs, rate limits, or error handling (e.g., for invalid campaign_id).

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 concise, with no redundant sentences. It front-loads the main purpose and efficiently lists defaults and options. Every sentence contributes meaning.

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

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

Given the tool's complexity (10 parameters, nested objects, no output schema), the description covers the main purpose, defaults, and key options. However, it lacks explanation of filtering, action_breakdowns, pagination (limit/after), and the structure of the response. The provided defaults partially compensate.

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%, and the description adds value by explaining defaults (e.g., 'Default range: last_7d') and usage patterns (e.g., 'Use breakdowns for cuts'). It clarifies parameter relationships 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?

Description clearly states 'Pull performance metrics for ONE campaign,' using a specific verb and resource. It explains default fields, default date range, and available options like breakdowns and time_increment, fully distinguishing the tool's purpose from siblings like get_ad_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?

The description implies using this tool for campaign-level insights but does not explicitly state when to use alternatives or when not to use it. No comparison with sibling tools like get_ad_insights or get_adset_insights 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?

With no annotations, the description implicitly indicates a non-destructive read operation via the verb 'get', but it does not disclose any additional behavioral traits such as error handling, performance, 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?

The description is a single, concise sentence with no extraneous words, but it sacrifices parameter and behavioral 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?

Given the tool's simplicity and lack of output schema, the description fails to explain the 'fields' parameter or the return format, making it incomplete 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 0% and the description adds no explanation for the 'fields' parameter or its possible values, leaving the agent without guidance on how to use the optional 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 clearly states the action (get), resource (ad creative), and scope (single by ID), which distinguishes it from sibling tools like list_creatives that return multiple items.

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 is provided on when to use this tool versus alternatives like list_creatives or create_ad_creative. The description only states what it does, not when 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?

No annotations are provided, so the description carries full burden. It discloses the auto-create behavior, the flow (GET access token, list, create if none), and the return value structure. It does not detail permissions or rate limits, but the information is sufficient for safe use.

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 concise with three sentences covering purpose, use case, and flow. Every sentence adds value 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?

Given the low complexity (1 parameter, no output schema), the description is nearly complete. It explains what, when, and how. It could mention that the tool may create a resource (i.e., side effect), but it already includes 'auto-create' and the 'created' flag.

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 baseline is 3. The description mentions 'page_id' in the flow context but does not add additional 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 clearly states the tool gets or auto-creates a Page-Backed Instagram Account for a Facebook Page. It specifies the verb ('Get (or auto-create)') and the resource ('PBIA'), distinguishing it from sibling tools which focus on ad campaigns and 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?

Explicit usage context is provided: 'Use this when the Page has no linked Instagram account but you want to run ads with IG placements.' It also outlines the flow. However, it does not explicitly state when not to use the tool or mention alternatives, though no direct sibling alternatives exist.

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 explains pagination via 'limit' and 'after', and lists return fields. It discloses that results are based on the current access token. While it doesn't explicitly state read-only or rate limits, the nature of a list operation is safely implied.

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-load the purpose and key information. Every phrase adds value: the action, returned fields, and usage guidance. 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?

Despite having no output schema, the description fully compensates by listing returned fields. With only two simple parameters and no nested objects, the description covers purpose, parameters, output, and usage guidance adequately.

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 descriptions for both 'limit' and 'after'. The description adds value beyond the schema by specifying Meta's cap (~500) and default (100) for limit, and the cursor source ('paging.cursors.after') for after, aiding correct parameter 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 verb 'List', the resource 'Meta Ad Accounts', and the scope 'accessible to the current access token'. It enumerates the returned fields and positions itself as the starting point for discovery, distinguishing it from siblings like 'get_ad_account' which fetches a single 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?

Explicitly says 'Use this first to discover what you can work with', guiding the agent to invoke it before other account-specific tools. However, it does not explicitly mention when not to use or directly compare to alternatives like 'get_ad_account'.

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

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

No annotations are provided, so the description must carry the burden. It lists return fields (id, name, adset_id, creative, status) but omits behavioral details such as pagination (limit, after parameters exist), rate limits, or that this is a read operation. The description adds some value but leaves significant gaps.

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-loaded with the purpose and key parameters. It is efficient but could add a note on output structure without hurting conciseness.

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 annotations, the description is incomplete. It covers only filtering by IDs and return fields but ignores pagination, status filtering, and field selection. A more complete description would mention these capabilities.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the three ID parameters (ad_account_id, adset_id, campaign_id) but does not mention limit, after, effective_status, or fields, leaving 4 of 7 parameters undescribed. The explanation for the IDs is good but insufficient overall.

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 'List ads' and specifies the three filter options (ad_account_id, adset_id, campaign_id), distinguishing it from sibling tools like list_adsets or list_campaigns. The verb-resource combination is explicit and the scope is well-defined.

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 the agent to pass one of three IDs but does not provide guidance on when to use this tool over siblings like search_ads_library or get_ad. There is no explicit when-not or alternative suggestion.

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 provided. Description only lists returned fields but omits important behavioral details like pagination (limit, after), rate limits, or 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?

Two sentences, front-loaded with purpose, no wasted words. Could be slightly more structured but highly 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?

Provides basic usage but lacking explanation of pagination, filtering, and optional fields; incomplete for a tool with 6 parameters and no output schema.

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

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

Adds meaning for ad_account_id and campaign_id, and lists return fields, but 4 out of 6 parameters (limit, after, effective_status, fields) are undocumented in both schema and description.

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

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

Clearly states 'List ad sets' and explains the two key filtering options (by account or campaign), distinguishing it from sibling tools like list_ads or 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 instructs to pass either ad_account_id or campaign_id, with clear return descriptions. However, lacks guidance on when not to use or 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?

Discloses pagination and return fields. No annotations provided, so description carries burden; but doesn't explicitly state it's read-only or mention side effects, though implicit.

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, front-loaded with purpose and return fields, then pagination detail. No verbose or redundant content.

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?

Compensates for lack of output schema by listing return fields. Mentions pagination. Could add ordering, error info, but sufficient for a 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%, but description adds value by listing return fields and confirming pagination cursor usage, which are not fully in 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?

Clearly states verb 'list' and resource 'campaigns in an ad account', and lists specific return fields, differentiating from siblings like get_campaign or batch 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?

Implies use for listing campaigns but lacks explicit guidance on when to use vs alternatives (e.g., get_campaign for single, search tools). No exclusions noted.

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?

Description lists returned fields, which is helpful, but does not disclose pagination behavior, rate limits, authentication requirements, or that it is a read operation. With no annotations, the description carries the full burden and only partially addresses it.

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 defines purpose, second lists return fields. No fluff, front-loaded 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 tool with 4 parameters and no output schema, the description only covers purpose and return fields. Missing explanations for pagination parameters and how to specify fields. Adequate but not thorough.

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 low (25%), and the description adds no meaning to parameters beyond the schema. It does not explain 'limit', 'after', or 'fields', leaving the agent to infer their 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 action (list), the resource (ad creatives), and the scope (in an account). It distinguishes from sibling tools like 'get_creative' (single creative) and 'create_ad_creative' (creates).

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 such as 'get_creative' or other list tools. No context about prerequisites or filtering options.

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 burden. It discloses output fields and token purpose, but lacks details on read-only nature, rate limits, or authentication requirements beyond 'current user/System User'.

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?

Single sentence front-loads purpose, but is slightly verbose; could be more concise.

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

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

Covers purpose and output fields adequately, but lacks parameter details and behavioral context given no output schema and no 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 has two parameters (limit, after) but the description provides no information about them despite 0% schema description coverage. Baseline should be higher, but fails to add value.

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 lists Facebook Pages managed by the current user, specifying the fields returned (id, name, access_token, category, tasks). This distinguishes it from sibling tools focused on ads and 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?

Implied usage for retrieving page access tokens needed for PBIA provisioning, but no explicit guidance on when to use this tool versus alternatives like list_ad_accounts or get_pbia.

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 key behaviors: WRITE operation, batch API usage, chunking, rate-limit handling, and specific return format. With no annotations, this is strong, though could mention partial failure 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 dense sentences, front-loaded with primary action and limits. Every word adds value, no filler.

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

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

With only one parameter and no output schema, the description covers purpose, behavior, limits, and response structure thoroughly, leaving no obvious 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?

Parameter 'campaign_ids' is fully described in schema (100% coverage) as 'Meta Campaign IDs to pause'. Description adds no extra meaning beyond what the schema provides, so baseline 3 applies.

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

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

Description clearly states the action (pause), resource (campaigns), and scope (bulk batch). The WRITE label and specific verb 'pause' distinguish it from siblings like 'activate_campaigns_batch' and individual update 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?

Provides explicit limits (50/request), automatic chunking, and 2s delay to avoid rate limits. While it doesn't directly compare to alternatives, the batch context and sibling names imply when to use this vs. individual updates.

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 important behavioral nuance: only ads in political/housing/employment/credit categories return full metadata, others return lighter data. No annotations exist, so description compensates well.

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 paragraphs with front-loaded purpose, no wasted words. 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?

Covers main functionality and limitations, but does not address pagination details or publisher_platforms filtering. Adequate for a search tool with no output schema.

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

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

Description adds context beyond schema by explaining search logic (OR between search_terms and search_page_ids), default country, and returned fields. Schema coverage is 67%, so description helps fill 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 the tool searches Meta's public Ad Library for competitive research, with specific verbs and resource. It distinguishes from sibling tools focused on account-level ads management.

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

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

Implies usage for competitive research but does not explicitly guide when to use this vs alternatives like get_ad, list_ads, or when not to use it. No exclusions or alternative tool mentions.

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. It explicitly states this is a write operation and mentions updating status (includes DELETED via enum), but does not disclose implications of creative swap or any authentication or rate limit requirements.

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 fluff. The critical action is front-loaded with 'WRITE' prefix, and the second sentence provides a concrete example. Every word earns its place.

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

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

While the description lists updatable fields, it omits important context: return value, prerequisites, behavior of swapping creative (e.g., is the old creative deleted?), and that only ad_id is required. For a write tool with 4 params and no output schema, this is insufficient.

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 25% (creative param has description). The description adds minimal meaning: it lists name, status, and creative as updatable fields but does not explain ad_id, nor does it elaborate beyond what the schema already shows for creative. It does not compensate for 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 starts with 'WRITE: Update an ad's name, status, or swap its creative.' This clearly states the verb (update) and resource (ad) with specific modifiable fields, effectively distinguishing it from sibling tools like delete_ad 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?

Provides a specific usage tip for replacing the creative, but lacks guidance on when to use this tool versus alternatives (e.g., update_adset) and does not exclude any scenarios.

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 must disclose behavioral traits. It signals 'WRITE:' and says 'Update any mutable field,' but does not mention side effects, permissions, idempotency, rate limits, validation behavior, or what happens if invalid values are passed. For a mutation tool, this is insufficient.

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 'WRITE:', no fluff. Every word contributes to clarity. Efficient and well-structured.

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 11 parameters, no output schema, and no annotations, the description is too brief. It lacks return value information, error scenarios, required permissions, and guidance on when to use this over other update tools (e.g., update_bids_batch). Incomplete for a complex write operation.

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

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

Schema description coverage is 0%, so the description must compensate. It lists several parameter names (status, bid_amount, daily_budget, targeting, name) which adds context beyond the schema's property names. However, it does not explain format, constraints (e.g., currency units), or the meaning of 'targeting' object, and uses vague 'etc.'.

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 updates an ad set, lists specific mutable fields (status, bid_amount, etc.), and distinguishes from create_adset and delete_adset by explicitly saying 'Update' and mentioning pass-only-changed-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 provides a key usage instruction: 'Pass only the fields you want to change.' This implies partial updates. It does not explicitly exclude other tools like update_campaign, but the context of ad set versus campaign is clear. No when-not-to-use or alternative tools 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?

Without annotations, the description carries the burden. It discloses auto-chunking of 50 and that it's a WRITE operation, but does not mention idempotency, failure handling, or permission requirements. 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?

Two sentences, immediately labeling the tool as 'WRITE (BULK)' and front-loading the verb and resource. 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?

No output schema. The description covers the input format and batch behavior but lacks information about return values, error handling, or success confirmation. Adequate for a simple bulk update tool but could be more 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 100%, so baseline is 3. The description adds value by specifying that bid values are in minor currency units (cents) and that chunks of 50 are automatically handled, which goes beyond the schema's parameter 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 clearly states 'Update bid_amount on many ad sets' with a bulk WRITE annotation. It distinguishes from sibling tools like update_adset (single) by explicitly stating 'BULK' and 'many ad sets'.

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

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

It clearly indicates when to use this tool (bulk updates to bid_amount) and implies it's for multiple adsets, distinguishing from single-update tools. However, it does not explicitly exclude single-adset use or mention update_adset as an alternative.

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

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

No annotations are provided, so the description carries the full burden. It only signals 'WRITE' and mentions mutable fields, but lacks disclosure of permissions, idempotency, error handling, rate limits, or other behavioral traits.

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, efficient sentence with no wasted words. It is front-loaded with 'WRITE:' to indicate the action, achieving high conciseness.

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 has 7 parameters, no annotations, and many sibling tools, the description is too brief. It does not explain return values, error conditions, or full usage context, 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?

The description lists the main mutable fields and clarifies that only desired fields need to be passed, adding meaning beyond the raw schema. However, it omits the 'special_ad_categories' parameter and provides no detail on enum values, which are already in the schema.

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

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

Description clearly states 'Update any mutable field on a campaign' with a list of specific fields, making the purpose obvious. However, it does not explicitly differentiate from sibling update tools like update_ad or update_adset, though the name and context provide sufficient distinction.

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

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

The description says 'Pass only the fields you want to change,' which is a basic guideline for partial updates. It does not provide when-to-use or when-not-to-use guidance, nor does it mention alternatives among 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?

Since no annotations are provided, the description covers key behavioral aspects: it is a write operation, returns a hash, scoped per account, and mentions backend caching. It does not cover file size limits or supported formats but is sufficient for a simple upload.

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 concise and front-loaded with 'WRITE:' and the main purpose, then return format and important note. Each sentence adds value, though minor redundancy could be trimmed.

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 the return format and provides cross-account advice. However, it lacks details on error cases, file size limits, or supported image types. Given no output schema, it covers the essentials but could be more 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 100%, so baseline is 3. The description adds context like 'Recommended' for url and explains how filename is used by Meta, but does not significantly expand beyond the 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 explicitly states 'Upload an image to an ad account' and details the return format. It distinguishes this tool from siblings like create_ad_creative and upload_video by explaining how the returned hash is used in creative creation.

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 on when to use this tool, especially the note about hash scoping and cross-account usage. However, it does not explicitly mention alternatives or 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?

No annotations are provided, so the description carries full burden. It discloses that it is a WRITE operation, returns `{id, title}`, and notes potential limitations for `file_path` (blocked on Windows/sandboxed hosts). This goes beyond basic function and adds useful context.

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

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

Two sentences, front-loaded with 'WRITE:', and no wasted words. Every sentence provides essential information 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?

No output schema exists, so description adequately explains the return value (`{id, title}`). It covers main usage patterns and a key limitation. Lacks error scenarios or detailed response fields, but is reasonably complete for a video 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 has 6 params with 67% coverage; description adds significant value by explaining why `file_url` is recommended over `file_path` and mentions the return structure. This clarifies the intent of key parameters beyond their schema definitions.

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 'WRITE: Upload a video to an ad account.' It specifies the action, resource, and context, and distinguishes itself from siblings by focusing on video file upload. The return value is also mentioned.

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 excellent guidance on when to use `file_url` vs `file_path` and explains why `file_path` may be unsuitable. However, it does not compare this tool to sibling tools like `create_ad_creative` or `upload_image`, leaving the when-to-use-this-tool-vs-alternatives partially incomplete.

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