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

No annotations provided, but the description discloses the default PAUSED status and the DCO-bypass pattern. However, it does not mention idempotency, permissions, or error behavior, which is partially compensated by the presence of 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?

Two sentences, no wasted words. The first sentence states the action, the second provides crucial workflow details and default. Highly concise and front-loaded.

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

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

Given 5 parameters and no schema documentation, the description covers the unique DCO-bypass flow and default status. However, it does not explain how to obtain required params like 'adset_id' or 'account_id', or what the output contains, though an output schema is present.

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 add meaning. It adds context for 'creative_id' (as PLACEHOLDER) and 'status' (default PAUSED), but other parameters (name, adset_id, account_id) lack explanation, leaving gaps for an agent.

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

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

The description states 'Create an ad.' with a clear verb and resource. It also specifies a unique workflow (DCO-bypass) and default status, distinguishing it from siblings like update_ad.

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

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

Explicitly indicates when to use this tool: for the DCO-bypass flow, pass a PLACEHOLDER creative_id and then call update_ad. Also mentions the default PAUSED status, providing clear guidance on usage.

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

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

No annotations provided, so description carries full burden. It details the two modes and their resulting spec types (asset_feed_spec vs object_story_spec), how Meta displays them, and important constraints like video_id origin and image URL expiration. Minor lack of explanation on other behavioral aspects like error scenarios.

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

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

Concise with clear structure: short intro, two paragraphs for modes, and a final paragraph for important notes. Uses bullet-like formatting and bold for emphasis. No redundant sentences.

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?

Output schema exists (not shown) but description doesn't mention return value. Explains modes well but doesn't clarify required params (page_id, link_url) or the significance of other params. Adequate but gaps remain for a tool with 12 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%, so description adds value for some parameters (video_id, image_url, messages/headlines/descriptions arrays vs strings) but leaves many parameters unexplained (e.g., account_id, call_to_action_type, link_url, page_id, name). Partially compensates but not fully.

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

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

Clearly states it creates an ad creative from an ad-account-scoped video. Explains two modes (multi-variant and single-variant) and distinguishes from sibling tools like update_ad and upload_video by referencing flow steps.

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

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

Provides explicit guidance on when to use each mode (step 2 vs step 4 of the flow). Warns about video_id source (must be from upload_video, not page-uploaded) and image_url expiration, suggesting get_video_thumbnail as alternative.

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

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

With no annotations, the description fully carries the transparency burden. It reveals that advantage_audience is forced OFF, budget is in cents, and targeting expects a specific Meta dict structure. This goes beyond a simple 'create' statement, though it doesn't cover potential errors or rate limits.

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

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

The description is efficiently written, starting with the core purpose, then budget format, then forced setting, optimization/billing, and targeting example. Every sentence adds value, and formatting with line breaks improves readability.

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

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

Given 9 parameters, no schema descriptions, and an existing output schema, the description covers the most critical aspects for creating a functional ad set (budget, targeting, goals). It omits minor details like default status or bid_strategy, and could mention that the campaign_id must belong to an ABO campaign, but overall it's sufficient.

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

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

Schema description coverage is 0%, so the description compensates by explaining the key parameters: daily_budget_cents format, targeting spec with an example, optimization_goal and billing_event usage. However, it does not cover status, account_id, or bid_strategy, leaving some parameters undocumented.

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

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

The description clearly states 'Create an ABO ad set,' using specific verbs and nouns. It distinguishes from sibling tools like 'create_ad' and 'update_adset' by focusing solely on ad set creation with ABO (Ad Set Budget Optimization), which is a distinct operation.

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

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

The description provides explicit when-to-use guidance: for ABO ad sets, with specific optimization goals (THRUPLAY for video, LEAD_GENERATION for lead gen) and forced advantage_audience off. It does not explicitly state when not to use, but the context implies alternatives exist (e.g., manual budget ad sets via update_adset).

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

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

With no annotations, description carries full transparency burden. It discloses key behaviors: default PAUSED status, budget model (ABO, no campaign budget), forced false for budget sharing, and objective restrictions. However, it does not mention error handling, validation outcomes, or whether the tool is idempotent. Still, major behavioral traits are covered.

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

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

Extremely concise: three sentences front-load the most critical information (create, default PAUSED, no budget). Every sentence adds value with no redundancy.

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

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

Given 5 parameters, 2 required, and an output schema, the description covers the essential constraints and behavior. It omits details about return values (but output schema exists) and error conditions. Still, it is sufficiently complete for an agent to correctly invoke the tool.

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

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

Schema description coverage is 0%, so description must compensate. It adds meaning for status (default PAUSED with caution), objective (must be OUTCOME_*), and special_ad_categories (conditional). However, account_id is not explained, and name is only implied. Overall, it provides significant value beyond the schema.

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

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

Description clearly states 'Create a campaign' with specific verb and resource. It distinguishes from siblings (e.g., create_ad, create_adset) by focusing on campaign-level creation and detailing campaign-specific constraints like ABO budgeting and status defaults.

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

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

Explicitly states when to use the tool (to create a campaign) and provides critical usage constraints: defaults to PAUSED with warning against setting live without explicit yes, ABO budget structure, forced false for budget sharing, required OUTCOME_* objectives, and conditional special_ad_categories. This guides agent on both usage and non-usage scenarios.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It mentions return fields (page id + name) and fallback behavior but lacks details on read-only nature, rate limits, or pagination. The description adds moderate behavioral context beyond the 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?

Three sentences with no wasted words. Front-loaded with purpose statement, followed by essential return info and usage guidance. Highly efficient.

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

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

For a simple tool with one optional parameter and an output schema, the description covers purpose, return fields, and usage. It lacks mention of pagination or limitations, but given the output schema likely standardizes response structure, this is acceptable.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the account_id parameter's fallback behavior (META_AD_ACCOUNT_ID if omitted), adding meaning beyond the schema's type definition.

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

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

The description clearly states the tool lists Facebook Pages promotable on the ad account, specifying the verb 'List' and resource 'Facebook Pages'. It distinguishes from siblings as no other sibling focuses on listing pages.

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

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

The description provides explicit context for when to use the output (for object_story_spec/asset_feed_spec in creatives) and explains fallback behavior when account_id is omitted. However, it does not explicitly exclude alternative tools since no direct sibling exists for this function.

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

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

With no annotations, the description provides basic behavioral info: it lists available accounts. It is accurate but lacks details like whether it filters by token scope or if the list is exhaustive.

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

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

A single sentence of 13 words efficiently conveys the purpose and output details. The verb is front-loaded, and every word adds value.

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

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

The description is complete for a simple parameterless tool with an output schema. It explains the output fields, though it could mention token permissions briefly for full context.

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

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

No parameters exist, so schema coverage is 100% by default. The description adds value by specifying the output fields, which helps the agent understand what data to expect.

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

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

The description clearly states the verb 'List' and the resource 'ad accounts', and specifies the fields returned (id, name, currency, status). It distinguishes from sibling tools like get_ads or get_campaigns which list different resources.

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

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

No explicit guidance on when to use this tool versus alternatives. It is implied as the primary way to list accessible ad accounts, but lacks when-not-to-use or mention of alternative tools.

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

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

With no annotations, the description must disclose behavioral traits, but it only states a read operation without mentioning pagination, authentication, or potential side effects.

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

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

The description is a single concise sentence, but it omits important details, making it under-specified rather than efficiently helpful.

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

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

Despite having an output schema, the description lacks essential context about parameter usage and filtering possibilities, leaving the agent underinformed for a 2-parameter tool.

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

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

Schema description coverage is 0%, and the description adds no meaning to the 2 parameters (limit, account_id). The agent receives no help understanding parameter purpose or format.

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 creatives on the account', and specifies returned fields (id, name, status), distinguishing it from sibling tools that create or update creatives.

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

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

The description provides no guidance on when to use this tool vs alternatives like get_ads or get_adsets, nor does it mention any prerequisites or filters.

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

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

With no annotations, the description should disclose behavioral traits like pagination, side effects, or read-only nature. It only mentions listing with optional filter, missing details on limit parameter behavior or account_id requirement.

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

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

Very concise single sentence that is front-loaded. However, it could be slightly more detailed without losing conciseness to cover parameters.

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

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

Given 3 parameters with no schema descriptions, no annotations, and an output schema not described, a one-sentence description is too brief. Needs to explain parameter format and return structure.

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

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

Schema description coverage is 0%, so description must add meaning. It explains the adset_id filter but not limit or account_id. Account_id is implied by 'on the account' but not explicit. Insufficient for 3 parameters.

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

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

The description clearly states the verb 'List' and resource 'ads' with an optional filter to one ad set. It distinguishes from sibling tools like get_adsets and get_campaigns.

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

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

No guidance on when to use this tool vs alternatives, or when not to use it. There is no mention of 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?

No annotations exist, so the description must disclose behavioral traits. It fails to mention read-only nature, authentication requirements, rate limits, pagination, or what happens when account_id is null.

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

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

Single sentence with no wasted words, but lacks structure. Could benefit from bullet points or explicit parameter explanations.

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 3 optional parameters, no required params, and an output schema present, the description omits important context like default behavior, return format hints, and pagination.

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

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

Schema description coverage is 0%. The description adds meaning only to campaign_id ('optionally filtered to one campaign'), leaving limit and account_id unexplained.

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

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

The description uses a specific verb ('List') and resource ('ad sets') and adds the optional filter scope ('optionally filtered to one campaign'), which clearly distinguishes it from sibling tools like create_adset and get_ads.

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

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

The description implies usage by stating the optional filter, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_ads, get_campaigns) or when not to use it.

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

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

With no annotations, the description conveys only that the tool lists campaigns, implying a read operation, but lacks details on permissions, pagination, rate limits, or behavior when account_id is null.

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

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

Single sentence efficiently conveys the tool's purpose and output fields, but could be slightly enhanced with parameter hints without losing conciseness.

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

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

Despite the presence of an output schema, the description is incomplete because it fails to explain the two parameters and usage context, which is important for a list operation with optional account_id.

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%, yet the description does not explain the parameters (limit, account_id). It only lists output fields, leaving the agent uninformed about how to use the input parameters.

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

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

Clearly states the tool lists campaigns and mentions returned fields (id, name, objective, status, budgets). However, it does not distinguish from other list tools like get_ads or get_adsets, relying on the tool name 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?

No guidance on when to use get_campaigns versus alternatives such as get_ads or get_insights. No exclusions or prerequisites 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 provided. Description indicates read-only operation ('Read performance') but does not disclose other behavioral traits like rate limits, authentication needs, or whether results are paginated.

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

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

Description is short and front-loaded with the main action. Could be more structured (e.g., listing parameters separately), but provides key information without unnecessary words.

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

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

Output schema exists (covers return values), but description omits usage context and parameter details for 3 of 5 parameters. Adequate for a simple read tool but incomplete for complex queries.

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

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

Schema coverage is 0%. Description explains 'level' and 'date_preset' values, and lists returned fields, but fails to describe 'limit', 'fields', and 'account_id' parameters. Missing critical details for correct parameter usage.

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

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

The description clearly states it reads performance data and specifies the level parameter values and date_preset options. It distinguishes itself from sibling tools which are create/update operations.

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

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

No explicit guidance on when to use this tool versus alternatives. However, it is the only read tool among siblings, so usage is implied. Lacks when-not or alternative mentions.

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

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

No annotations provided, so the description fully informs: thumbnails expire fast (reliability), returns a list, and identifies the preferred thumbnail with is_preferred=true. No contradictions.

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

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

Two concise sentences front-loaded with the primary action. Every sentence adds critical information: purpose, expiration behavior, recommended usage, and return format.

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?

Has output schema, so return details are covered. Description explains usage timing and preferred thumbnail selection. Adequate for a single-parameter, read-only tool.

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

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

Single parameter video_id has no schema description. The description says 'for a video' but does not explain the expected format or source. With 0% schema coverage, the description partly compensates but lacks specifics.

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 'Fetch fresh thumbnail urls for a video.' It uses a specific verb ('fetch') and identifies the resource ('thumbnail urls for a video'), and distinguishes itself from sibling tools by focusing on fresh thumbnails.

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

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

Explicitly advises calling 'immediately before create_ad_creative' and using the returned URI as image_url, giving clear context for when and how to use this tool. No alternatives needed given the unique purpose.

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

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

Describes returned fields (id, name, audience_size) but does not disclose authentication needs, rate limits, or side effects. Since no annotations, more detail would help, but the read-only nature is implied.

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

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

Two sentences, front-loaded with key action, no unnecessary words. Every sentence adds value.

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

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

Describes output fields (id, name, audience_size) and usage context despite lacking parameter details. Output schema exists but is not detailed; description covers key return values.

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

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

Schema coverage is 0%, and description only hints at 'query' parameter (search by name). No explanation for 'limit' or 'account_id', so agent lacks guidance on their usage.

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

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

Clearly states 'search targetable interests by name', specifying action and resource. Distinguishes from sibling tools like create_adset and get_ads by being a search/list operation.

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

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

Explicitly says results are used to load into a flexible_spec interest stack on an ad set, giving context for when to use. Could mention when not to use, but adequate.

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

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

No annotations are provided, so the description bears full responsibility. It discloses that swapping creative_id bypasses a DCO check, but does not mention other behavioral traits like required permissions, partial updates, or side effects on other fields.

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

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

Two sentences, no redundancy. The first sentence states the core action, the second adds critical nuance. Highly efficient.

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

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

The description is adequate for the specific DCO bypass scenario but lacks general parameter explanations and broader usage context. An output schema exists, which helps with return values, but the description could be richer.

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

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

With 0% schema description coverage, the description should compensate but only mentions creative_id indirectly. The meanings of name, ad_id, and status are not explained, leaving the agent to guess.

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

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

The description clearly states 'Update an ad' and provides a specific use case (bypassing DCO check with creative_id swap), distinguishing it from sibling tools like update_adset or create_ad.

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

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

The description implies usage as step 4 of a flow and highlights a specific scenario (bypassing DCO error 1885998). It does not explicitly state when not to use or list alternatives, but the context is clear.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It fails to mention whether the update is immediate, if it requires specific permissions, what happens to unchanged fields, or the response format. The word 'update' implies mutation but no further 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?

A single, front-loaded sentence that conveys the essential purpose without any filler. Every word is necessary and the structure is optimal for quick scanning.

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, no annotations, and an output schema, the description is somewhat adequate but leaves gaps. It covers the primary mutable fields but lacks information on preconditions, effects, or return values. Relies on the output schema for return details, but the description could be more self-contained.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that daily_budget_cents is in cents and that status and name are updatable. However, it does not mention adset_id (required, obvious from tool name) and omits any enumeration for status. Still provides useful semantic context beyond schema.

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

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

The description clearly states the verb 'Update' and the resource 'ad set', and lists specific updatable fields (status, daily budget in cents, name). It distinguishes itself from create_adset by focusing on modification, and from update_ad/update_campaign by targeting ad sets specifically.

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

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

No guidance on when to use this tool versus alternatives. It does not mention that this tool is for modifying existing ad sets and that create_adset should be used for new ones. No prerequisites or context for invocation 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 must carry the burden. It warns that launching requires an explicit yes, implying a destructive or state-changing operation. However, it does not disclose permissions, rate limits, or other behavioral traits. The warning is helpful but incomplete.

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

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

Two sentences with zero wasted words. The first sentence states the core purpose, the second provides critical usage instructions. Efficient and front-loaded.

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

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

Given the presence of an output schema, return values need not be described. The description covers the status parameter well but omits details about the name parameter. For a tool with 3 parameters and no annotations, more completeness on all parameters would be expected.

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

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

The input schema has 0% description coverage, meaning the schema alone provides no parameter meaning. The description adds crucial semantics for the status parameter by listing valid values (ACTIVE, PAUSED, DELETED). It does not explain the name or campaign_id parameters, but status is the key 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 tool updates a campaign. The verb 'Update' and resource 'campaign' match the name. It distinguishes from siblings like update_ad and update_adset by focusing on campaigns. However, it does not elaborate on what fields can be updated beyond status and name.

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

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

Provides explicit guidance on using the status parameter: 'Pass status ACTIVE to launch (get an explicit yes first), PAUSED to pause, DELETED to remove.' This tells when to use each status. No explicit alternatives are mentioned, but siblings are for different resources.

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 bears full responsibility. It discloses the return format ({"id": "<video_id>"}), the upload method (multipart), and the file type (.mp4 or similar). Missing details include authentication requirements, rate limits, and error handling. This is adequate but not rich.

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

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

The description is concise, using two main sentences plus a brief note on chunked uploads. It front-loads the purpose and return value, and every sentence adds value without redundancy.

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

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

Given the tool has 3 parameters and an output schema is mentioned, the description covers the core function, return format, and a key behavioral trait. Missing details about the optional parameters are minor given their likely inferred purpose (name and account_id). Overall, it is fairly complete for the tool's complexity.

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

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

The description adds meaning for the required 'file_path' parameter, explaining it must be an absolute path to an .mp4 file. However, it does not document the optional 'name' and 'account_id' parameters. With 0% schema coverage, the description partially compensates but leaves gaps.

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

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

The description clearly states the verb (upload) and resource (local video file to ad account), and distinguishes the tool from siblings by specifying its return value and its role in creating ad creatives. No other sibling tool performs upload, so uniqueness is clear.

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

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

The description explains when to use the tool (uploading a local video file) and notes the limitation that it does a straight multipart upload, implying it may not be optimal for very large files. However, it does not explicitly state when not to use it or provide alternatives, which keeps it from a perfect score.

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