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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'duplicate' implies a write operation, it doesn't clarify permissions needed, whether it's idempotent, rate limits, or what happens to the original ad. For a mutation tool with zero annotation coverage, this is inadequate—it should describe more about the cloning process and outcomes.

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

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

The description is a single, efficient sentence that gets straight to the point. It avoids unnecessary words and doesn't repeat the tool name. However, it could be more front-loaded with critical details (e.g., 'Creates a copy of an existing ad...'), but as-is, it's appropriately 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?

Given the complexity (7 parameters, mutation operation, no annotations) and the presence of an output schema, the description is minimally adequate. The output schema likely covers return values, reducing the need for that in the description. However, for a tool that duplicates ads, more context on behavior, parameters, and usage relative to siblings would improve completeness.

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

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

Schema description coverage is 0%, meaning parameter titles are generic (e.g., 'Ad Id', 'Target Ad Set Id'). The description adds no semantic context about parameters—it doesn't explain what 'ad_id' refers to, how 'name_suffix' is applied, or what 'new_status' options exist. With 7 parameters, this leaves the agent guessing about their meanings and usage.

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

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

The description clearly states the tool's purpose: 'Duplicate an ad using Meta's local Graph copy edge.' It specifies the verb ('duplicate') and resource ('an ad'), and mentions the underlying mechanism ('Meta's local Graph copy edge'). However, it doesn't explicitly differentiate from sibling tools like 'clone_ad_creative' or 'clone_ad_set', which would require a 5.

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 doesn't mention when to choose 'clone_ad' over 'create_ad' or 'update_ad', nor does it specify prerequisites or exclusions. With many sibling tools available (e.g., create_ad, update_ad, clone_ad_creative), this lack of context is a significant 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?

No annotations are provided, so the description carries full burden. While 'Duplicate' implies a write operation, it doesn't disclose behavioral traits like whether this requires specific permissions, if it's rate-limited, what happens to the original creative, whether the duplication is immediate or asynchronous, or what authentication is needed beyond the access token parameter. The mention of 'Meta's local Graph copy edge' is technical but doesn't clarify practical implications.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with a clear primary function, though the lack of additional context means it may be too brief rather than optimally 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?

For a mutation tool with 8 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is inadequate. It doesn't explain what the tool returns, what errors might occur, or provide usage context. While the output schema may document return values, the description should still cover behavioral aspects and parameter semantics that aren't captured elsewhere.

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 and 8 parameters (7 optional), the description adds no parameter information beyond what's in the schema. It doesn't explain what 'ad_creative_id' should be, how the suffix is applied, what fields can be overridden, or the purpose of the access token. The schema documents parameter names and types, but the description provides no additional semantic 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 clearly states the action ('Duplicate a creative') and the resource ('creative'), and mentions the implementation method ('using Meta's local Graph copy edge'). It distinguishes from siblings like 'create_ad_creative' by focusing on duplication rather than creation from scratch. However, it doesn't explicitly contrast with other clone tools like 'clone_ad' or 'clone_ad_set'.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools including 'create_ad_creative', 'update_ad_creative', and other clone operations, there's no indication of prerequisites, appropriate contexts, or when this specific duplication method is preferred over creating a new creative from scratch.

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 for behavioral disclosure. While 'Duplicate' implies a write operation, it doesn't mention permissions required, whether the original is affected, rate limits, error conditions, or what happens with the 8 optional parameters. The mention of 'Meta's local Graph copy edge' adds some technical context but not enough operational guidance.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool description and gets straight to the point without unnecessary elaboration.

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

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

Given the complexity (9 parameters, mutation operation) and complete lack of annotations, the description is insufficient. While an output schema exists (which helps), the description doesn't address the mutation nature, parameter interactions, or sibling tool differentiation needed for a complex cloning operation. It's minimally adequate but with significant 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 for 9 parameters (1 required, 8 optional), the description provides no information about any parameters. It doesn't explain what 'ad_set_id' should be, what 'new_targeting' object should contain, what 'new_status' values are valid, or how parameters like 'include_ads' and 'include_creatives' affect the duplication. The description fails to compensate for the complete 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 action ('Duplicate') and resource ('an ad set'), and mentions the specific technical implementation ('using Meta's local Graph copy edge'). However, it doesn't explicitly differentiate this tool from its sibling 'clone_campaign' or 'clone_ad', which would be needed for a perfect score.

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 like 'create_ad_set' or 'update_ad_set'. With multiple sibling cloning tools present (clone_ad, clone_ad_creative, clone_campaign), the lack of differentiation is a significant gap in usage 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 full burden but only states the basic action. It doesn't disclose behavioral traits like required permissions, rate limits, whether it's idempotent, what happens on failure, or how the copy edge works. 'Duplicate' implies a write operation, but no safety or side-effect details are 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, efficient sentence with no wasted words. It's front-loaded with the core action and technical context, making it easy to parse despite lacking detail.

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

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

For a 9-parameter mutation tool with no annotations and 0% schema description coverage, the description is inadequate. It doesn't explain the cloning behavior, what gets copied by default, how authentication works via meta_access_token, or what the output contains (though an output schema exists). The technical mention of 'Meta's local Graph copy edge' adds some context but doesn't compensate for missing operational details.

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

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

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what campaign_id refers to, the purpose of include_* flags, how name_suffix is applied, or the implications of copy_schedule and new_status. The description provides zero parameter semantics beyond what's in 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 clearly states the verb ('Duplicate') and resource ('a campaign'), specifying it uses Meta's local Graph copy edge. It distinguishes from create_campaign by indicating duplication rather than creation from scratch, though it doesn't explicitly contrast with other clone_* tools.

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

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

No guidance is provided on when to use this tool versus alternatives like create_campaign or other clone_* tools. The description mentions the technical mechanism but offers no contextual usage advice, prerequisites, 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention required permissions, whether it's idempotent, what happens on failure, rate limits, or what the output contains. For a complex mutation tool with 19 parameters, this leaves critical behavioral aspects undocumented.

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, focused sentence with no wasted words. It's appropriately sized for a basic purpose statement, though it lacks the additional context needed for such a complex tool.

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

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

For a creation tool with 19 parameters, 0% schema description coverage, no annotations, and complex advertising domain context, the description is severely incomplete. While an output schema exists (which helps with return values), the description doesn't address critical aspects like parameter meanings, usage context, behavioral expectations, or how this tool relates to siblings in the advertising hierarchy.

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%, meaning none of the 19 parameters have descriptions in the schema. The tool description provides no information about any parameters—not even the required ones like 'ad_account_id', 'campaign_id', or 'name'. This leaves the agent with no semantic understanding of what values to provide for any parameter.

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

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

The description clearly states the action ('Create') and resource ('an ad set under a campaign'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_ad' or 'create_campaign', which would require specifying what distinguishes an ad set from those other 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?

The description provides no guidance on when to use this tool versus alternatives like 'clone_ad_set' or 'update_ad_set'. It mentions the parent relationship ('under a campaign') but doesn't specify prerequisites, constraints, or typical use cases for creating an ad set versus other advertising entities.

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 for behavioral disclosure. It states this is a creation tool (implying a write/mutation operation) but doesn't mention required permissions, rate limits, side effects, or what happens upon success/failure. The mention of 'optional budgeting and bid controls' hints at configuration options but lacks operational 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 a single, efficient sentence that gets straight to the point. It's appropriately sized for a basic tool description, though it could be more front-loaded with critical information given the complexity of the tool.

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

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

For a 15-parameter mutation tool with no annotations and 0% schema description coverage, this description is inadequate. While an output schema exists (which helps with return values), the description fails to provide necessary context about the tool's behavior, parameter meanings, usage scenarios, or differentiation from sibling tools. It doesn't compensate for the lack of structured documentation.

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 all 15 parameters are undocumented in the schema. The description only mentions 'optional budgeting and bid controls', which covers perhaps 4-5 parameters at most (daily_budget, lifetime_budget, bid_strategy, bid_cap, spend_cap). It doesn't explain critical required parameters like ad_account_id, name, objective, or other important ones like status, special_ad_categories, or campaign_budget_optimization.

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

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

The description clearly states the action ('Create') and resource ('campaign'), and specifies optional budgeting and bid controls. However, it doesn't differentiate this from sibling tools like 'clone_campaign' or 'update_campaign', which would require explicit comparison.

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 about when to use this tool versus alternatives like 'clone_campaign' or 'update_campaign'. The description mentions optional budgeting and bid controls but doesn't explain prerequisites, constraints, or typical use cases for campaign creation.

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 but offers minimal behavioral insight. It implies a write operation ('create') but doesn't disclose permissions needed, rate limits, whether the schedule is reversible, or what happens upon success/failure. This is inadequate for a mutation tool.

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

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

The description is a single, efficient sentence with no wasted words. However, it's overly concise given the tool's complexity—front-loaded but lacking necessary detail for a 6-parameter mutation tool.

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

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

For a mutation tool with 6 parameters, 0% schema coverage, no annotations, and sibling tools present, the description is incomplete. It doesn't clarify the tool's role in the ecosystem, behavioral expectations, or parameter meanings, despite an output schema existing.

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 but adds no parameter details. It doesn't explain what 'budget_value_type' means, the format of 'time_start'/'time_end', or the purpose of 'meta_access_token'. This leaves all 6 parameters poorly understood.

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 the action ('create') and resource ('high-demand budget schedule for a campaign'), which is clear but vague. It doesn't specify what makes a schedule 'high-demand' or differentiate from sibling tools like 'create_campaign' or 'update_campaign' that might also involve budgets.

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 is provided. There's no mention of prerequisites, timing considerations, or how this relates to sibling tools like 'create_campaign' or 'update_campaign' that might handle budgets differently.

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 but offers minimal behavioral insight. It mentions 'Generate... reports' which implies a read-only operation, but doesn't disclose authentication needs (though 'meta_access_token' parameter hints at this), rate limits, whether it's synchronous/asynchronous, or what the output contains beyond 'reports'. More context on the tool's behavior is needed.

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

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

The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a tool name like 'create_report', though it could be more informative given the complexity.

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

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

Given the tool's complexity (12 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is inadequate. It doesn't explain parameter usage, behavioral traits, or how it differs from siblings. While the output schema might cover return values, the description lacks essential context for proper tool selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't explain any of the 12 parameters, such as what 'OSS-local' means, valid values for 'report_type' or 'export_format', or how 'date_range' should be formatted. The description adds no parameter semantics beyond what's inferred from parameter 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 action ('Generate') and resource ('OSS-local performance reports for Meta Ads accounts/campaigns'), making the purpose understandable. However, it doesn't explicitly differentiate this reporting tool from other reporting-related tools like 'list_insights' or 'search_ads_archive', which might offer similar data in different formats.

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. The description doesn't mention prerequisites, such as needing a Meta Ads account, or compare it to other tools that might retrieve similar data (e.g., 'list_insights' for raw data vs. this for formatted reports).

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 of behavioral disclosure. It mentions 'deprecated interest-list mode,' which hints at legacy functionality, but doesn't describe key behaviors: whether this is a read-only estimation, if it requires authentication (implied by 'meta_access_token' but not stated), rate limits, or what the output contains. For a tool with 6 parameters and no annotations, this leaves significant gaps in understanding how it operates.

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

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

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's use cases.

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 (6 parameters, no annotations, but an output schema exists), the description is incomplete. The output schema means return values don't need explanation, but the description lacks details on authentication needs, parameter interactions, and behavioral traits. It covers basic purpose but misses critical context for effective use, especially with undocumented 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?

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds minimal semantics: it implies 'targeting' and 'interest_list' are used for estimation, and 'interest_list' is deprecated. However, it doesn't explain the purpose of other parameters like 'meta_access_token', 'ad_account_id', 'optimization_goal', or 'interest_fbid_list', nor their relationships. With 6 parameters, the description fails to compensate for the 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's purpose: 'Estimate audience size for targeting specs or validate deprecated interest-list mode.' It specifies the verb ('estimate') and resource ('audience size'), and distinguishes between two use cases. However, it doesn't explicitly differentiate from sibling tools like 'search_demographics' or 'suggest_interests' that might also relate to audience analysis.

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

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

The description implies usage by mentioning two modes: 'for targeting specs' and 'validate deprecated interest-list mode.' This provides some context on when to use the tool, but it doesn't offer explicit guidance on when to choose this over alternatives (e.g., vs. 'search_demographics' for audience insights) or prerequisites like required parameters. The guidance is present but not comprehensive.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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, so the description carries full burden. It mentions visibility to a user context, hinting at access control, but fails to disclose key behaviors like pagination (implied by parameters), rate limits, authentication needs, or response format. This leaves significant gaps for a tool with 4 parameters and an output schema.

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

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

The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for its purpose, making it highly concise 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?

Given 4 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the basic purpose but lacks parameter explanations, usage context, and behavioral details, making it minimally adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It adds no meaning beyond the schema, failing to explain parameters like 'meta_access_token' (authentication), 'meta_user_id' (default 'me'), 'page_size', or 'page_cursor' (pagination). This inadequately addresses the coverage gap.

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

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

The description clearly states the verb ('List') and resource ('ad accounts'), specifying the scope as 'visible to a user context.' It distinguishes from siblings like 'read_ad_account' (singular read) but doesn't explicitly differentiate from other list tools (e.g., 'list_ads'), making it a 4 rather than a 5.

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 like 'read_ad_account' or other list tools. It lacks prerequisites, exclusions, or context for selection, offering only a basic functional statement.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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, so the description carries full burden. It doesn't disclose behavioral traits like pagination (implied by page_size and page_cursor parameters but not explained), rate limits, authentication requirements (meta_access_token is in schema but not mentioned), or whether it's a read-only operation. The description is minimal and lacks critical operational 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?

Extremely concise with a single sentence that front-loads the core purpose. No wasted words or redundant information, making it easy to parse quickly.

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

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

Given 5 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It lacks details on parameter usage, authentication, pagination behavior, and when to use versus siblings, making it inadequate for a tool with this complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'under an account or campaign' which hints at ad_account_id and campaign_id, but doesn't explain their relationship, defaults, or other parameters like page_size, page_cursor, or meta_access_token. The description adds minimal value beyond the schema's parameter 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 action ('List') and resource ('ad sets'), specifying they can be under an account or campaign. It distinguishes from other list tools like list_ads or list_campaigns by focusing on ad sets, but doesn't explicitly differentiate from read_ad_set (which might fetch a single ad set).

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

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

No guidance on when to use this tool versus alternatives like search_ads_archive or read_ad_set. It mentions 'under an account or campaign' but doesn't clarify if both can be specified or if one takes precedence, nor does it mention prerequisites like authentication.

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 for behavioral disclosure. It mentions 'optional filters' but doesn't describe pagination behavior (implied by page_size and page_cursor parameters), rate limits, authentication requirements, or what happens when filters are applied. The description is minimal and lacks important operational 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 a single, efficient sentence with zero waste. It's appropriately sized for a list operation and front-loads the core purpose. Every word earns its place.

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

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

Given 6 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks guidance on parameter usage, behavioral traits, and differentiation from siblings. The output schema reduces the need to describe return values, but other gaps remain significant.

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 but only mentions 'optional filters' without explaining which parameters are filters or their purposes. It doesn't clarify the relationship between ad_account_id and meta_access_token, or explain filter syntax/values. The description adds minimal value beyond what parameter names suggest.

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

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

The description clearly states the verb 'List' and resource 'campaigns' with the scope 'for an ad account'. It distinguishes from other list tools by specifying campaigns, but doesn't explicitly differentiate from other campaign-related tools like 'read_campaign' or 'search_ads_archive'.

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

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

The description mentions 'optional filters' which implies some usage context, but provides no guidance on when to use this tool versus alternatives like 'search_ads_archive' or 'read_campaign'. No prerequisites, exclusions, or comparison with sibling tools 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Fetch insights' implies a read operation, but it doesn't specify permissions needed, rate limits, pagination behavior (though page_size and page_cursor parameters exist), or what format the insights come in. The description is too vague about what 'insights' actually means in this 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 a single, efficient sentence with no wasted words. It's appropriately sized for what it communicates, though what it communicates is insufficient. The structure is front-loaded with the core action and target.

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, 0% schema description coverage, no annotations, and complex sibling relationships, the description is severely incomplete. While an output schema exists (which helps with return values), the description doesn't address parameter meanings, usage context, behavioral constraints, or differentiation from alternatives. It leaves too many questions unanswered for effective tool selection and invocation.

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

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

With 12 parameters and 0% schema description coverage, the description provides no information about any parameters. It doesn't explain what 'object_id' refers to, what 'date_range' options exist, what 'breakdown' means, or how any parameters interact. The description fails to compensate for the complete lack of parameter documentation in the schema.

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

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

The description clearly states the action ('Fetch insights') and the target resources ('for an account, campaign, ad set, or ad'), making the purpose understandable. However, it doesn't distinguish this tool from other list/search tools on the server (like list_ads, list_campaigns, etc.), which would require explicit differentiation to earn a 5.

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. With many sibling tools available (e.g., list_ads, list_campaigns, search_ads_archive), there's no indication of when insights fetching is preferred over other listing operations or what specific insights it provides that other tools don't.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns metadata but does not specify details like response format, error handling, authentication requirements (beyond the optional token parameter), rate limits, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves.

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, direct sentence with no wasted words, making it highly concise and front-loaded. It immediately conveys the core function without unnecessary elaboration, which is efficient 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 has an output schema (which should cover return values) and no annotations, the description is minimally adequate for a simple read operation. However, it lacks details on usage context, parameter meanings, and behavioral traits, making it incomplete for effective agent use without additional inference or trial.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'account metadata' but does not explain what 'ad_account_id' represents (e.g., format, source) or the purpose of 'meta_access_token' (e.g., when it's required, how to obtain it). This fails to add meaningful context beyond the bare schema.

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

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

The description clearly states the action ('Return') and resource ('account metadata for a single ad account'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'list_ad_accounts' or 'read_ad', which also retrieve ad account data, leaving room for ambiguity in tool selection.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'list_ad_accounts' for multiple accounts or other 'read_' tools for different resources. It lacks context on prerequisites, like when 'meta_access_token' is needed, or exclusions, making it insufficient for informed tool selection.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Fetch full details,' implying a read-only operation, but doesn't specify authentication needs (e.g., the meta_access_token parameter), rate limits, error conditions, or what 'full details' entails. This leaves significant gaps for a tool that likely interacts with an external API.

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

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

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is incomplete. It lacks parameter explanations and behavioral details, though the output schema may cover return values. For a read operation in a sibling-rich environment, more context on usage and parameters would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't mention any parameters, failing to explain the required 'ad_set_id' or optional 'meta_access_token'. This leaves the agent without semantic context for the two parameters, beyond what the schema's titles minimally suggest.

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 ('Fetch full details') and resource ('for one ad set'), making the purpose specific and understandable. However, it doesn't differentiate this tool from similar siblings like 'read_ad' or 'read_ad_creative', which follow the same pattern for different resource types.

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 doesn't mention prerequisites (e.g., needing an ad set ID), exclusions, or comparisons to siblings like 'list_ad_sets' for multiple items or 'update_ad_set' for modifications, leaving the agent to infer usage from context 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Fetch detailed campaign metadata') without revealing any behavioral traits such as whether it's read-only, requires authentication (implied by meta_access_token parameter but not explained), rate limits, error handling, or what 'detailed metadata' entails. This leaves critical operational aspects undocumented.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to stating the tool's purpose.

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

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

Given the tool has an output schema (which should define return values), the description's minimalism is somewhat acceptable. However, with no annotations, 0% schema description coverage, and 2 parameters, the description lacks crucial context like authentication needs, error cases, and parameter semantics. It's incomplete for a tool that likely involves API calls and sensitive data, but the output schema mitigates 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?

Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no information about parameters, failing to explain what 'campaign_id' is (e.g., a unique identifier) or the purpose of 'meta_access_token' (e.g., for authentication). With 2 parameters and no compensation in the description, this is a significant gap in understanding how to invoke the tool correctly.

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 ('Fetch') and resource ('detailed campaign metadata'), making the purpose understandable. It distinguishes from siblings like 'list_campaigns' (which lists multiple campaigns) and 'update_campaign' (which modifies campaigns). However, it doesn't explicitly mention it retrieves a single campaign by ID, which could be slightly more specific.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a campaign_id), contrast with 'list_campaigns' for multiple campaigns, or specify use cases like viewing campaign details before editing. Without such context, the agent must infer usage from the tool name and schema 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about 'cache-first + API fallback behavior', which hints at performance characteristics and error handling, but doesn't cover critical aspects like authentication needs, rate limits, or what happens on failures. It's not misleading, but incomplete for a tool with potential network interactions.

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

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

The description is a single, efficient sentence that front-loads the core purpose. There's no wasted text, but it could be slightly more structured by separating behavioral details. It's appropriately sized for a simple tool.

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

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

Given the tool has 1 parameter with no schema descriptions, no annotations, and an output schema exists (which reduces the need to explain return values), the description is moderately complete. It covers the basic action and a behavioral trait, but lacks details on parameter usage, error cases, or integration with siblings, leaving room for improvement in guiding the agent.

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

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

The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic details. The description adds minimal meaning by implying 'resource_id' is used to fetch 'complete record data', but doesn't explain the ID format, scope, or examples. It partially compensates for the low schema coverage but leaves significant gaps.

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

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

The description states the tool 'fetch[es] complete record data by ID' which clarifies the verb (fetch) and resource (record data), but it's vague about what 'record data' refers to—web content, ads, or something else—and doesn't distinguish it from sibling tools like 'search_web_content' or 'read_ad'. It's not tautological, but lacks specificity for differentiation.

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 'cache-first + API fallback behavior', which implies a performance or reliability context, but provides no explicit guidance on when to use this tool versus alternatives like 'search_web_content' or other 'read_' tools. There's no mention of prerequisites, exclusions, or comparative use 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Meta's public Ads Library endpoint' which hints at an external API, but doesn't disclose authentication requirements (despite the meta_access_token parameter), rate limits, pagination behavior (though page_size and page_cursor parameters exist), or what kind of data is returned. The description is minimal and leaves critical behavioral aspects unexplained.

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 - a single sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action and target. Every word earns its place, making it maximally efficient within its limited scope.

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 (7 parameters, 2 required), complete lack of schema descriptions, and no annotations, the description is inadequate. While an output schema exists (which relieves the description from explaining return values), the description doesn't address authentication needs, parameter meanings, usage context, or behavioral constraints. For a search tool with multiple parameters and external API integration, this leaves too many gaps for effective agent 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 for all 7 parameters, the description provides no parameter information whatsoever. It doesn't explain what 'search_terms' should contain, what 'ad_reached_countries' expects, what the 'meta_access_token' is for, what 'ad_type' options exist, how pagination works with 'page_size' and 'page_cursor', or what 'fields' controls. The description fails to compensate for the complete 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 action ('Search ads') and target resource ('Meta's public Ads Library endpoint'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling search tools like 'search_behaviors', 'search_demographics', or 'search_pages', which all search different aspects of the Meta ecosystem.

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 about when to use this tool versus alternatives. There's no mention of when this search is appropriate compared to other search tools (like search_pages or search_interests) or when to use it versus listing tools (like list_ads). No prerequisites, exclusions, or contextual boundaries 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?

No annotations are provided, so the description carries full burden but offers minimal behavioral insight. It mentions 'search' but doesn't disclose if this is read-only, requires authentication (implied by meta_access_token parameter), has rate limits, or what the output entails. The description lacks critical operational 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 a single, efficient sentence with no wasted words, making it appropriately concise. However, it's under-specified rather than optimally structured, as it lacks front-loaded detail that would aid 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 has 3 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It fails to explain the tool's role in the context of sibling search tools or provide necessary usage context, making it inadequate for effective agent use.

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

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

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'behavior-based targeting categories' are, how to search them, or the role of parameters like meta_access_token, page_size, and page_cursor, leaving semantics unclear.

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 'Search behavior-based targeting categories' restates the tool name 'search_behaviors' with minimal elaboration, making it tautological. It doesn't specify what resource is being searched (e.g., Facebook/Meta advertising behaviors) or how results are structured, though it implies targeting categories related to 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?

No guidance is provided on when to use this tool versus alternatives. Given sibling tools like 'search_demographics', 'search_interests', and 'search_geo_locations', it's unclear if this is for complementary targeting data or overlaps with them, leaving usage ambiguous.

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 for behavioral disclosure. 'Search' implies a read-only operation, but the description doesn't mention authentication requirements (though meta_access_token parameter hints at this), rate limits, pagination behavior (though page_size and page_cursor parameters exist), or what the search returns. It provides minimal behavioral context beyond the basic operation type.

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, focused sentence with zero wasted words. It's appropriately sized for a search operation and front-loads the essential information. Every word earns its place in this minimal description.

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

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

Given that an output schema exists (which should document return values), the description's minimalism is somewhat acceptable. However, for a search tool with 4 parameters and no annotations, the description should provide more context about authentication, pagination behavior, and what constitutes a 'demographic targeting class' to be truly complete.

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

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

With 0% schema description coverage for 4 parameters, the description provides no parameter information whatsoever. It doesn't explain what demographic_class represents, how meta_access_token should be obtained or used, or how pagination works with page_size and page_cursor. The description fails to compensate for the complete 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 'Search demographic targeting classes' clearly indicates a search operation targeting demographic classes, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like search_behaviors, search_interests, or search_geo_locations that appear to perform similar search operations for different targeting categories.

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. There's no mention of prerequisites, when this search is appropriate, or how it differs from other search tools in the sibling list. The agent must infer usage from the tool name 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?

No annotations are provided, so the description carries full burden. It mentions 'search' but doesn't disclose behavioral traits like whether this is a read-only operation, requires authentication (though meta_access_token parameter hints at it), rate limits, pagination behavior (implied by page_size/page_cursor but not explained), or what 'targeting' entails. The description adds minimal context beyond the basic action.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though this conciseness comes at the cost of detail. Every word earns its place, making it structurally sound.

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

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

Given the tool's complexity (5 parameters, 1 required), lack of annotations, and 0% schema coverage, the description is incomplete. An output schema exists, so return values needn't be explained, but the description doesn't cover authentication needs, pagination, or targeting context. For a search tool with multiple parameters and no annotation support, this is inadequate.

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 doesn't explain any parameters—not what the 'query' should contain, what 'location_types' are, how pagination works, or the role of 'meta_access_token'. The description adds no meaning beyond what the bare schema provides, failing to address the coverage gap.

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

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

The description states the tool searches for 'geo-location entities for targeting', which provides a general purpose. However, it lacks specificity about what 'geo-location entities' are (e.g., cities, regions, coordinates) and doesn't distinguish this search tool from other search siblings like search_ads_archive or search_interests. The verb 'search' is clear but the resource scope is vague.

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. The description doesn't mention prerequisites, context (e.g., for ad targeting), or exclusions. With many sibling tools including other search functions, this omission leaves the agent without direction on appropriate use 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?

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention authentication needs (though 'meta_access_token' parameter hints at it), rate limits, pagination behavior (implied by 'page_size' and 'page_cursor' but not explained), or what 'find' entails (e.g., search algorithm, result format). This is inadequate for a tool with parameters and no annotation coverage.

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

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

The description is a single, efficient sentence with zero waste—every word contributes to the core purpose. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the tool has 4 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It doesn't provide enough context about behavior, parameters, or usage to compensate for the lack of annotations and schema descriptions, though the output schema mitigates some need for return value explanation.

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 but adds no parameter information beyond implying 'keyword' relates to 'query'. It doesn't explain 'meta_access_token', 'page_size', or 'page_cursor', leaving all 4 parameters with minimal semantic context. The description fails to bridge the coverage gap.

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

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

The description 'Find audience interests by keyword' clearly states the action (find) and target resource (audience interests), but it's vague about scope and doesn't distinguish from sibling tools like 'suggest_interests' or 'search_behaviors'. It provides basic purpose but lacks specificity about what 'interests' means in this 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?

No guidance is provided about when to use this tool versus alternatives like 'suggest_interests' or other search tools in the sibling list. The description doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage differentiation.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching and returning 'matching record IDs', which implies a read-only operation, but fails to detail critical aspects like authentication requirements (implied by 'meta_access_token' parameter), rate limits, pagination, or error handling. This leaves significant gaps for a tool interacting with external APIs.

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

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

The description is a single, efficient sentence with no wasted words, clearly front-loading the core purpose. It is appropriately sized for a simple search tool, making it easy to parse quickly.

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 moderate complexity (2 parameters, external API interaction) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and low schema coverage, it lacks crucial context like authentication, search scope, and behavioral traits, making it incomplete for safe and effective use.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain the 'query' parameter's format or semantics (e.g., search syntax, fields searched) or the 'meta_access_token' usage (e.g., when required, how to obtain it). The description adds no meaningful details beyond what the bare schema provides.

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

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

The description clearly states the verb ('Search through') and resource ('Meta Ads data'), specifying the action and target. It distinguishes from siblings like 'search_ads_archive' or 'search_pages' by focusing on 'web content', though it doesn't explicitly contrast them. However, it's not fully specific about what 'web content' entails compared to other search tools.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'search_ads_archive' or 'search_pages', nor does it mention prerequisites such as authentication needs. It lacks explicit context for selection among the many search-related 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 of behavioral disclosure. It mentions 'Fetch related interests' but doesn't specify whether this is a read-only operation, requires authentication (implied by 'meta_access_token' parameter), involves rate limits, or describes the output format. This leaves significant gaps in understanding the tool's behavior.

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

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

The description is a single, efficient sentence with no wasted words, making it easy to parse and front-loaded with the core purpose. It earns its place by being direct and to the point.

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

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

Given the tool has 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It doesn't explain parameter meanings or behavioral traits, though the output schema may cover return values. This results in a minimal viable but gap-filled description.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only vaguely references 'a base list of interests' for 'interest_list', but doesn't explain the semantics of 'meta_access_token', 'page_size', or 'page_cursor', nor does it clarify the relationship between parameters. This fails to add meaningful context beyond the bare schema.

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

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

The description clearly states the action ('Fetch related interests') and the resource ('from a base list of interests'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'search_interests', which might have overlapping functionality, so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'search_interests' or other sibling tools. It lacks context about prerequisites, use cases, or exclusions, leaving the agent without clear usage instructions.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no 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, so the description carries the full burden of behavioral disclosure. It mentions 'Update' which implies a mutation, but fails to describe critical aspects like required permissions, whether changes are reversible, rate limits, or response behavior. This leaves significant gaps for an agent to understand how to use it safely and effectively.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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 (12 parameters, mutation operation) and lack of annotations, the description is insufficient. It doesn't cover behavioral traits, parameter details, or usage context. While an output schema exists, the description should still address critical aspects like side effects or prerequisites, which it omits.

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 12 parameters and 0% schema description coverage, the schema provides only titles and types without explanations. The description lists general categories ('delivery, budgeting, and targeting configuration') but doesn't clarify individual parameters like 'bid_strategy' or 'optimization_goal', nor does it explain relationships or constraints, failing to compensate for the low schema coverage.

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

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

The description clearly states the action ('Update') and the resource ('an ad set's delivery, budgeting, and targeting configuration'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from its sibling 'update_ad' or 'update_campaign', which would be needed for a score of 5.

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 like 'update_ad' or 'update_campaign', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios 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?

With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified settings. For a mutation tool with 13 parameters, this is a significant gap in 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 a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, stating the core purpose immediately without unnecessary elaboration.

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 (13 parameters, mutation operation) and lack of annotations, the description is incomplete. While an output schema exists (which helps), the description doesn't address key contextual aspects like parameter meanings, usage scenarios, or behavioral implications, leaving significant gaps for an AI agent.

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

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

Schema description coverage is 0%, so parameters are undocumented in the schema. The description adds no information about any parameters—it doesn't mention which settings can be updated, what 'campaign_id' refers to, or the meaning of fields like 'bid_strategy' or 'objective'. This fails to compensate for the schema gap.

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

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

The description clearly states the verb ('Update') and resource ('campaign settings for an existing campaign'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'update_ad' or 'update_ad_set', which also update advertising resources, so it doesn't achieve full differentiation.

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 doesn't mention prerequisites (e.g., needing an existing campaign ID), exclusions, or comparisons to sibling tools like 'create_campaign' or other update tools in the list.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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