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

With no annotations, the description carries the full burden and handles it well. It discloses the algorithm behavior (largest centered region matching aspect ratio, equivalent to 'Original' crop), the default set of crop keys with their aspect ratios and placements, and the inclusion of validation notes for invalid keys. This gives a complete picture of what happens during execution.

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 well-structured with Args and Returns sections. Though it contains a detailed list of crop keys, every element adds value. The opening sentence provides an immediate summary, and no content is superfluous or redundant with schema.

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

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

The tool has a small parameter set (3) and an output schema, so the description doesn't need to document return format in detail. It covers algorithm, defaults, parameter meanings, downstream usage, and error handling (validation notes), making it fully complete for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains image_width and image_height with pixel units and examples, and details crop_keys as an optional list with the six defaults, each enriched with aspect ratio and placement context. This is far beyond schema basics.

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 begins with a clear, specific verb+resource combination: 'Compute image_crops coordinates for a source image of the given dimensions.' It uniquely identifies the tool's function, distinguishing it from all sibling tools which focus on ad/account management. No ambiguity about what the tool does.

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

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

The description explains the output is 'ready to pass directly to create_ad_creative or bulk_create_ad_creatives', which clearly signals when to use this tool (before creating ad creatives). However, it doesn't explicitly state when not to use it or mention alternatives, though none are apparent among siblings. The context is clear but not exhaustive.

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

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

No annotations are provided, so the description carries the burden. It discloses the default PAUSED status, optional access_token with a cached fallback, and the dynamic-creative constraint with a specific error subcode. These are useful behavioral details, though it does not mention permissions or rate limits.

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

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

The description is well-structured: a front-loaded one-sentence summary, a parameter list with helpful details, and a critical note. Each line earns its place, and the tracking_specs example is valuable despite adding length.

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

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

For a Meta Ads API create operation with 8 parameters, the description covers all parameter semantics, the default behavior, and a known failure mode. It is sufficiently complete given an output schema exists. A minor gap is the lack of accepted status values and account/adset consistency constraints, but these are not essential for basic invocation.

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

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

The schema has no property descriptions (0% coverage), but the description compensates by explaining every parameter, including the act_ format for account_id, bid_amount in cents, a tracking_specs JSON example, and the optional cached access token. This adds substantial meaning beyond the bare schema titles.

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

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

The description opens with 'Create a new ad with an existing creative,' clearly stating the action (create), the resource (ad), and a key constraint (existing creative). This distinguishes it from sibling tools like create_ad_creative or 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?

The phrase 'with an existing creative' gives clear context that a pre-existing creative ID is required, implying that creative creation should happen first via a different tool. The dynamic creative note also provides a specific prerequisite. However, it does not explicitly name alternative tools or say when not to use this tool.

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

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

Despite no annotations, the description thoroughly discloses behavioral traits: error codes (error_subcode=1487390, error 1885800), video processing delays with retry logic, Meta silently collapsing multiple image_hashes in DOF mode, auto-handling of ad_formats for videos, and quirks like link_url requirement for asset customization. It goes beyond basic expectations.

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

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

The description is very long but well-structured with sections for creative modes, parameter details, and examples. It front-loads the purpose and modes, then uses bullet points and clear headings. Some redundancy exists (e.g., asset_customization_rules explained twice), but the structure supports the tool's complexity.

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

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

Given the high complexity (35 parameters, multiple modes, error handling) and minimal output schema, the description covers interactions, constraints, and behavioral notes comprehensively. However, the return value description is minimal ('JSON response with created creative details'), lacking details about typical response fields or status codes, which could be improved for full 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?

With 0% schema description coverage, the description fully compensates by detailing each of the 35 parameters: formats (e.g., account_id as 'act_XXXXXXXXX', instagram_actor_id as string), constraints (e.g., 'cannot be used with image_hash'), nested structures (e.g., messages as string or dict, asset_customization_rules format), and caveats (e.g., phone_number E.164 format and internal handling). The description adds significant meaning beyond the raw schema.

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

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

The description clearly states 'Create a new ad creative' and lists six distinct creative modes (existing post, simple image/video, multi-variant copy, placement customization, dynamic creative, FLEX/Advantage+). It distinguishes the tool from siblings like create_ad and compute_image_crops by focusing on 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 explicit guidance on when to use each creative mode and how to combine parameters, including mutual exclusivity rules (e.g., image_hash vs video_id vs object_story_id) and prerequisites (e.g., link_url required for asset customization even for lead ads). It also warns about common errors and suggests alternatives like using compute_image_crops before image_crops.

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

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

With no annotations provided, the description fully bears the burden. It discloses many behaviors: frequency_control_specs immutability after creation, promoted_object cannot be added via update, bid_adjustments requires allowlisted capability, error subcodes, and the need for DSA fields for EU targeting.

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 well-structured with each parameter on a new line, but it is very long and verbose. It could be more concise by summarizing some lists (e.g., valid optimization_goal values) or linking to external documentation. However, it is well-organized and front-loaded with the 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 the complexity of the tool (26 parameters, no annotations, no schema descriptions), the description is exceptionally complete. It covers budget inheritance, bid strategies, targeting defaults, regulatory fields, and even error subcodes. An agent can confidently invoke this tool with the information provided.

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%, but the description compensates with detailed explanations for each of the 26 parameters. It provides valid values, formats, examples, constraints, and relationships. For example, optimization_goal lists all valid values per destination_type, bid_strategy specifies which require bid_amount, and frequency_control_specs gives an example and immutability note.

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 'Create a new ad set in a Meta Ads account.' This provides a specific verb (create) and resource (ad set). It distinguishes itself from sibling tools like update_adset and create_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?

The description provides extensive when-to-use and when-not-to-use guidance, e.g., CBO budget inheritance ('Do NOT set this if the parent campaign already has a budget'), bid_amount requirements per bid strategy, and valid optimization_goal combinations per campaign objective. It also warns against using invalid values like 'LOWEST_COST' and 'ON_AD' for OUTCOME_ENGAGEMENT.

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

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

With no annotations provided, the description carries the full burden. It discloses the return format ('JSON string containing the ID... or an error message'), the meaning of budget_value_type ('ABSOLUTE' or 'MULTIPLIER'), and the optional access_token fallback. It does not mention rate limits or reversibility, but for a create operation, this is reasonably transparent.

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

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

The description is well-structured: a one-line purpose, a brief contextual sentence, a clearly formatted Args list, and a Returns line. Every sentence earns its place, with no fluff or redundancy. It is appropriately sized for the complexity.

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

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

Given the tool's complexity (6 parameters, no annotations, output schema present), the description is complete. It covers all parameters, explains the return value, and provides enough context for an agent to select and invoke the tool correctly. No gaps are apparent.

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 fully compensates by documenting every parameter: campaign_id, budget_value, budget_value_type, time_start, time_end, and access_token. It adds meaning beyond the schema, such as the interpretation of budget_value based on budget_value_type and the Unix timestamp requirement.

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 'Create a budget schedule for a Meta Ads campaign' with a specific verb and resource, and further explains its purpose: 'Allows scheduling budget increases based on anticipated high-demand periods.' This distinguishes it from sibling tools, none of which handle scheduling.

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 implicitly conveys when to use the tool via 'Allows scheduling budget increases based on anticipated high-demand periods,' which is clear context. It also provides practical guidance on Unix timestamps. It does not explicitly mention alternatives or exclusions, but no sibling offers similar functionality, so the guidance is 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 provided, the description carries the full burden. It explains that the tool returns a campaign id, warns about start_time limitation, legacy objectives, and bid strategy implications for child ad sets. It does not cover permissions or rate limits.

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

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

The description is well-structured with a clear overview, a note section, and an args list. It is front-loaded with purpose. However, it could be slightly more concise; some details like the full list of ODAX objectives are repeated.

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 high parameter count (15) and no annotations, the description covers many aspects: hierarchy context, warnings, return value. It does not address error handling, pagination, or rate limits, but these are not critical for a creation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all parameters, including account_id format, objective enums with usage warnings, budget units, bid strategy enums, conditional usage of daily_budget/lifetime_budget, and an example for ab_test_control_setups.

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 that it creates a Facebook or Instagram ad campaign, specifies it as the first step in the campaign hierarchy, and lists alternative names. It distinguishes from sibling tools by defining its role as the entry point.

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 context on when to use (first step of hierarchy) and includes a note about start_time and objective mapping. However, it lacks explicit guidance on when NOT to use this tool versus alternatives like update_campaign or create_adset.

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 present, the description carries the full burden of behavioral disclosure. It provides valuable context: access_token is optional and falls back to a cached token, account_id is required for comprehensive estimation, interest_list and interest_fbid_list are deprecated backward-compatibility parameters, and optimization_goal defaults to 'REACH' with stated options. It also describes the return value as a JSON string including estimated_audience_size and reach_estimate. This goes well beyond a terse description, though it does not cover error cases 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 well-structured with a leading summary sentence, followed by Args and Returns sections. The example targeting object is highly informative without being bloated. Every sentence contributes value, including the explicit deprecation notices. It is appropriately sized for a complex tool and does not waste 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?

The tool has 6 parameters, zero annotations, and an output schema. The description covers all core aspects: what it does, when to use it, each parameter's purpose and format, deprecated options, and the shape of the return value. The provided example fills in gaps that the abstract schema cannot. Given the tool's complexity and the absence of annotations, the description is notably complete.

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

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

Schema description coverage is 0%, so the description must compensate for the input schema's bare property definitions. It does so thoroughly: every parameter is explained in the Args section, with details like 'format: act_XXXXXXXXX' for account_id, a concrete JSON example for targeting, a list of options for optimization_goal, and explicit deprecation notes for legacy params. This adds meaning far beyond the schema's type and default declarations.

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

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

The description opens with a specific, action-oriented statement: 'Estimate audience size for targeting specifications using Meta's delivery_estimate API.' This clearly identifies the resource (audience size estimation) and the target API, and it distinguishes the tool from siblings like search_interests or search_geo_locations by focusing on estimation rather than discovery. The mention of 'comprehensive audience estimation for complex targeting combinations' further clarifies its scope.

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

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

The description provides clear context on when to use the tool: for comprehensive estimation of complex targeting combinations (demographics, geography, interests, behaviors) and for backwards-compatible simple interest validation. It stops short of explicitly naming alternative tools for different use cases or saying 'use X instead,' but the guidance is sufficient to place the tool correctly among its siblings.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool does not make direct API calls, only returns cached records, and returns 'Record not found' if the record wasn't cached. It also notes the session scoping, providing essential 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?

The description is well-structured with clear sections: main purpose, important limitations, alternatives, args, and returns. Every sentence provides necessary information, and the key limitation is front-loaded. Length is justified by the complexity and requirement to prevent misuse.

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 an output schema, the description explains the return behavior ('JSON response with record data, or 'Record not found''), which is essential. It covers the single parameter, use cases, limitations, and alternatives, making it complete for this relatively simple 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 input schema only lists an 'id' string with no description. The description adds critical meaning: the required format ('type:id', e.g., 'account:act_123456') and that the record must have been returned by a previous 'search' call. This is substantial value 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 states a specific verb ('Fetch') and resource ('a record previously returned by the 'search' tool'), clearly distinguishing this from sibling tools. It explicitly notes this is not for direct ID lookups, which further sharpens its 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 explicitly states when to use the tool (after a prior 'search' call) and when NOT to use it ('Do NOT use this tool to look up campaigns, adsets, or ads by ID directly'), and then lists specific alternative tools for those cases. This is model 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?

Without annotations, the description adds value by explaining optional token caching, default fields, and a critical nuance for prepaid account balance calculation. However, it does not disclose read-only status, required permissions, or rate limits, leaving some behavioral aspects opaque.

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

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

The description starts with a clear one-line purpose, then lists parameters in a structured format. The prepaid account explanation is valuable but adds length; overall it is reasonably concise without unnecessary redundancy.

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

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

The description covers purpose, parameter semantics, and a key edge case (prepaid balance). With an output schema present, return value documentation is not needed. It does not discuss prerequisites or error handling, but is generally adequate for a read 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?

With 0% schema coverage, the description fully explains all three parameters: account_id format (act_XXXXXXXXX), access_token caching behavior, and fields parameter with default list and prepaid account note. This exceeds the baseline and 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 'Get detailed information about a specific ad account,' specifying both the action (get) and resource (ad account). This clearly distinguishes it from sibling tools like get_ad_accounts (which lists accounts) and get_insights (analytics).

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 no guidance on when to use this tool versus alternatives, such as when to use get_ad_accounts for listing or get_campaign_details for campaign-specific info. It lacks explicit when-to-use or when-not-to-use instructions.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It notes the optional access_token and cached-token fallback, giving insight into authentication behavior. It also states the return format (JSON). It could mention what happens when no token is available, but for a simple GET operation, this is adequately transparent.

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

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

The description is well-structured with Args and Returns sections, front-loading the purpose. Every sentence provides useful information without 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?

For a simple tool with an output schema, the description covers the essential aspects: purpose, parameters, and return value. It is complete enough for an agent to select and invoke the tool correctly, especially given the explicit parameter format and caching note.

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 fully compensate. It explains account_id format (act_XXXXXXXXX) and the optional access_token with caching behavior, adding meaningful context beyond the bare schema. Both parameters are effectively documented.

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 pages associated with a Meta Ads account, using a specific verb and resource. It naturally distinguishes itself from sibling tools like search_pages_by_name by focusing on account association rather than name-based search.

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 for when to use the tool: when you need pages linked to a specific Meta Ads account. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough to infer the appropriate use case.

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

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

With no annotations provided, the description carries full burden of behavioral disclosure. It only mentions that amount_spent and balance are in currency units, but fails to disclose pagination behavior, error cases, token permission requirements, or data freshness. This is insufficient for a tool that likely returns a list of sensitive financial data.

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

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

The description is extremely concise: first sentence states purpose, then a note about behavior, then the parameter list. No filler words. The parameter list uses a clear 'name: explanation' format. Front-loaded with key 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 3 optional parameters and an output schema, the description covers the basic semantics and a behavioral note (currency units). However, it omits important context like whether results are paginated, how to handle errors, or what happens when no ad accounts are available. The output schema exists but the description should still provide enough context for an agent to decide whether to call the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains all three parameters: access_token (optional, cached), user_id (default 'me'), limit (maximum accounts, default 200). This adds value beyond the schema's type annotations, but could be improved by clarifying the format of access_token or user_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 'Get ad accounts accessible by a user', which is a specific verb and resource. It distinguishes itself from sibling tools like get_ads and get_campaigns by focusing on ad accounts and user accessibility. The purpose is unambiguous.

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

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

The description implies usage when listing ad accounts for a user, but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or when-not scenarios. The presence of similar sibling tools (e.g., get_account_info) suggests differentiation is needed, but none is given.

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

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

With no annotations, the description carries the full burden. It discloses the token caching behavior and the required ad_id, which is helpful. But it doesn't mention whether the operation is read-only, possible errors, or any rate limits—basic behavioral context for a read 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 brief, front-loaded with the core purpose, and uses a clean Args list. 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?

For a tool with only 2 parameters and an output schema, the description covers the workflow, prerequisites, and parameter semantics. Its brevity is appropriate given the low complexity and available output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It does this thoroughly by explaining that ad_id is the Meta Ads ad ID and that access_token is optional with a cached-token fallback, adding meaning the schema lacks.

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

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

The description uses a specific verb 'Get' and clearly identifies the resource: creative details for a specific ad. It distinguishes itself from siblings by emphasizing the ad_id requirement (not account_id) and directs users to get_ads first, making its scope unambiguous.

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

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

Provides clear usage context by stating the prerequisite (use get_ads first) and clarifies the required ID type. However, it doesn't explicitly name alternative tools or when-not-to-use, so it stops short of a 5.

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

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

Without annotations, the description carries the full burden. It adds useful behavioral context about the access_token parameter, noting that a cached token is used if not provided. However, it does not explicitly mention read-only safety, error handling, or what 'detailed information' includes.

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 plus a clear argument list. It is front-loaded with the purpose statement and concise, with no 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?

For a simple single-resource read operation with an output schema, the description is fairly complete. It covers what the tool does, both parameters, and the token fallback behavior. The only notable gap is the lack of usage guidance, which is already penalized under usage_guidelines.

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 provides no descriptions for parameters (0% coverage), so the description fully compensates. It explains ad_id as 'Meta Ads ad ID' and access_token as 'Meta API access token (optional - will use cached token if not provided),' adding semantic meaning beyond the schema's bare type and default.

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: 'Get detailed information about a specific ad.' This distinguishes it from plural listing tools like get_ads and other detail tools like get_adset_details or get_creative_details by specifying 'ad' and '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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of alternatives or exclusions, which is problematic given the many sibling 'get_*_details' tools that could be confused.

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?

While no annotations exist, the description discloses the read-only nature (get/download) and that it returns the currently serving image. Could mention if any side effects or rate limits, but adequate overall.

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?

Concise: main action in first sentence, alternate usage in second, then Args/Returns. 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 retrieval tool, the description covers purpose, input, output, and alternatives. No output schema needed given the simple return type.

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

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

Schema coverage is 0%, but the description explains both parameters: ad_id as Meta Ads ad ID, access_token as optional with caching behavior, adding significant value beyond the bare 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 the tool gets, downloads, and visualizes the image attached to an existing Meta ad, distinguishing it from get_image_by_hash which is for image hash lookups.

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

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

Explicitly states when to use (have ad ID) and when to avoid (only have image hash), and provides the alternative get_image_by_hash.

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 responsibility. It explains optional token caching and default limit but omits behaviors like pagination, error handling, or whether only active ads are returned.

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 well-structured with bullet points and front-loaded purpose. Minor verbosity (e.g., 'optional - will use cached token if not provided') could be trimmed, but overall 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?

Given 5 parameters, required account_id, and presence of output schema, the description covers all necessary aspects. It lacks mention of pagination or result scope (e.g., active vs. all ads), but is largely complete.

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

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

With 0% schema description coverage, the description fully compensates by detailing each parameter: account_id format, access_token optionality, limit default, and filter fields. Adds significant meaning 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?

The description clearly states 'Get ads for a Meta Ads account with optional filtering,' specifying the verb, resource, and context. It distinguishes from sibling tools like get_adsets or get_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 lists optional filters but does not explicitly guide when to use this tool versus alternatives like search or get_campaigns. No exclusions or when-not-to-use 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?

With no annotations provided, the description must communicate behavioral traits. It discloses that access_token is optional and will use a cached token if not provided, which is useful. However, it does not mention potential errors, permission requirements, or the read-only nature explicitly (though 'get' implies it). This provides some transparency but leaves 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 concise: a one-sentence purpose, a clear Args list, and an example. It is well-organized and front-loaded with the purpose. No unnecessary wording.

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 the presence of an output schema, the description is largely complete. It explains the parameters and how to call the function. However, it omits any mention of error conditions or how the response is structured, but the output schema covers that. The description suffices for selection and basic invocation.

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

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

The schema has zero descriptions for its properties, so the description must compensate. It explains adset_id as 'Meta Ads ad set ID' and access_token as an optional token with caching behavior. It also provides a concrete invocation example. This adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool's function: 'Get detailed information about a specific ad set.' The verb 'get' and resource 'adset details' distinguish it from sibling tools like get_adsets (which lists adsets) and get_ad_details (which handles ads, not adsets).

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 does not provide explicit guidance on when to use this tool versus alternative tools like get_adsets. It implies you need a specific adset_id, but offers no contextual information about when to choose this over others. The example focuses on invocation syntax rather than selection criteria.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as pagination behavior, ordering, or side effects. It only describes the basic operation (read) without clarifying limits or error handling, which is insufficient given the absence of annotations.

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

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

The description is concise with a single sentence summary followed by a structured Args block. It is front-loaded and every sentence provides useful information, though the Args block slightly repeats schema info without being 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 the tool simplicity and existence of an output schema, the description covers basic functionality and parameters. However, it lacks context on edge cases (no results), error messages, or rate limits, leaving it minimally complete for a production setting.

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 compensates by explaining account_id format ('act_XXXXXXXXX'), access_token optionality with cached token note, limit default, and campaign_id optionality. This adds value beyond the schema, though it could detail limit behavior or filter semantics more.

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 ad sets for a Meta Ads account with optional filtering by campaign.' It specifies the verb 'Get', the resource 'ad sets', the context 'Meta Ads account', and an additional feature. This distinguishes it from siblings like get_ads (different resource) and get_adset_details (specific ad set).

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

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

The description mentions optional filtering by campaign but does not explicitly state when to use this tool vs alternatives like get_adset_details or get_ads. There is no guidance on prerequisites or use cases, leaving the agent to infer context from the tool name.

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

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

With no annotations, the description carries full disclosure responsibility. It thoroughly explains behavior: polling for video status, error prevention by waiting for 'ready' status, and the advantage of providing account_id to avoid API errors. The video_status field values ('processing', 'ready') are clearly documented.

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 well-structured with two paragraphs and a bulleted list. It is concise yet comprehensive, with each sentence adding value. The front-loaded purpose statement is immediately 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?

Given the tool has 4 optional parameters, no enums, and an output schema, the description covers all necessary aspects: purpose, parameters, usage context (polling, error avoidance), and behavioral details. An agent can correctly select and invoke this tool without additional information.

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%, but the description compensates excellently. It explains each parameter's purpose: ad_id auto-extracts video, video_id for direct use, account_id enables advideos edge, and access_token is optional. This provides critical context beyond the bare 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 the tool's purpose: 'Get video details and source URL for a Meta ad video creative.' It lists specific outputs (source URL, thumbnail, status, metadata) and distinguishes from sibling tools like get_ad_image by focusing on video-specific data and polling usage.

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 context for when to use the tool, particularly for polling after bulk_upload_ad_videos. It explains the relationship with create_ad_creative and the importance of waiting for 'ready' status. However, it does not explicitly list alternatives or when not to use this tool versus others.

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 the tool requests a fixed set of fields and notes the availability of other Meta API fields, setting expectations about data completeness. It also explains access_token fallback behavior. However, it does not mention error handling, pagination, or the exact return envelope, leaving some behavioral 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 well-structured with a clear purpose sentence, a useful note about field limitations, and an Args list. The note about modifying the 'fields' parameter in code is slightly tangential for an AI agent but still relevant. It is not overly verbose and each section 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 simple read-only nature of the tool and the presence of an output schema, the description is reasonably complete. It explains the limited field set, covers both parameters, and notes token caching. However, it lacks explicit guidance on how this tool fits with sibling tools, such as when to prefer get_campaign_details over get_campaigns, which would elevate 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?

Schema coverage is 0%, so the description must compensate. It defines campaign_id as 'Meta Ads campaign ID' and access_token as 'Meta API access token (optional - will use cached token if not provided),' adding real semantic meaning not present in the schema. This explains both the purpose and optionality clearly, though it could add constraints like format validation.

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 with a specific verb and resource: 'Get detailed information about a specific campaign.' The word 'specific' explicitly distinguishes it from sibling get_campaigns, which would list campaigns. This makes the tool's scope unambiguous.

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

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

The description implies when to use the tool (when you need details for a specific campaign) and emphasizes 'specific,' but it does not explicitly name alternatives or state when not to use it. No mention of sibling tools like get_campaigns or update_campaign leaves usage guidance implicit rather than explicit.

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

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

With no annotations, the description carries full burden. It describes the default field subset, optional token handling, pagination via 'after', and filtering behavior. It does not mention rate limits or destructive actions, but adequately explains the read operation.

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

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

The description is well-structured with sections and bullet points, but slightly verbose. Every sentence adds value; however, some details like valid objectives could be condensed. Still, it is clear 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 6 parameters, no schema descriptions, no annotations, and presence of an output schema, the description is remarkably complete. It covers all parameters, default behavior, pagination, and filtering nuances, making it fully self-contained 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?

Despite 0% schema description coverage, the description adds thorough meaning: explains account_id format, access_token optionality, limit default, status_filter mapping and array handling, objective_filter valid values and examples, and after for pagination. This fully compensates for the schema gap.

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

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

The description clearly states it retrieves campaigns for a Meta Ads account with optional filtering, using specific verbs and resources. It distinguishes from sibling tools like get_campaign_details, get_ads, 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 clear context on when to use, explains the default field behavior and the limitation of not exposing all fields. It indirectly suggests when not to use (if all fields needed) but does not explicitly enumerate 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Get detailed information' without describing side effects, required permissions, rate limits, pagination, or what 'detailed information' includes. The read-only nature is not explicitly stated.

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 a clear first sentence stating the purpose and a structured Args list. Every sentence contributes value with no redundancy or filler.

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

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

For a simple get-by-ID tool, the description covers the basic purpose and parameters, and an output schema exists so return values need not be explained. However, it lacks usage guidance and behavioral transparency, making it only minimally complete for an agent to confidently select and invoke the tool.

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

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

The schema coverage is 0%, and the description's Args section provides basic meaning for both parameters (Meta Ads creative ID, optional access token). This adds some context beyond the schema types, but it lacks format details or how the access token is used, so it does not fully compensate for the low schema 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?

The description uses the specific verb 'Get' and the resource 'ad creative by its ID', which clearly distinguishes this from sibling tools like get_ad_creatives (likely listing) and update_ad_creative (modification). The purpose is unambiguous.

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

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

The description implies usage for a single creative by ID but provides no explicit comparison to alternatives such as get_ad_creatives or guidance on when not to use this tool. There is no mention of exclusions or alternative tools, so the context is only implied.

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

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

No annotations provided, so description carries the full burden. It explains what the tool does (retrieve and visualize image), that access_token is optional, and input formats. However, it does not specify return type (binary, URL, base64) or clarify if 'download' implies side effects.

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?

Well-structured with a clear one-line summary, usage context, and parameter list. The parameter descriptions are concise but informative. A minor redundancy is the note about access_token being optional repeated in the list.

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

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

With no output schema, the description should specify the return format (binary, base64, URL). It only says 'ready for direct visual analysis', which is vague. It covers parameters and usage context adequately but lacks output details.

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

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

Schema coverage is 0%, so description adds value by explaining that account_id accepts 'act_XXXXXXXXX or bare numeric', image_hash is the hash, and access_token is optional with fallback to cached token. This clarifies usage beyond the bare 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 the action ('Get, download, and visualize') and the resource ('a Meta ad image by its hash'). It distinguishes from sibling tool get_ad_image by specifying when to use each.

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

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

Explicitly tells when to use this tool ('when you have an image_hash without an ad') and when to use an alternative ('prefer get_ad_image(ad_id)'). Provides concrete examples of image hash sources.

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 fully discloses behavioral traits: fixed field return, auto-handling of platform_position and media_type breakdowns, restrictions on unsupported fields, pagination details, and the impact of the compact parameter. This provides complete transparency for an AI agent.

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

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

The description is long but well-organized with clear sections and bullet points. While every sentence adds value, the length could be slightly reduced for quicker scanning. However, given the tool's complexity, the structure earns a high score.

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

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

Given the tool's high parameter count (14), lack of schema descriptions, and complex behaviors, the description covers all necessary context: parameter details, constraints, auto-behaviors, and even alternative tool recommendations. The output schema exists, so return value explanation is unnecessary.

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

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

The schema has 0% coverage, but the description exhaustively explains each parameter: object_id aliases, time_range presets with examples, breakdown valid values with notes and auto-applied behaviors, level, limit, after, attribution windows, action_breakdowns, and compact. This adds immense meaning beyond the bare 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 the tool retrieves performance insights for campaigns, ad sets, ads, or accounts. It distinguishes itself from sibling tools like get_ad_details by focusing on aggregated insights rather than individual entity details.

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 on when to use this tool versus alternatives, such as recommending bulk_get_insights for large result sets or when only specific metrics are needed. It also clarifies limitations like fixed field sets and potential response size issues.

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 behavioral traits like optional access_token caching, default limit, and output format. However, it does not mention rate limits or side effects, but for a read-only tool it is fairly transparent.

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

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

The description is concise, well-structured with a brief purpose followed by clear bullet-like parameter explanations. Every sentence adds value 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?

The description covers parameters, return, and optional behavior. However, it lacks context about the source of suggestions (e.g., Meta's ad targeting taxonomy) and potential input limitations. Overall fairly complete for a simple 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 0%, so the description fully compensates by providing clear semantics for each parameter: interest_list examples, access_token optionality and caching, limit default. The return value is also described.

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 with a specific verb ('Get') and resource ('interest suggestions'), and differentiates from siblings like search_interests by specifying it is 'based on existing interests.'

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 when the agent has a list of interests and wants related suggestions, but does not provide explicit when-not-to-use instructions or mention alternatives among siblings like search_interests.

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 transparency burden. It discloses caching behavior (optional access_token, will use cached token) and the return type, but does not explicitly state whether generating the link has side effects (e.g., creates a session, expires) or requires specific permissions. This is a moderate gap.

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

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

The description is concise and well-structured: a one-sentence purpose, a note, and clear Args/Returns sections. Every sentence adds value and no space is wasted.

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

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

The tool is simple (one optional param), and the description provides usage context, parameter details, and return value. It could mention prerequisites like having a custom Facebook app, but the 'NOTE' section partially covers this. Overall, it is complete for its 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 schema only provides the parameter name and type, while the description adds meaningful semantics: 'Meta API access token (optional - will use cached token if not provided).' This explains the optionality and fallback behavior, compensating for the schema's minimal 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?

The description clearly states the tool's function with a specific verb and resource: 'Get a clickable login link for Meta Ads authentication.' This unambiguously distinguishes it from the sibling ad-management 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?

Explicit usage guidance is provided: the method should only be used when using your own Facebook app, and the recommended Pipeboard authentication path is described with a concrete alternative (setting PIPEBOARD_API_TOKEN). This is a model of when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns matching record IDs, searches across multiple entity types, and clarifies that access_token is optional and uses a cached token if not provided. This adds meaningful context beyond the schema, though it does not cover potential limitations like result limits or pagination.

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

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

The description is well-structured with a concise intro, Args, Returns, and Example Usage sections. The example usage includes five queries, which is slightly repetitive but useful for illustrating query variety. Overall, it is efficient and not 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 the tool's simplicity (2 params, no nested objects) and the presence of an output schema, the description is adequately complete. It covers purpose, parameter semantics, return type, and examples. However, it does not mention pagination, result limits, or error behavior, which are minor 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 schema has no descriptions (0% coverage), so the description compensates by explaining 'query' as 'Search query string to find relevant Meta Ads records' and 'access_token' as optional with cached-token behavior. This adds clear semantic value beyond the plain schema, though it could provide more detail on query syntax or constraints.

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: 'Search through Meta Ads data and return matching record IDs.' It specifies the resource (Meta Ads data) and scope (across ad accounts, campaigns, ads, pages, and businesses), effectively distinguishing it from sibling tools like search_pages_by_name or search_ads_archive.

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 for use through examples like 'search(query="active campaigns")' and 'search(query="facebook pages")', implying it is a broad cross-entity search. However, it does not explicitly state when not to use it or mention alternatives, so it earns a 4 rather than a 5.

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

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

With no annotations, the description must carry behavioral disclosure. It mentions that access_token can be omitted to use a cached token, but it lacks details on pagination, rate limits, or the read-only nature of the operation. The description covers only a small portion of potential 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?

The description is well-structured: a one-sentence purpose, an Args breakdown, and a curl example. The example is somewhat verbose and partially redundant with the Args list, but the overall organization is clear 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?

The description provides a complete invocation recipe including all parameters, a usage example, and defaults. Since an output schema exists, not detailing return values is acceptable. It lacks some context like pagination behavior, but for a moderately simple search tool it is sufficiently 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 0%, but the Args list explains every parameter with examples and formats. For instance, it specifies ad_reached_countries as a list of country codes, ad_type with concrete enum-like examples, and fields as a comma-separated string. This fully compensates for the schema's lack of 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 'Search the Facebook Ads Library archive,' with a specific verb and resource. This distinguishes it from sibling tools like search_pages_by_name, making it unambiguous.

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

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

The description provides an example and parameter list but does not explicitly explain when to use this tool versus alternatives. There is no mention of exclusions or any guidance on choosing among sibling search tools.

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

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

No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as authentication requirements (beyond an optional token), rate limits, or side effects. The description is minimal and does not add significant context beyond the obvious.

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 well-structured: a one-line purpose, then each parameter with description, and a return value description. Every sentence is informative 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?

Given the absence of annotations and low schema coverage, the description covers input parameters and return format adequately but lacks context on prerequisites, error scenarios, or how this tool fits among siblings. It is minimally 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 0%, so the description must compensate. It explains that access_token is optional and defaults to null, with caching behavior noted, and limit has a default of 50 and a description. This adds meaningful value 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 the tool retrieves 'all available behavior targeting options', with a specific verb ('Get') and resource ('behavior targeting options'). It distinguishes from sibling search tools like search_demographics and search_interests by specifying 'behavior'.

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

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

The description lacks explicit guidance on when to use this tool versus alternatives. No 'when not to use' or comparison to similar sibling tools is provided; the name alone differentiates it.

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

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

With no annotations, the description carries the full burden. It discloses that access_token is optional and that a cached token may be used, which is useful. However, it does not explicitly state that the operation is read-only, nor does it mention pagination behavior, rate limits, or error conditions. The 'Get' verb implies reading, but more explicit behavioral context would be beneficial.

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 well-organized with clear Args and Returns sections. Every sentence contributes essential information, with no redundancy or fluff. It is succinct yet comprehensive, fitting the ideal length for a tool with three 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?

The description covers all parameters and the return value structure, which is sufficient for a search-like tool with no nested objects. However, it lacks details on potential pagination (beyond the limit parameter) or rate limiting, which might be relevant for large result sets. An output schema exists, so return type is further clarified, but the absence of explicit edge-case behavior keeps it from being a 5.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining every parameter: access_token's optional nature and fallback behavior, demographic_class with its enumerated options and default, and limit with its default. This exceeds what the schema alone provides and gives clear semantic meaning.

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 demographic targeting options with the verb 'Get' and a specific resource. It is unambiguous, but it does not explicitly differentiate itself from sibling tools like search_interests or search_behaviors; the distinctiveness comes from the resource name rather than the description itself.

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 no guidance on when to use this tool versus alternatives such as search_interests, search_behaviors, or search_geo_locations. It only describes the function itself, leaving the agent to infer usage context from the name.

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

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

With no annotations provided, the description carries the full burden. It discloses access_token caching behavior, returns a JSON string with location data, and implies a read-only search operation. While it doesn't mention rate limits or pagination, it provides solid transparency for a search 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 uses a clean, structured Args/Returns format. Every line earns its place, listing parameters and return value without any filler or redundancy.

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

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

The description covers the tool's purpose, all parameters, token handling, and return structure. Given the tool's simple search nature and no annotations, this is complete enough for an agent to select and invoke it correctly.

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

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

The input schema has 0% description coverage, but the description fully compensates by explaining each parameter: query, access_token, location_types (including available options), and limit with default. This adds complete semantic meaning beyond the bare schema types.

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 'Search for geographic targeting locations' with a specific verb and resource. This distinguishes it from sibling search tools like search_interests and search_behaviors, making the tool's scope unambiguous.

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

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

The description clearly indicates this is for geographical targeting locations, which gives clear context for when to use it. However, it does not explicitly mention alternatives or exclusion criteria, only implying the use case through the resource type.

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 describes the function as a search returning JSON with specific fields. However, it does not disclose any required permissions or potential side effects beyond being a read operation.

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

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

The description is concise and well-structured with a one-line summary, clear Args block, and Returns section. Every sentence provides useful 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?

Given the tool has 3 parameters (1 required) and an output schema, the description covers all essential aspects: parameter explanations, default values, and return format summary. It is complete and self-contained.

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 adds significant value: explains query with examples ('baseball', 'cooking'), mentions access_token is optional and uses cached token, and specifies limit default (25) and purpose.

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 'Search for interest targeting options by keyword,' specifying a unique verb and resource. Sibling tools like search_behaviors and search_demographics have distinct names, so this tool stands out.

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

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

The description explains when to use the tool (searching for interests by keyword) but does not explicitly mention when not to use it or suggest alternatives. The context is clear, but lacks exclusions.

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

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

No annotations are provided, so the description must carry the burden. It discloses some behaviors: access_token can be omitted and 'will use cached token if not provided', and search_term is optional with a defined fallback. However, it does not mention authentication requirements, rate limits, permissions, or response structure beyond 'JSON response with matching pages'.

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 uses a structured Arg/Returns format that is easy to scan. It is concise with no superfluous content, though the docstring formatting adds some lines. Overall it earns its place.

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

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

For a simple search tool with 3 parameters and an output schema, this description is sufficiently informative. It covers all parameters and the return type, plus the account_id format. Minor gaps exist (no pagination, no error behavior), but these are not critical for a straightforward search 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 coverage is 0%, so the description compensates. It explains all three parameters: account_id with format 'act_XXXXXXXXX', access_token with cached-token fallback, and search_term with behavior when omitted. However, it lacks details on search_term matching semantics (e.g., exact vs substring, case sensitivity).

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: 'Search for pages by name within an account.' The verb 'search' and the resource 'pages' with the qualifier 'by name' make the purpose specific and distinguish it from siblings like 'get_account_pages' or 'search_ads_archive'.

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 by explaining optional parameters (e.g., 'returns all pages if not provided'), but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No direct references to sibling tools.

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

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

No annotations are provided, so the description must disclose mutation behavior. It only hints at side effects via creative_id ('changes the ad's image/content') and notes access_token caching, but omits permission requirements, reversibility, partial vs full update semantics, and potential failures. This is insufficient for a mutation tool.

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

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

A one-sentence purpose followed by a compact argument list. Information is front-loaded and concise, though a few parameter descriptions (e.g., 'New ad name') are self-evident and 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?

Given the tool's complexity (7 params) and lack of annotations, the parameter meanings are well covered and an output schema exists to describe return values. However, usage guidance and mutation caveats are absent, making it only partially complete for an agent to safely invoke.

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 compensates fully by explaining all 7 parameters, including units (cents for USD), optionality, and behavioral effects (creative changes content). This adds significant meaning beyond the raw schema.

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

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

Clear action verb 'Update' with explicit resource 'an ad' and scope 'new settings'. It distinguishes from sibling update_ad_creative by noting creative_id changes the ad's image/content, and from other update tools by focusing on ad-level 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 by naming the resource and update action, and the parameter list provides context for what can be changed. However, it does not explicitly state when to prefer this over sibling tools like update_ad_creative, update_campaign, or update_adset.

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

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

With no annotations provided, the description carries the full burden. It discloses the critical API limitation on content fields and notes that many parameters may be rejected. However, it omits potential behaviors like rate limits or authentication requirements beyond the optional access token, which could be relevant for agents.

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 well-structured with a clear title, an important note, and an organized Args list. However, it is lengthy and could be more concise by grouping some content fields under a single note to reduce repetition without losing clarity.

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 (15 parameters, 1 required, no enums), the description covers the key limitations, parameter behaviors, and provides a Returns section. It fully compensates for the lack of schema descriptions and gives enough context for an agent to use the tool correctly.

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

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

Since the input schema has no descriptions (0% coverage), the description's Args section provides essential meaning for all 15 parameters. It distinguishes between single and plural variants, notes which ones are likely to be rejected, and explains the usage of ad_formats and creative_features_spec. This goes well beyond the schema's scope.

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 existing ad creative's name or optimization settings, specifying the verb 'update' and the resource 'ad creative'. It distinguishes itself by noting the limitation on content fields, which differentiates it from other tools like create_ad_creative or 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?

The description explicitly states that the Meta API does not allow updating content fields, so this tool should only be used for name and optimization settings. It provides an alternative workflow: create a new creative and update the ad reference via update_ad. This gives clear when-to-use and 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, the description carries full burden. It discloses many behavioral traits: warnings about immutable fields, deprecated parameters, field requirements, and optional token usage. It notes that certain changes require creating a new ad set. However, it does not mention the return value or side effects like overwriting existing settings.

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 structured with line breaks separating parameters, and the purpose is front-loaded. Despite its length (22 parameters), each entry is concise and informative. Some repetition could be avoided (e.g., similar warnings for different fields), but overall it is well-organized for a complex 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 tool's complexity (22 parameters), the description covers all necessary details including constraints and warnings. An output schema exists but is not referenced; describing the return value (e.g., 'returns the updated ad set') would improve completeness. Nevertheless, the description is thorough and handles edge 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 description coverage is 0%, so the description must compensate. It does so excellently by providing detailed semantics for each parameter: examples, valid values, interdependencies, requirements, and warnings. For bid_strategy, it lists all valid options and notes; for bid_constraints, it gives a concrete example. This far exceeds the schema's bare information.

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: 'Update an ad set with new settings including frequency caps and budgets.' The verb 'Update' and the required adset_id parameter indicate modification of an existing ad set, but it does not explicitly differentiate from sibling tools like create_adset or update_campaign beyond the verb.

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 minimal usage guidance. It includes specific warnings (e.g., is_dynamic_creative is immutable, attribution_spec unsupported) but lacks general guidance on when to use this tool versus alternatives like create_adset or update_ad. No explicit exclusions or context for tool selection.

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

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

No annotations provided, but the description fully discloses critical behaviors: campaign cannot use start_time, CBO→ABO migration mechanics with atomicity, deprecation of use_adset_level_budgets, and that objective may not always be updatable. This is exemplary 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 well-organized with a purpose statement, informative note, migration section, and parameter list. While lengthy, every part earns its place. Could be slightly more concise, but clarity is prioritized over brevity.

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 all parameters, includes migration guidance, deprecation info, and a key constraint. An output schema exists so return values are assumed covered. Missing mention of errors or rate limits, but given complexity this is acceptable.

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, so description must explain all 14 parameters. It provides meaningful descriptions for each, including units, examples for adset_budgets, and notes on optional vs required. Some parameters like bid_strategy lack possible values, but overall adds significant value beyond schema titles.

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 an existing campaign in a Meta Ads account.' This directly conveys the tool's action and resource, distinguishing it from sibling tools like create_campaign or get_campaign_details.

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: start_time note, migration details, and deprecation warning. However, it does not explicitly state when to use this tool versus create or get tools, though the name and first line are sufficient.

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

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

No annotations present, so description fully handles behavioral disclosure. Explains two methods for image input (file vs image_url), optional access_token, default name behavior, and details return object structure including image_hash and images list. No mention of destructive actions or limits, but behavior is well-covered.

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

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

Description is concise with a one-line summary followed by clearly labeled Args and Returns sections. No extraneous information; every sentence contributes to understanding.

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 5 parameters, no annotations, and presence of an output schema (which is compensated by the description's return section), the description is complete. It explains input, output, and ties to other tools (create_ad_creative, get_image_by_hash). No 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?

Schema coverage is 0%, yet description adds full meaning for each parameter: account_id format 'act_XXXXXXXXX', file as data URL or base64, image_url as direct URL, access_token optional with fallback, name defaults to filename. This compensates fully for the schema's lack of 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 'Upload an image to use in Meta Ads creatives.' Identifies the specific resource (image) and action (upload), distinguishing it from retrieval tools like get_ad_image and creative-building tools like create_ad_creative.

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 on when to use (for ad creatives) and how output image_hash ties into create_ad_creative and get_image_by_hash. Lacks explicit 'when not to use' but implies the tool is for uploading, not for other operations.

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