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

No annotations are provided, so the description carries full burden. It only states the basic action without disclosing atomicity, error handling, limitations on object count, required permissions, or effects on ad delivery, leaving significant 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 concise with 5 lines, starting with a clear summary sentence and a structured parameter explanation. It is efficient but could be slightly more front-loaded.

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

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

Given the tool is a bulk operation with one parameter and no output schema, the description lacks return value info, error handling, rate limits, and behavioral details, making it incomplete for confident use.

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

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

The schema provides only a string type with 0% coverage. The description adds the exact JSON array format, including object structure and allowed object_type values, which is essential for correct invocation 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 'Rename multiple Meta Ads objects in one call', identifying the specific verb (rename) and resource (Meta Ads objects), and emphasizes the bulk aspect, distinguishing it from individual rename operations.

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

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

The description implies usage for bulk renames via 'multiple...in one call', but does not explicitly contrast with sibling tools like update_ad, update_adset, or update_campaign, nor provide when-not-to-use or alternative guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool returns token validity, granted/missing permissions, and rate limit usage, which is good behavioral context. It could mention error handling or authentication assumptions, but overall solid.

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

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

The description is two sentences: first defines the purpose, second lists outputs. No wasted words, front-loaded with critical information. Excellent conciseness.

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

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

For a simple diagnostic tool with no parameters and no output schema, the description covers the key outputs (validity, permissions, rate limit). It could add notes on error scenarios or intended use as a preliminary step, but 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?

The input schema has zero parameters, so baseline is 4. The description adds no parameter info beyond what the schema provides, which is acceptable as there are no parameters to describe.

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 checks Meta API token health, permissions, and rate limit status. It uses specific verbs ('check') and resources ('Meta API token'), distinguishing it from sibling tools focused on ad management and pixels.

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 token verification, but does not explicitly state when to use this tool over alternatives or provide prerequisites. Given no overlapping sibling tool, usage is implied but not formally guided.

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

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

With no annotations, the description carries full burden. It discloses auto-resolution of Instagram identity and fallback to Facebook-only, plus naming enforcement. It lacks details on rate limits or idempotency but is generally 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?

Well-structured: purpose, return value, requirements, limitations, then parameter list. Every sentence is informative without redundancy. Length is appropriate 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 9 parameters with 0% schema coverage and no output schema, the description covers all inputs and explains the output (creative_id). It addresses constraints (single-image only) and integration with other tools.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains each parameter in detail (e.g., account_id format, image_hash origin, valid CTA types) and adds context beyond the 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 explicitly states 'Create a standalone single-image ad creative' and identifies the resource and type. It mentions the return value (creative_id) and distinguishes from create_multi_asset_ad for video/carousel/dynamic creatives.

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

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

Clearly specifies when to use this tool (single-image creatives) and provides the alternative create_multi_asset_ad for other types. It lists requirements like Facebook Page ID but does not explicitly state when not to use beyond that alternative.

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

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

Describes internal steps: loads manifest, detects mode, resolves identity, checks duplicates, validates, creates, verifies. States ad is always PAUSED. With no annotations, this provides adequate transparency, though it does not detail permissions or 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?

The description is lengthy but well-structured with clear sections (Instagram gate, video ads, Args list). It front-loads the main purpose. Minor redundancy could be trimmed, but overall it's organized and informative.

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 23 parameters and no output schema, the description covers prerequisites, behavior, and all parameters. Missing return value explanation, but acceptable. Provides sufficient context for an AI 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?

With 0% schema coverage, the description compensates fully by explaining each parameter's purpose, defaults, and conditions (e.g., copy_mode values, overrides, dry_run). Even required and optional parameters are well-described, adding significant 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 creates an ad from a manifest entry, always PAUSED, with manifest-driven behavior and no exceptions. It distinguishes itself from siblings like create_ad_creative by specifying the manifest-driven nature and the always-paused state.

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

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

Provides explicit guidance on when to use different placement modes (full_meta, facebook_only, instagram_only) and prerequisites for video ads (need meta_video_id from upload_video_asset and poll_video_processing). Does not explicitly mention when not to use this tool, but context is clear.

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

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

With no annotations, the description fully carries the burden. It discloses the always-PAUSED initial state, lists enforcement steps (audience enforcement, campaign inspection, ABO/CBO enforcement, etc.), and explains parameter dependencies (e.g., tracking mode overrides, audience_mode restrictions).

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 front-loaded summary and a detailed Args section. While informative, the list of enforcement steps and repeated parameter details could be slightly more concise, but overall it efficiently communicates needed information.

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

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

The description covers complexity well: budget modes, campaign state, tracking overrides, and audience modes. However, it does not mention the return value (likely the new ad set ID) or error handling behavior, which are minor gaps 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 coverage is 0%, but the description provides extensive parameter explanations with examples (e.g., targeting_json, promoted_object_json), constraints, and usage context. It adds meaning beyond the schema's basic type and title 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 'Create a new ad set (always PAUSED, no exceptions)' with a specific verb and resource. It lists enforcement steps that distinguish it from update or duplicate operations, providing clear differentiation from siblings.

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

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

The description provides detailed constraints for parameters (e.g., campaign_id must be PAUSED or ACTIVE, budget rules for ABO/CBO) and explains when to use optional parameters. However, it does not explicitly state when to use this tool versus alternatives like update_adset or duplicate_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, the description discloses key behaviors: naming enforcement, pre-write validation, post-write verification, mutation logging, and the PAUSED status. This goes beyond a simple creation statement.

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

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

The description is concise: a one-line purpose, a bullet of steps, and parameter list. No redundant 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?

Given no annotations or output schema, the description covers creation behavior, parameter details, and naming conventions. It lacks return value or error handling, but is sufficient 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 explains each parameter: account_id with example, name with naming convention, objective with list of valid values, and product/funnel/budget_model for auto-correction.

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 campaign' with the specific constraint 'always PAUSED, no exceptions.' It distinguishes from sibling tools like update_campaign and duplicate_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 explicitly says 'always PAUSED, no exceptions,' guiding when to use this tool (for creation) vs. update for activation. It implies naming enforcement, but no explicit when-not-to or alternatives.

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

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

No annotations provided, so the description carries the full burden. It discloses key behaviors: enforced identity, asset modes, copy generation modes, Instagram gate, and blocking conditions. However, it does not mention return values or error handling, which would enhance transparency.

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

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

The description is well-structured with sections and clear bullet points. It is fairly lengthy but each section adds necessary context. Could be slightly more concise by trimming redundant phrasing, but overall it's appropriately front-loaded and organized.

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 19 parameters and no output schema, the description covers modes, constraints, and conditional logic well. It lacks return value information and could mention error scenarios. Still, it provides sufficient context for an AI agent to understand usage.

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

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

Input schema has 0% description coverage, so the description adds significant value. It explains the purpose and conditional requirements for many parameters (e.g., copy_mode, placement_mode, video/image hashes). Some parameters like account_id have minimal explanations, but overall it clarifies usage 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 it creates an ad with enforced identity, multi-asset support, and verification. It specifies two asset modes (VIDEO and STATIC IMAGE) with explicit conditions, distinguishing it from sibling tools like create_ad_creative (single image) and 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 provides explicit guidance on when to use each mode, what is blocked (mixed video+image, single image hash), and the Instagram gate via placement_mode. It also references the alternative tool create_ad_creative for single image cases.

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 any behavioral traits such as side effects, authentication requirements, idempotency, or error handling. The sole verb 'Create' suggests mutation, but no further behavioral context is given.

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

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

The description is a single sentence followed by a structured list of parameters with examples. Every part is concise and adds value; no redundant information.

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

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

The description covers parameter semantics adequately but lacks details on return behavior, potential errors, or prerequisites. For a simple creation tool with no output schema, it is minimally complete but could include more context like expected responses.

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

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

The description's Args section provides clear, brief explanations for all 3 parameters (catalog_id, name, filter_json) including an example for filter_json. This adds meaning beyond the schema names, especially given 0% schema description 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 states 'Create a product set with filter rules for DPA targeting.' This clearly identifies the verb (create), resource (product set), and context (DPA targeting), effectively distinguishing it from related tools like get_product_sets or update_product_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 implies when to use the tool (to create a new product set) but provides no explicit guidance on when not to use it or alternatives like update_product_set. The sibling list includes update_product_set, but the description does not contrast usage.

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 the destructive nature, the order of deletion, the dry-run safety mechanism via the 'confirm' parameter, and the behavior of 'delete_all_active'. It lacks details on reversibility or conflict handling but is adequate for safe invocation.

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 front-loaded purpose sentence followed by brief bullet point explanations of arguments. Every sentence adds value, and there is no redundant or extraneous 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?

Given the lack of annotations and output schema, the description provides sufficient context for invocation: it covers the action, parameter behavior, and safety mechanism. It omits the return value or status, but this is not critical for tool selection. Overall, it is reasonably 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. It fully explains all 4 parameters: account_id, campaign_ids_json (with interaction with delete_all_active), delete_all_active, and confirm (dry run vs actual deletion). This adds significant meaning beyond the schema's basic type and default 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 it deletes the entire campaign structure in the correct order (ads -> adsets -> campaigns). This is a specific verb ('delete') and resource ('campaign structure'), and it distinguishes itself from sibling tools, none of which are delete operations.

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

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

The description provides clear context that this tool is used for deleting a campaign hierarchy, but does not explicitly state when not to use it or mention alternative tools. However, since it is the only delete tool among siblings, the usage is implicitly clear.

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

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

No annotations are provided, so the description carries the full burden. It states the tool performs a headless browser check and lists what is checked, but does not disclose whether any state modification occurs or what side effects exist. The read-only nature is inferred from 'diagnose' but not explicitly confirmed.

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

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

The description is four concise sentences, each serving a purpose: purpose statement, list of checks, prerequisite, and parameter definitions. It is front-loaded and contains no redundant information.

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

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

The description lacks details about return value format (e.g., pass/fail per check, error messages) and does not address error conditions or performance. Given no output schema, the agent has insufficient information about what to expect after 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 description adds meaning to both parameters: url is the website URL to check, pixel_id is an optional specific pixel ID to look for. This goes beyond the schema's type-only definitions, especially given 0% schema description coverage in the context signals.

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 diagnoses pixel installation via headless browser check and explicitly lists the checks performed (pixel script presence, consent blocking, Lead event setup, Complianz status). This distinguishes it from sibling tools like get_pixel_info or get_pixel_events which retrieve data rather than diagnose installation.

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 a prerequisite (browser MCP/Puppeteer availability) but does not provide explicit guidance on when to choose this tool over alternatives, nor does it mention when not to use it. Usage is implied by the diagnostic nature.

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 states the tool returns a 'comprehensive mapping of all accessible assets', implying it is a read operation, but does not explicitly disclose whether it modifies state, requires special permissions, or has rate limits. The description is adequate but could be more transparent about 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?

The description is extremely concise with three sentences, each adding distinct value: the first describes the action, the second the use case, and the third the output format. No redundant or extraneous text, and the key information is front-loaded.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description provides a clear purpose, use case, and output description. It could mention whether it is read-only or idempotent, but overall it is complete enough for an agent to understand when and how to invoke it.

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

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

The input schema has zero parameters, so schema coverage is effectively 100%. The description does not need to explain parameters. A score of 4 reflects that no additional parameter information is required, and the description is not penalized for lacking param details.

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 discovers all ad accounts along with their pages, pixels, and Instagram accounts. The verb 'discover' and resource 'all ad accounts' are specific, and it distinguishes from sibling tools like 'get_ad_accounts' which likely only lists accounts without the comprehensive mapping.

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

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

The description explicitly says it is used to generate or update the account registry ('config/accounts.yaml'), providing a concrete use case. It implicitly guides when to use this tool versus simpler list tools like 'get_ad_accounts' by mentioning the comprehensive mapping, though it lacks explicit 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?

Discloses key behaviors: created objects are paused, child ads are not duplicated, and budget override behavior. Lacks info on error handling or return value, but no annotations are present.

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

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

Very concise with a clear summary followed by bullet-pointed args; 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?

Covers input semantics and constraints well, but lacks description of the return value (e.g., ID of duplicated ad set) which would be helpful given no output schema.

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

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

The description explains each parameter's purpose and defaults (e.g., budget_override in EUR, name_suffix default), significantly adding meaning beyond the input schema's bare property names.

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

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

The description clearly states the tool duplicates a single ad set into a target campaign within the same account, distinguishing it from siblings like 'duplicate_campaign' and noting it does not duplicate child ads.

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

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

Explicitly mentions same-account only and that created objects are paused, but does not compare to alternatives like 'create_adset' or specify when not to use it.

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

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

With no annotations provided, the description fully covers behavioral aspects: 'All created objects are PAUSED' and 'when include_ads=True, ads are duplicated with their existing creative references (creatives are reused, not copied).' Lacks details on idempotency or rate limits but overall strong.

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

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

Well-structured: core purpose first, then constraints, then Args section. Every sentence is informative with no redundancy. Appropriate length for the tool's complexity.

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

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

Covers purpose, parameter semantics, and key behavioral notes despite no output schema or annotations. Could mention error handling or return format, but overall provides sufficient context for correct invocation.

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

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

Schema coverage is 0%, so description must add meaning. It provides detailed explanations for all 6 parameters: purpose of campaign_id, account_id, name_suffix (with default and constraint), include_adsets, include_ads, and adset_budget_override (with ABO context and currency). Adds significant value beyond field names.

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

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

Clearly states 'Duplicate a campaign (and optionally its child ad sets and ads) within the same account.' This specific verb-resource combination distinguishes it from sibling 'duplicate_adset' and includes scope constraint.

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 'Same-account only. Cross-account duplication is not supported,' providing a clear when-not-to-use condition. Does not explicitly mention alternatives (e.g., duplicate_adset) but usage context 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?

No annotations exist, so the description carries the full burden. It describes the tool as estimating reach, which is non-destructive, but does not explicitly confirm it is a read-only operation. The behavioral traits are implied but not fully disclosed.

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

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

The description is extremely concise: two sentences plus an Args section. It is front-loaded with the primary purpose and provides necessary details without extraneous text.

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 estimation tool, the description covers purpose, parameters, and return values (daily reach bounds). It lacks discussion of error conditions or edge cases, but overall is sufficient given the tool's simplicity and no output schema.

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

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

Schema description coverage is 0%, so the description compensates well by explaining account_id with an example format and targeting_json with a JSON string example. This adds substantial meaning beyond the schema alone.

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 estimates audience reach for a targeting specification and returns daily reach bounds. It uses specific verbs and resources, distinguishing it from sibling tools that manage ads or accounts.

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

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

The description implies use for estimating audience size given a targeting spec and account, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons are provided.

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

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

Despite no annotations, the description clearly indicates the tool generates names without side effects. It does not describe return format but is transparent about its non-destructive nature.

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

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

The description is front-loaded with purpose and well-structured. It is somewhat lengthy due to parameter details, but every sentence adds value.

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

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

For a tool with 12 parameters and no output schema, the description is quite complete. It covers parameter values and conventions, though it could mention the output format more explicitly.

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 compensates by listing allowed values for each parameter, defaults, and conventions, providing critical context beyond the schema.

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

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

The description clearly states the tool generates names for Meta Ads objects following a naming convention. It distinguishes from siblings like create_campaign by focusing on naming, not 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?

While the description does not explicitly state when to use versus alternatives, the naming focus is clear. The extensive parameter documentation implicitly guides usage.

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 the description carries the full burden. It lists the categories of returned data (configuration, status, spend, pixel info, connected assets), giving a good sense of the output. However, it doesn't mention prerequisites, error conditions, or whether the account must be owned.

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

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

The description is concise (two sentences plus an Args section) and front-loaded. Every sentence adds value without redundancy.

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

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

Given the tool has one required parameter and no output schema, the description provides sufficient detail about purpose and parameter. It lists output categories but omits error handling or detailed output structure. Still, it is nearly complete for a straightforward 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?

Schema description coverage is 0%, but the description adds an example format ('act_123456789') for the account_id parameter, which clarifies the expected prefix and format. This compensates for the lack of schema-level documentation.

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

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

The description clearly states the tool's purpose: 'Get detailed information about a specific ad account.' It lists the types of data returned (configuration, status, spend, pixel info, connected assets), distinguishing it from siblings like 'get_ad_accounts' which lists accounts.

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies it's for a single account by ID, but doesn't contrast with siblings such as 'discover_all_accounts' or 'get_ad_accounts'. Usage context is inferred but not clarified.

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

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

No annotations are present, so the description must carry the burden. It only says 'List ... available for ads,' implying read-only but lacks explicit details on required permissions, error handling, or rate limits. Minimal behavioral disclosure.

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

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

The description is extremely concise with two lines of purpose and a parameter block. It is front-loaded with the main action and wastes no words. Every sentence earns its place.

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

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

For a simple list tool with one parameter and no output schema, the description covers the basics but lacks details on output format, pagination, or any side effects. It is minimally viable but not fully informative.

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 adds value by providing an example format ('e.g., 'act_123456789''), clarifying the required prefix and structure. It does not explain the parameter's meaning beyond the name, but the example is helpful.

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

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

The description clearly states 'List Facebook Pages available for ads on a specific ad account.' It specifies the verb (List), resource (Facebook Pages), and context (available for ads, per account). This adequately distinguishes it from sibling tools like resolve_page_identity.

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 compared to alternatives. It does not mention conditions, prerequisites, or when to avoid it. The agent must infer usage from the purpose alone.

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 states the tool lists ad accounts and returns specific fields, but does not disclose authorization details, side effects, or pagination behavior beyond the limit parameter.

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 (4 lines) with no unnecessary words. Each sentence contributes value: purpose, output fields, and parameter explanation.

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

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

While the description covers purpose and one parameter, it contains a slight contradiction ('List all' vs 'maximum number to return') and omits details like error handling or authentication requirements. No output schema exists to supplement.

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 description for the 'limit' parameter. The description clearly explains its meaning ('Maximum number of accounts to return') and provides the default value, adding essential context.

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 'List' and clearly identifies the resource 'ad accounts accessible to the authenticated user'. It differentiates from sibling tools like get_account_info by focusing on listing all accounts in the portfolio.

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

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

No explicit guidance on when to use this tool vs alternatives. It does not mention scenarios where other tools might be preferred or provide exclusion criteria.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions 'image hash resolution' as a feature, but does not explicitly state that the tool is read-only, safe, or any side effects. For a list operation, this is adequate but not thorough.

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 clear first-line summary followed by structured Args. Every sentence adds value. Slightly longer than necessary but no fluff. Front-loading of purpose is good.

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 three parameters and no output schema, the description covers what the tool does and all parameters. However, it lacks details about the return format (e.g., list of creative objects with fields) and any limitations (e.g., pagination behavior). This is a minor gap for a simple list tool.

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

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

The input schema has no property descriptions (0% coverage), but the description explains the purpose of each parameter: account_id for image hash resolution, ad_id for targeting a specific ad, and limit for pagination. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool lists ad creatives for an account or specific ad, with a specific feature (image hash resolution). It distinguishes from siblings like get_creative_details (which gets details of a single creative) and 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?

The description implies usage: provide account_id to list all creatives, or ad_id to target a specific creative. However, it does not provide explicit guidance on when to prefer this over siblings (e.g., get_creative_details) or mention any prerequisites or scenarios to avoid.

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 fails to disclose behavioral traits such as whether the operation is read-only, any side effects, or rate limits. It only lists output categories, lacking 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 concise, with two sentences and a bullet list of details, followed by an Args section. It is front-loaded and avoids unnecessary text, though it could be more structured for 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 low complexity (single parameter, no output schema), the description adequately lists the main output categories. However, it lacks details like error handling, permissions, or response format, leaving some gaps.

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

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

With 0% schema description coverage, the description adds minimal meaning by stating ad_id is an 'Ad ID (numeric string)'. This clarifies the type but does not specify format constraints or validation rules, providing only basic semantic value.

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

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

The description clearly states the tool retrieves 'detailed ad information' and lists specific categories like creative reference, tracking specs, etc. It distinguishes from sibling tools like get_ads or get_ad_creatives by focusing on detailed details, but it does not explicitly differentiate from all siblings.

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

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

No guidance is provided on when to use this tool vs. alternatives, prerequisites, or when not to use it. The description only explains what it does without contextual usage advice.

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 discloses that the tool retrieves data (not modifies), but lacks details on error handling, permissions, or rate limits. Adequate but not comprehensive.

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

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

The description is concise: three sentences plus parameter docs, front-loaded with the main purpose. Every sentence adds value without redundancy.

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

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

Given no output schema, the description specifies return fields (URL, dimensions, name, other metadata), which is sufficient for a simple retrieval. It does not cover error cases, but overall adequate.

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

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

Schema descriptions are missing (0% coverage), but the description adds helpful context: account_id includes an example format, and image_hash is linked to 'upload_ad_image'. This adds 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 clearly states 'Retrieve metadata and URL for an uploaded ad image by hash', using a specific verb and resource. It distinguishes from sibling tools like 'upload_ad_image' by focusing on retrieval.

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 guidance on when to use this tool vs alternatives, nor does it mention when not to use it. It simply states what it does without contextual usage advice.

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

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

Description indicates a read-only list operation, but no annotations provided. Does not mention side effects, rate limits, or pagination behavior beyond the limit parameter. Adequate but minimal.

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?

Starts with a clear one-liner, then bulleted parameter list. No redundant information, each sentence adds value. Efficient and well-structured.

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

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

Lacks return value description (e.g., fields of ad objects) or pagination details beyond limit. Despite good parameter coverage, the absence of output schema and explanation of results reduces 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 compensates fully by providing explanations, examples (e.g., 'act_123456789'), and defaults (limit=50). Adds significant 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?

Clearly states the tool lists ads, with specific scope (account, campaign, or ad set). Distinguishes from siblings like get_ad_details (single ad) or get_ad_creatives (creatives).

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

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

Implicitly useful for listing ads with filters, but no explicit guidance on when to use this versus alternatives like get_ad_details or get_ad_creatives. Lacks exclusion criteria.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It describes the tool as a read operation and lists the type of information returned, but does not address potential side effects, authorization needs, error conditions, rate limits, or the structure of the response. The behavioral transparency is minimal.

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

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

The description is extremely concise: two sentences plus an args line. The main purpose is front-loaded, and there is no superfluous information. Every word serves a clear function, making it efficient for an agent to parse.

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 (single parameter, no output schema), the description provides a reasonable outline of what is returned (targeting, optimization, learning stage, etc.). It adequately differentiates from sibling tools. However, it lacks details on error handling, response format, or edge cases, which would enhance 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?

The parameter 'adset_id' is described as 'Ad set ID (numeric string)', adding semantic value beyond the schema which only specifies type string. The schema coverage is 0%, so the description compensates by clarifying the format. However, it does not explain the meaning or context of the adset ID, which is already implied by the tool name.

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

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

The description starts with 'Get detailed ad set information', clearly stating the verb (get) and resource (ad set details). It lists specific categories included, distinguishing it from sibling tools like get_adsets (which lists adsets) and get_ad_details (which gets ad details). The purpose is explicit and 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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or situations where other tools might be more appropriate. The only implied usage is when one needs detailed ad set info, but no explicit when/when-not or alternatives are 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?

No annotations provided, so description carries burden. It mentions pagination via 'limit' parameter but not how to get next pages. No info on rate limits, authorization, or side effects. Partially adequate.

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

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

Two sentences plus a compact bullet list for args. Front-loaded with main purpose. 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 no output schema and no annotations, the description lacks return value format, error handling, and required permissions. Partially complete for a simple list tool, but could be improved.

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 must add meaning. It explains account_id with example, campaign_id as optional filter, status_filter with valid values, and limit with default. 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 states 'List ad sets' with clear verb and resource, and indicates filtering by account or campaign. It distinguishes from siblings like get_adset_details, create_adset, 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?

Implies usage for listing adsets with optional filters, but does not explicitly provide when to use this vs alternatives like get_adset_details or duplicate_adset. No exclusions stated.

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

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

No annotations are provided, so the description must compensate. It discloses that the tool aggregates spend, impressions, clicks, conversions, ROAS and uses accounts from Meta API. It also mentions the limitation on campaign-level. However, it does not state whether this is a read-only operation or any safety or rate-limit considerations.

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 5 sentences, front-loaded with the core purpose, followed by aggregated metrics, data source note, and a clear Args block. Every sentence adds value, 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 inputs and limitations but omits output details. There is no output schema, so the agent has no idea what the response structure looks like. It also does not mention pagination or behavior when limit_accounts is exceeded.

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 no descriptions for parameters and 0% coverage. The description adds meaning: it explains the time_range string options, clarifies that level only supports 'account', and defines limit_accounts as max accounts with default 20. This compensates well for the lack of schema descriptions.

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

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

The description clearly states 'Get performance insights across all accessible ad accounts in one call.' It specifies the verb 'Get', resource 'performance insights', and scope 'across all accessible ad accounts'. This distinguishes it from siblings like get_insights, which is likely for a single account.

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

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

The description provides context on when to use this tool (for bulk insights across accounts) and notes that it uses accounts from the Meta API, not accounts.yaml. It explicitly states campaign-level bulk is not supported. It does not name an alternative tool, but the context is clear enough.

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

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

No annotations provided, so description carries burden. 'Get' implies read-only, but does not explicitly confirm no side effects, auth needs, or rate limits. Lists returned fields but no structure details. Adequate but not comprehensive.

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

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

Two short paragraphs: first states purpose with specific examples, second documents the argument. No fluff, every sentence adds value. Front-loaded with the main action.

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

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

For a single-parameter tool with no output schema, the description covers purpose, parameter meaning, and return fields. Could include more detail on return structure or edge cases, but sufficient for typical use.

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

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

Despite 0% schema description coverage, the description clarifies that campaign_id is a numeric string, adding format context. Also lists what the tool returns (fields not in schema). Fully compensates for missing schema parameter info.

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

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

Clearly states it gets detailed campaign info, listing specific fields (budget, objective, bid strategy, etc.). Distinguishes from sibling get_campaigns (which likely lists campaigns) and other get_* tools for different entities.

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

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

Implies use when you need details for a specific campaign (requires an ID), but no explicit guidance on when to use vs alternatives like get_campaigns or when not to use. Minimal context for choosing among many 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 carries the full burden. It adds behavioral info like default limit, max 100, and effective_status filter behavior. However, it omits details on pagination, sorting, and error handling.

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 clear summary and structured Args section. Each sentence adds value, though the format could be slightly more streamlined.

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 does not detail return values beyond 'status and budget info.' Missing pagination details, error conditions, and field names reduce completeness for a listing 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 compensates fully: it explains account_id format, status_filter enum values, and limit defaults/max. All parameters are clearly 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 states 'List campaigns for an ad account with status and budget info,' providing a specific verb and resource. It clearly distinguishes from siblings like get_campaign_details (single campaign) 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?

No explicit guidance on when to use this tool vs. alternatives like get_campaign_details or other list tools. Usage is only implied by the name and description.

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 explicitly state that this is a read-only operation, nor does it disclose any side effects, authentication needs, or error handling. For a simple get, the read-only nature is implied but not confirmed.

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

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

The description is concise with two sentences plus an Args line, front-loading the main purpose. The Args section is justified given the schema's lack of descriptions, making it efficient and relevant.

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

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

Despite no output schema, the description lists expected return fields (product count, vertical, name, connected event sources), and clarifies the single parameter. For a simple retrieval tool, this provides adequate completeness, though error handling is omitted.

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% description coverage, but the description adds 'Product catalog ID (numeric string)' for the single parameter, clarifying that it expects a numeric string. This adds meaningful context 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 retrieves catalog details and lists specific attributes (product count, vertical, name, connected event sources). It distinguishes itself from numerous sibling 'get_' tools by focusing on catalog information.

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, no context on prerequisites or exclusions. Among many get_* functions, the usage context is implied but not 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?

No annotations provided, so description must cover behavioral traits. It indicates a read operation but does not mention pagination, rate limits, or auth requirements. The lack of these details leaves gaps for safe invocation.

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 two sentences for purpose and a structured list for args. No wasted words; every sentence adds value.

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

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

With no output schema, description partially compensates by listing returned fields (price, availability, etc.), but lacks details on output format, pagination behavior, or authentication constraints. Adequate for a simple list tool but not exhaustive.

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

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

Schema coverage is 0%, so description carries full weight. It adds meaning: catalog_id as 'Product catalog ID', limit with 'default 25, max 100', filter_availability with three explicit values. This goes beyond the schema's property names.

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

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

Description has specific verb 'List' and resource 'products in a catalog', with details on fields like price, availability, review status, and URLs. It clearly distinguishes from siblings such as get_catalog_info (catalog metadata) and get_product_sets (product groupings).

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

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

No guidance on when to use this tool vs alternatives like get_catalog_info or get_product_sets. The description only states what it does, leaving the agent to infer context.

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

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

No annotations are provided, so the description must carry the full burden. It implies a read operation (get details) but does not explicitly state it is read-only, nor does it mention any side effects, authorization needs, or rate limits. Given the criticality with missing annotations, the description falls short.

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

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

The description is concise and front-loaded with the purpose. The parameter section is clearly separated and efficient. Slightly more brevity could be achieved, but it is well-structured and informative.

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

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

The description explains what fields are returned and documents both parameters well. However, it lacks details on return format, error states, or pagination. Given no output schema, more context would be beneficial, but it is adequate for a simple retrieval tool.

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

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

The description adds significant meaning beyond the schema: it explains creative_id is a numeric string, and account_id is optional with the specific consequence that image hashes will not be resolved to URLs if omitted. With 0% schema coverage, this high-quality parameter documentation justifies a 4.

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

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

The description clearly identifies the tool's action (get full creative details) and lists specific returned fields (mode classification, media URLs, object_story_spec, etc.), distinguishing it from siblings like get_ad_creatives which probably list creatives rather than get full 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?

No explicit guidance on when to use this tool vs alternatives. It only states what it does without any context on appropriate scenarios, prerequisites, or when to avoid using it. This is a clear gap.

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 transparency burden. It implies read-only behavior through 'get' and 'checks', and outlines the analysis performed (coverage, completeness, flags, health). However, it does not explicitly state that no side effects occur or describe the output format, missing some behavioral details.

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 (four sentences) and front-loaded with the primary purpose. Each sentence adds necessary information without redundancy, making it efficient for an AI agent to parse.

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 and parameters well but omits the output structure or return value. Given no output schema, mentioning what the tool returns (e.g., a health status or stats object) would improve completeness, but the current level is adequate for basic use.

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

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

With 0% schema description coverage, the description fully explains both parameters: pixel_id as a numeric string and archetype with allowed values and default. This adds significant meaning beyond the schema's basic type and title, enabling correct use.

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

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

The description clearly states the tool retrieves event statistics with archetype-aware diagnostic analysis, specifying checks on event coverage, parameter completeness, and diagnostic flags. It effectively distinguishes from sibling tools like get_pixel_events or diagnose_pixel_on_site by focusing on aggregated analysis and classification.

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 explicit guidance on when to use this tool versus alternatives, such as get_pixel_events for raw events or run_tracking_diagnostic for broader diagnostics. The usage context is implied but not spelled out, leaving room for confusion among the many 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?

Describes the return of normalized metrics with objective-aware extraction, detailed archetype specializations, and the compact option. No annotations provided, but description provides good behavioral context. Lacks mention of authentication or rate limits, but still strong.

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

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

Well-structured with purpose first, then key features, then parameter explanations in list form. Somewhat lengthy but each sentence adds value. Could be slightly more concise.

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

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

Covers parameters well but lacks output schema explanation and details on the compact summary format. No mention of pagination or response structure, which is needed for a complex data retrieval 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%, but description explains all 7 parameters in detail, including allowed values for time_range, breakdowns, level, archetype, and the meaning of compact. Adds immense 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?

Clearly states the verb 'Get', the resource 'performance insights', and the scope 'any Meta Ads object (account, campaign, ad set, or ad)'. Distinguishes from sibling 'get_bulk_insights' by focusing on single object insights.

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

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

No explicit guidance on when to use this tool versus alternatives like 'get_bulk_insights'. Does not mention when not to use it or any prerequisites.

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

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

No annotations are provided, so the description bears full responsibility. It indicates a read operation by saying 'list' and mentions return value, but lacks details on authentication needs, error handling, or prerequisites like linked Instagram accounts.

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

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

The description is extremely concise with only two sentences plus an argument line, no fluff, and front-loaded with the main purpose. Every sentence adds value.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description adequately explains purpose and parameter usage. It could be more complete by describing the response format (e.g., list of objects or strings) and error conditions, but overall it is fairly complete given the tool's simplicity.

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

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

The input schema has one parameter with no description, but the description adds meaning by providing the format and example ('act_123456789'). This compensates for the 0% schema description 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 specifies the tool lists Instagram accounts available for ads on a specific ad account, uses verb 'list', and mentions returning the canonical identifier. It distinguishes from siblings by stating it's the first step in the Instagram identity resolution ladder.

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 by stating it's the first step in the identity resolution ladder, implying its use before other steps. However, it does not explicitly mention when not to use it or alternative tools, but the context is clear enough.

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

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

No annotations provided, so description carries full burden. It describes input and output but does not disclose whether it is read-only, rate limits, or any side effects. Lacks behavioral context like data source or authorization needs.

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

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

Well-structured with Args section. Information is front-loaded but could be slightly more concise. Every sentence adds value, but some repetition 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 no output schema, description hints at return value ('suggested related interests') but lacks details on format. For a simple tool with 2 params, it is fairly complete but could mention output structure.

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 description fully explains both parameters: interest_list can be IDs or names (with examples), limit has default and meaning. Adds significant value 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?

Description states 'Get related interest suggestions from seed interests' with clear verb and resource. It is distinct from siblings like search_interests and estimate_audience_size.

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

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

No explicit guidance on when to use vs alternatives. The description implies usage for targeting expansion but does not list exclusions or mention 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?

With no annotations, the description carries full burden. It discloses the time window (last 24 hours) and output breakdown (by event type and hourly counts). It does not mention side effects or permissions, but for a read operation this is acceptable. The description is transparent enough for the 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 extremely concise: one sentence plus a parameter line. It front-loads the purpose with no wasted words. Ideal for quick 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 the tool's simplicity (1 param, no output schema), the description covers the purpose and parameter. However, it omits details on the response structure (e.g., format of hourly counts, event types). Since there is no output schema, more description of output would be beneficial. Adequate but not fully 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?

The schema has 0% description coverage; the parameter only has a title. The description adds minimal value by noting pixel_id is a 'numeric string', but does not compensate for the lack of schema descriptions. The param description is insufficient.

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 events received by a pixel in the last 24 hours, broken down by event type and hourly counts. This specific verb+resource+scope distinguishes it from siblings like get_pixel_info or get_event_stats.

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

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

No guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or other context. The sibling list is provided externally but the description itself lacks usage direction.

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 clearly indicates the tool returns status, connections, last fired time, and availability. It implies a read-only retrieval operation. No side effects or additional behaviors are mentioned, but the output scope is 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 two sentences: one for the tool's purpose and one for the parameter. Every word adds value, and the key information is front-loaded. No fluff.

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

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

For a simple 1-parameter retrieval tool with no output schema, the description covers the basic output. However, it lacks context like read-only nature, potential errors (e.g., invalid pixel_id), and when to prefer this over similar tools.

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

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

The input schema has no property description (0% coverage). The description adds that pixel_id is a 'numeric string', which provides type guidance beyond the schema, but is minimal.

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 pixel status, connections, last fired time, and availability. The verb 'Get' and resource 'pixel' are specific, and the listed data items distinguish it from sibling tools like get_pixel_events or diagnose_pixel_on_site, though no explicit differentiation is made.

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

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

No guidance on when to use this tool versus alternatives such as get_pixel_events or diagnose_pixel_on_site. There is no mention of prerequisites, context, or 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 carries the full burden. It only states the tool lists product sets with counts and filter rules but does not disclose behavioral traits like read-only nature, potential pagination, or required permissions. This is insufficient for safe invocation.

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 short (two lines) and free of unnecessary words, but it lacks structure such as front-loading the tool's purpose or using bullet points. It is minimally acceptable but could be improved without 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 simple tool with one parameter and no output schema, the description is incomplete. It does not explain the output format, the concept of 'filter rules', or provide any usage examples. This leaves the agent uncertain about what to expect.

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

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

With 0% schema description coverage, the description must add meaning to the parameter. It only repeats 'Product catalog ID' without explaining what a catalog ID is, how to obtain it, or its format. This adds no 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 uses a specific verb 'List' and resource 'product sets in a catalog', and distinguishes this tool from sibling tools like 'get_catalog_info' and 'get_catalog_products'. However, it could be more precise by stating that it lists all product sets for a given catalog, including counts and filter rules, which would further differentiate it.

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

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

No guidance on when or when not to use this tool compared to siblings such as 'get_catalog_products' or 'get_catalog_info'. The description fails to provide context about prerequisites or alternative tools for similar tasks.

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 the description carries the full burden. It discloses that the tool flags audiences with issues (unusable, too small, etc.), giving some behavioral insight. However, it does not state whether the operation is read-only, if authentication is needed, or any side effects. The description is adequate but not rich.

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 succinct: a main paragraph explaining the tool's purpose and features, followed by two short parameter descriptions. Every sentence adds value without redundancy. The key information is front-loaded.

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

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

For a tool with 2 parameters and no output schema, the description covers the purpose and arguments. However, it does not describe the return value structure beyond mentioning included diagnostic fields. The agent might need more detail on the output format to use the tool effectively, but it is passable.

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

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

Input schema has no descriptions (0% coverage), so the description adds meaningful semantics: it explains account_id with an example ('act_123456789') and clarifies limit as max audiences with a default. This compensates well 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?

Description clearly states the tool lists custom audiences for an ad account with additional information like type classification, size estimates, delivery status, and diagnostic warnings. It also flags problematic audiences. This verb+resource combination and the inclusion of diagnostic features distinguish it from sibling listing tools like get_accounts 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?

No explicit guidance on when to use this tool versus alternatives. However, the context of listing custom audiences is clear, and sibling tools are for different entities. The agent can infer usage from the domain, but the description lacks explicit when-to-use or when-not-to-use statements.

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

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

The description discloses the polling loop, default timing, and termination conditions (ready, failed, max attempts). However, it does not describe the return format, error handling, or side effects. With no annotations, this is adequate but not thorough.

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

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

The description is very concise with a clear structure: a one-line summary followed by parameter definitions in a list. No redundant information; every sentence adds value.

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

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

The description covers parameters and polling behavior adequately for basic usage. However, it lacks details about the return value (e.g., what 'ready' or 'failed' looks like) and does not specify error states or handling. Given no output schema, this is a notable gap.

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

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

All three parameters are explained with their purpose and defaults, including the equivalence of max_attempts to minutes. The schema itself has no descriptions (0% coverage), so the description fully compensates, adding essential meaning beyond the schema.

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

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

The description clearly states the tool polls video processing status until ready, failed, or max attempts. It uses a specific verb (poll) and resource (video processing status), distinguishing it from siblings like upload_video_asset or get_video_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 implies usage after upload_video_asset by mentioning 'video_id from upload_video_asset'. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. The context is implicit but not fully clear.

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

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

With no annotations provided, the description carries the full burden. 'Read' implies a non-destructive operation, and it mentions returning explicit blockers for missing files. However, it does not disclose authentication needs, rate limits, or other behavioral traits beyond the core functionality.

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 four sentences including the args. It is front-loaded with purpose and avoids unnecessary detail.

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

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

Given the tool has only two parameters and no output schema, the description provides sufficient context: purpose, auto-resolved items, blocker behavior, and parameter explanations. It could mention output format but is otherwise 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?

The description explains both parameters in detail: account_id is resolved to a client slug via registry, and include_context adds campaign history, assets, and constraints. This compensates fully for the 0% schema description 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 reads all client intelligence from the Obsidian vault for ad operations, specifying auto-resolved items like brand voice, ICPs, angles, objections, and profile IDs. It distinguishes itself from siblings which focus on ad accounts, campaigns, or creatives.

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

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

The description implies usage for ad operations but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No alternatives are named.

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

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

No annotations are provided, so the description bears full burden. It discloses the 3-step IG resolution process and fallback, which adds behavioral context. However, it does not mention potential errors, side effects, or authentication requirements.

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

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

The description is concise with two main sentences and a bullet list of arguments. It front-loads the purpose and resolution ladder, making it efficient to parse.

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

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

Given no output schema and low schema coverage, the description lacks details about the return format, error scenarios, or prerequisites. It explains the resolution logic well but is incomplete for an agent to fully understand what to expect.

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 meaning by explaining that account_id improves IG resolution, but does not describe formats or constraints beyond the schema's type hints.

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 resolves full identity for a Facebook Page including Instagram business account. It uses a specific verb 'resolve' and describes the output. However, it does not explicitly differentiate from sibling tools like get_account_pages or get_instagram_identities.

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 resolution ladder and fallback behavior but provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites or context for use.

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

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

With no annotations, the description carries the full burden. It discloses read-only behavior and that results are structured with pass/warn/fail and fix instructions. It could provide more detail on error handling or performance, but the transparency is good for a simple check 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 concise with two short paragraphs, front-loaded with the main purpose. Every sentence adds value: purpose, what is validated, return type, and read-only nature.

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

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

Given no parameters and no output schema, the description covers the essential aspects: what it checks, what it returns, and that it is read-only. However, it could mention prerequisites (e.g., required permissions) or whether it is safe to run multiple times, but it is adequate for a setup check.

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 no parameters, so the description cannot add parameter semantics. According to the rules, baseline is 4 for zero parameters. The description does not need to add further semantics.

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

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

The description clearly states it checks MCP setup readiness and returns structured results with pass/warn/fail and fix instructions. The verb 'check' and resource 'setup readiness' are specific and distinct from sibling tools like 'check_token_status' or 'diagnose_pixel_on_site'.

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 verifying setup before proceeding and states it is read-only. However, it does not explicitly mention when not to use it or provide alternatives among siblings, such as 'check_token_status' for a subset of checks.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool runs a diagnostic and returns results, but does not indicate whether it is read-only, destructive, or requires special permissions. The absence of side-effect disclosure is a significant 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 (about 60 words) and front-loaded with the main purpose. Every sentence is informative, with no redundant content. The Args section is appropriately separated.

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 high-level summary of the return type but lacks detailed structure or examples. Given no output schema, this is adequate for a diagnostic tool, but more specifics on the classification schema would enhance 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 adds meaning by explaining 'account_id' (with example) and 'archetype' (for requirement matching). However, it does not enumerate valid archetype values or clarify how they affect the diagnostic, leaving ambiguity.

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

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

The description clearly states the tool performs a comprehensive tracking diagnostic for an ad account, listing specific checks (pixels, event coverage, parameters, Meta flags) and output (health classification with issues and suggestions). This distinguishes it from sibling 'diagnose_pixel_on_site' which likely focuses on a single pixel.

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

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

No guidance is provided on when to use this tool versus alternatives like 'diagnose_pixel_on_site'. The description does not mention prerequisites, when not to use, or specific scenarios where this tool is preferred.

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 implies read-only behavior by describing search/list. Lacks details on output format, pagination, or 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?

Description is concise with one-line purpose, conditional usage, and parameter docs. 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 tool simplicity and absence of output schema, description covers purpose and parameter usage adequately. Could mention output structure but not critical.

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% coverage, but description adds meaning: query is optional search term, limit is max results with default 30. This compensates for missing schema documentation.

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

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

The description clearly states it searches or lists behavior-based targeting options, with a specific verb and resource. It distinguishes from sibling tools like search_demographics, search_geo_locations, and search_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?

Provides explicit usage pattern: if query provided, filter; otherwise list all. However, does not mention when to avoid this tool or compare with 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 provided, so description bears full burden. It explains the filtering and listing behavior, but does not mention side effects, authorization needs, or rate limits. However, as a read-only search tool, the description is sufficient.

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 brief: three sentences plus bulleted args. Purpose is front-loaded. No redundant or unnecessary 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 simple search tool with two parameters and no output schema, the description covers all necessary behavioral details. It explains when filtering occurs and what kind of data is returned.

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 clearly explains both parameters: query (optional search term with examples) and limit (default 30). Adds meaning beyond schema's 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?

Description uses specific verb 'Search or list' and clearly identifies the resource as 'demographic targeting options'. Lists example categories (life events, education, etc.), distinguishing it from sibling tools like search_interests or search_behaviors.

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

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

States behavior with and without query: 'If query is provided, filters by keyword. Otherwise returns all demographics.' Implicitly suggests usage for demographic targeting, but does not explicitly exclude other scenarios or compare 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 carries the full burden. It gives examples of query values and lists location types, but lacks information on whether the tool is read-only, authentication needs, or behavior on empty results.

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

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

The description is extremely concise, with two short sentences followed by an argument list. Every sentence adds value, and the purpose is front-loaded.

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

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

The description covers the basic purpose and parameters, but lacks information on the return format (no output schema) and any prerequisites or permissions. For a simple search tool, it is adequate but not 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?

The description adds significant meaning beyond the input schema, which has 0% coverage. It provides examples for query, lists valid location_type values, and explains limit as 'Max results (default 10)'.

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 searches for geographic locations for ad targeting, which distinguishes it from sibling tools like search_behaviors and search_demographics. However, it could be more explicit about the ad targeting context.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for geographic targeting but does not exclude other use cases or mention when not to use it.

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

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

No annotations provided; description indicates a read-only search and mentions returns but does not disclose side effects, auth needs, or rate limits. Adequate for a simple search but lacks explicit safety assurances.

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 (5 lines), front-loads the purpose, and every sentence contributes value. No redundancy or fluff.

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

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

Covers return values (audience size, category, path) and parameters. Lacks pagination or error info, but sufficient for a low-complexity search tool. Output schema absent, but return description is helpful.

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 clearly explains both parameters: query with examples and limit with default. Adds significant meaning beyond the schema's bare 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 the tool searches for interest-based targeting options, specifying verb+resource. It distinguishes from siblings like search_behaviors and search_demographics by focusing on 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 for interest targeting but does not explicitly contrast with siblings like get_interest_suggestions or provide 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 bears the full burden of behavioral disclosure. It mentions that test_event_code can be auto-generated and provides a custom_data example, but it omits side effects, error states, rate limits, or authentication requirements, which are important for safe usage.

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

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

The description is reasonably concise: one sentence for purpose followed by a parameter list. While clear, the 'Args' section could be more structured (e.g., as bullet points), but it avoids unnecessary verbosity.

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

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

Given no output schema and no annotations, the description covers purpose and parameters but lacks details on return values, error handling, and prerequisites (e.g., pixel_id must exist). It is adequate but leaves gaps for a tool with 4 parameters.

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% description coverage, so the description fully compensates by explaining each parameter: pixel_id (numeric string), event_name (default), test_event_code (auto-generates if missing), and custom_data (JSON string with example). This adds crucial 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's function: 'Send a test event via the Conversions API Test Events endpoint.' It distinguishes itself from sibling tools like get_pixel_events and diagnose_pixel_on_site by focusing on event sending rather than retrieval or diagnostics.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context for choosing this over other pixel-related tools, leaving the agent without decision support.

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

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

The description explicitly discloses behavioral traits: supervised write, pre-write snapshot, validation, post-write verification, and the creative swap behavior. Since no annotations are provided, the description fully carries the transparency burden, and it does so well.

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

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

The description is concise and well-structured, starting with the core purpose, followed by behavioral details, and ending with parameter descriptions. It is slightly verbose but not overly so; every sentence adds value.

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

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

Given the complexity of updating an ad via Meta API, the description covers key aspects: validation, rollback, and parameter nuances. It does not specify return values or error conditions, but with no output schema, this is acceptable. Overall, it is sufficiently 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?

With 0% schema description coverage, the description adds substantial meaning via an 'Args' section. It explains ad_id, name (naming enforcement), status (allowed values and activation nuance), and creative_id (requires existing creative, numeric format). This goes far 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 starts with 'Update an existing ad,' which clearly states the verb and resource. It distinguishes itself from sibling tools like update_ad_creative by focusing on the ad entity itself. The parameter descriptions further clarify the tool's 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 implicit guidance, such as the creative_id note explaining it re-points rather than creates a creative. However, it lacks explicit when-to-use or when-not-to-use comparisons with sibling tools like update_ad_creative or create_multi_asset_ad.

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

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

With no annotations provided, the description carries the full burden. It discloses that Meta API does not allow changing most creative fields, implying this tool only updates the name. Behavior is clearly limited to name updates. However, it does not mention permissions, error conditions, or side effects, which are minor omissions for a simple mutation.

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

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

The description is extremely concise: two short paragraphs and a bulleted arg list. It front-loads the main purpose, then the critical limitation, then the alternative, then args. 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?

Given the tool's simplicity (2 params, no output schema), the description is sufficiently complete. It explains what the tool does, its limitations, and its arguments. It could optionally mention the return value (e.g., success indicator), but this is not essential for a typical update 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?

The description adds meaning beyond the input schema by explicitly naming and describing each parameter: 'creative_id: Creative ID to update' and 'name: New creative name.' The schema only provides titles with no descriptions (coverage 0%), so the description fills that gap effectively.

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, distinguishing it from create_ad_creative and other siblings. The verb 'update' paired with the specific resource 'ad creative' and the scope 'name' leaves no ambiguity.

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 tells when to use this tool (to update name) and when not to (for changing copy, headline, CTA, or link URL). It provides a clear alternative: create a new creative and swap on the ad, thus preventing misuse.

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

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

No annotations are provided, so the description carries full burden. It clearly discloses the supervised write behavior with pre-write snapshot, validation, and post-verify. It also details budget enforcement and targeting merge rules, offering rich behavioral context beyond a simple update.

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 summary line, behavioral notes, and a detailed Args list. It is informative without being overly verbose, though the notes on budgets and targeting could be slightly streamlined. Overall, it earns its 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?

Given no output schema and 8 parameters, the description thoroughly covers the tool's behavior, budget rules, targeting semantics, and status transitions. It includes an example for targeting_json, making it complete for an update tool with complex constraints.

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 compensates fully. Each parameter in the Args section includes allowed values, constraints, and format examples (e.g., daily_budget 'Only allowed for ABO ad sets', targeting_json example). This adds significant meaning beyond the schema's type/optionality.

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

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

The description starts with 'Update an existing ad set,' clearly stating the verb and resource. It distinguishes itself from siblings like create_adset by specifying 'Supervised write - validates before applying,' making the purpose specific and 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 context on when to use (e.g., budget rules for ABO vs CBO, targeting partial updates) but does not explicitly mention when not to use or alternatives like create_adset. The sibling list includes update_campaign and create_adset, but the description lacks direct comparison, so a 4 is appropriate.

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 discloses behavioral traits: it describes the supervised write process, pre-write snapshot for rollback, validation, API application, and post-write verification. This is comprehensive and beyond minimal 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 well-structured with a short summary, process overview, and parameter list. Every sentence adds value, and the parameter details are clearly separated. It is concise yet thorough, earning its 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?

Given the complexity (8 parameters, no annotations, no output schema), the description is very complete for parameter semantics and process. However, it does not specify what the tool returns (e.g., updated campaign object or success confirmation), which would enhance completeness for an agent expecting a return value.

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

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

The description adds significant meaning beyond the input schema (which has 0% description coverage). It explains mutual exclusivity of daily_budget and lifetime_budget, allowed status values, activation validation, ISO 8601 format for times, and comma-separated special_ad_categories. This fully compensates for the absence of schema-level 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 'Update an existing campaign' as the primary function, with a specific verb and resource. It distinguishes from sibling tools like create_campaign or delete_campaign_structure by emphasizing it modifies an existing campaign.

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

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

The description implies the tool is for updating campaigns but does not explicitly state when to use it versus alternatives (e.g., use create_campaign for new campaigns, or delete for removal). No exclusion criteria or scenarios where this tool is inappropriate are mentioned.

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

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

No annotations provided, and description lacks behavioral details such as side effects, permissions, or what happens when optional parameters are omitted. For a mutation tool with no annotations, this is insufficient.

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

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

Description is short, with two sentences and a clear parameter list. 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 update operation with no output schema, the description adequately explains inputs but lacks usage context, behavioral notes, and alternative suggestions.

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

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

Description adds minimal meaning beyond schema: 'New name' and 'New filter rules as JSON string'. Schema coverage is 0%, so description compensates somewhat but does not explain filter_json format 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 action (update) and resource (product set), and specifies the updatable fields (name, filter rules). It distinguishes from sibling tools like create_product_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?

No guidance on when to use this tool versus alternatives (e.g., create_product_set for creation). No mention of prerequisites or conditions.

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 the process (downloads image, uploads via multipart) and return value (image hash). No contradictions detected.

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 headings and an args list. It is concise yet includes all essential details 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?

Despite no output schema, the description mentions the return value (image hash). It covers input constraints (formats, size) and the tool's role in the creative workflow, making it complete for an upload tool.

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

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

Schema coverage is 0%, but the description adds significant meaning: explains account_id format, that image_url must be public, and name defaults to filename. This fully compensates for lack of schema documentation.

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

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

The description clearly states the tool uploads an image from a URL into Meta's ad images library. It distinguishes itself from sibling tools like upload_video_asset by specifying image-related functionality.

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 that the returned image hash is needed for creative creation and ad building, implying when to use this tool. It also provides supported formats and max size, but does not explicitly mention when not to use it or alternatives.

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

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

With no annotations, the description discloses file validation, size limit, and that video enters processing post-upload. While it lacks details on auth requirements or error handling, it provides adequate 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 concise and well-structured: a clear summary paragraph followed by a bulleted arg list. Every sentence adds value without repetition.

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

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

Given the complexity and lack of output schema, the description covers validation, size limits, processing steps, and return value. It also references poll_video_processing, making it contextually complete for an upload tool.

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

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

Schema description coverage is 0%, but the description lists all parameters with examples (e.g., 'act_123456789' for account_id) and notes optionality, adding meaning beyond the schema.

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

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

The description clearly states the tool uploads a local video file to a Meta ad account, specifying validation, size limit (<1GB), and return of meta_video_id. It differentiates from sibling tools like upload_video_resumable and poll_video_processing.

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 for when to use this tool (files <1GB) and mentions poll_video_processing for checking readiness. It implies that upload_video_resumable is for larger files, offering clear usage guidance.

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