NotFair-MetaAds

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

The description discloses that it sends a message directly to the NotFair team, generates a ticket, and the user receives an email within 1 business day. It also instructs to write in first person. Annotations show readOnlyHint=false and destructiveHint=false, consistent with the described write operation. 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?

The description is well-organized with clear sections for purpose, when to use, and exclusions. It is slightly verbose but every sentence adds value. Front-loaded with the core function.

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

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

Given no output schema, the description explains the outcome (ticket generated, email response within 1 business day). It covers the flow and expectations for a contact tool, making it complete.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds guidance for the 'message' parameter to write in first person, and for 'context' to omit PII except user's explicit input. This adds value beyond the schema.

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

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

The description clearly states the tool contacts NotFair support, with specific verb 'contact' and resource 'NotFair support'. It distinguishes from sibling tool fileInternalNotFairToolFeedback by specifying that this is for user-facing support.

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

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

The description explicitly lists when to use (user wants to contact support) and when not to use (routine questions, internal tool issues, questions you haven't tried to answer). It provides concrete examples of user utterances and conditions for escalation.

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?

Annotations already provide idempotentHint=true and destructiveHint=false. Description adds useful context: defaults to status=PAUSED and the need for a creative_id. No contradictions with annotations.

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

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

Two sentences, front-loaded with action, then default and prerequisite. Every sentence adds value with no waste.

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

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

Covers main action, prerequisite, and default status. No output schema, but annotations fill safety context. Lacks details on permissions or failure modes, but sufficient for a creation tool.

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

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

Schema coverage is 40% (only 2 of 5 params have descriptions). The description explains creative_id ('attaching an existing creative by id') and status default, but adds no detail for name, adset_id, or accountId beyond schema basics.

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

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

Description clearly states the tool creates a new ad within an existing ad set, attaching an existing creative by ID. It distinguishes from sibling tools like createAdCreative (which creates the creative) and is specific about the resource and action.

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

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

Explicitly advises to call createAdCreative first, giving a clear prerequisite. Lacks explicit when-not-to-use or alternatives, but the context of sibling tools (enableAd, pauseAd) implies this is for creation only.

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?

Annotations already indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds that it returns a creative ID, which is useful context, but does not delve into side effects or error conditions 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?

Extremely concise at 4 sentences, no filler. Front-loads the action ('Create an ad creative') and efficiently conveys all necessary operational details.

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

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

Covers the main creation flow, key parameter, and result usage. Lacks error handling details but given no output schema and available annotations, it provides sufficient context for an agent to use the tool correctly.

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

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

Enhances schema by detailing that 'object_story_spec' must include page_id and one of link_data/photo_data/video_data/template_data, and that page_id comes from 'listPages'. This adds significant meaning beyond the schema's minimal descriptions.

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

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

The description clearly states the tool creates an ad creative, using a specific verb ('Create') and resource ('ad creative'). It distinguishes from sibling tools like 'createAd' by explaining the returned creative ID is used there.

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 instructions on structuring 'object_story_spec' with page_id and one data type, and instructs to use 'listPages' for a valid page_id. Lacks explicit when-not-to-use but covers prerequisites and downstream 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?

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds valuable behavioral details: defaults to status=PAUSED and the budget consideration (set here or rely on CBO). This covers key behavioral traits beyond the annotations.

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

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

The description is three sentences, concise and front-loaded with the purpose. It efficiently covers key points, but could be better structured for such a complex tool with 14 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 the tool's complexity (14 parameters, nested objects, no output schema), the description covers the core aspects but misses important context like return values, permissions, and interaction with the campaign lifecycle. It is adequate but not comprehensive.

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

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

With 57% schema coverage, the description adds meaning for the targeting parameter (JSON spec with examples) and mentions budget and status. However, many parameters (e.g., end_time, bid_amount, promoted_object) are not explained beyond the schema, leaving 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 'Create a new ad set under an existing campaign', which is a specific verb and resource. It distinguishes from sibling tools like createCampaign and createAd by specifying 'ad set' and 'under an existing campaign'.

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

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

The description implies the tool should be used when you have an existing campaign, but it does not explicitly compare to alternatives like createAd or provide when-not-to-use scenarios. Some guidance is given about budget (either set here or rely on CBO) but overall lacks explicit usage context.

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

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

The description adds significant behavioral context beyond annotations: returns campaign id and snapshot, defaults to PAUSED, budgets in minor units, and special_ad_categories requirement. This complements the annotations (readOnlyHint=false, idempotentHint=true) without contradiction.

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, front-loaded with the purpose, and each sentence adds value. No redundant information.

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

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

Given the 10 parameters and no output schema, the description covers return values (id and snapshot), default behavior, budget units, and required special_ad_categories. It could mention prerequisites or error scenarios, but for a create tool it is reasonably complete.

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

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

With 60% schema description coverage, the description adds meaning beyond the schema by clarifying budget units, special_ad_categories values, and default status. It does not explain every parameter in detail but compensates for the coverage gap with key contextual notes.

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

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

The description explicitly states the verb 'Create' and the resource 'campaign' with the context of 'on the active (or specified) ad account'. It clearly distinguishes itself from sibling tools like createAd, createAdSet, and updateCampaign by naming the primary function and return value.

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 helpful usage context: defaulting to PAUSED for review, requiring special_ad_categories, and noting budget units. However, it does not explicitly differentiate from createAdSet or createAd, nor does it mention when to use this tool over alternatives like updateCampaign.

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?

Annotations already indicate idempotent and non-destructive behavior. The description adds the prerequisite condition about parent ad set and campaign being active, which is valuable beyond annotations.

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

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

Two sentences, front-loaded action, then condition. No unnecessary words. 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 explains the action and necessary conditions. Lacks output schema details, but for a simple state-change tool this is adequate.

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

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

With 50% schema coverage (adId missing description), the description does not add any parameter-level information. It only explains the overall effect, not the specific 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 tool re-activates a paused ad, using a specific verb ('re-activate') and target resource ('paused ad'). It distinguishes from siblings like pauseAd and createAd.

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 gives explicit context on when the ad will deliver (parent entities must be active), but does not explicitly state when not to use or compare to 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?

Annotations already provide idempotentHint=true and destructiveHint=false. Description adds the parent campaign condition, but does not disclose other behavioral traits like required permissions or error states. The description does not contradict annotations.

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

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

Two sentences with no unnecessary words. First sentence states purpose, second adds a critical condition. 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 mutation tool, the description covers the action and a key prerequisite. It does not mention output, but no output schema exists. It lacks error conditions or edge cases, but is reasonably complete given the tool's simplicity.

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

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

Schema description coverage is 50%: adSetId has no schema description, accountId has a description. The tool description does not elaborate on parameter meanings or formats. adSetId's purpose is inferable from the purpose, but explicit parameter guidance is absent.

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 verb 'Re-activate', resource 'paused Meta ad set', and outcome 'status=ACTIVE'. This specifically distinguishes it from sibling tools like pauseAdSet, enableAd, and enableCampaign.

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?

Description indicates when to use (re-activate paused ad set) and includes a key prerequisite: parent campaign must be ACTIVE. It does not explicitly list alternatives or when-not-to-use, 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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds critical context beyond annotations: the dependency on child objects being active. No contradictions with annotations.

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

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

The description consists of two efficient sentences. It immediately states the action and follows with a crucial caveat. No wasted words.

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

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

For a simple toggle tool with two parameters, existing annotations, and no output schema, the description is fully complete. It explains the operation and the essential prerequisite about child objects, enabling an agent to use it correctly.

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

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

The input schema has 50% description coverage (accountId has a description, campaignId lacks one). The tool description does not add any parameter-specific details beyond what the schema provides, so it only meets the baseline for moderate 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 verb 'Re-enable' and the resource 'paused Meta campaign', targeting status=ACTIVE. This distinguishes it from sibling tools like pauseCampaign and enableAdSet.

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 useful guidance by noting that underlying ad sets/ads must be active for delivery to resume. It implies when to use this tool (to resume a paused campaign) but does not explicitly list when not to use it or offer alternatives.

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

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

Annotations indicate a non-destructive mutation. The description adds behavioral context: private channel, user not seeing it, 5-per-session limit, and that it doesn't need permission. 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?

Well-structured with sections and bullet points, but slightly long. However, every sentence adds value and is front-loaded with 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?

Comprehensive coverage of purpose, triggers, exclusions, timing, volume, and parameter usage. No output schema needed; the tool is complete for its feedback function.

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

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

Schema coverage is 100%, and the description supplements by advising specificity (e.g., 'Reference tools by name'), adding value beyond the schema definitions.

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

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

The description clearly states the tool's purpose as an internal feedback channel for reporting MCP/tool friction, distinguishing it from sibling tools like askSupport.

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 when-to-use triggers, when-not-to-use exclusions (e.g., individual errors, success confirmation), timing advice ('file now'), and volume guidelines, making it easy to decide when to invoke.

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?

Beyond annotations (which indicate openWorldHint and non-destructive), the description adds critical behavioral details: it counts against monthly quota, returns a public URL, and explains quality vs latency trade-offs. No contradictions with annotations found.

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

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

The description is long but well-structured with clear sections (Prompt craft, Ad-policy rules, Aspect ratios, Quality vs latency, Output format). It is front-loaded with the main purpose and every sentence provides actionable information. No wasted words.

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

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

Given no output schema, the description fully explains the return value (public URL). It covers all parameters, usage contexts, and edge cases (e.g., background transparency requirements). The description is comprehensive for an agent to use the tool correctly.

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

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

The input schema already covers all 6 parameters with descriptions (100% coverage). The tool description goes further by providing rich context for the 'prompt' parameter (crafting instructions, ad rules) and for 'quality', 'aspectRatio', 'outputFormat', and 'background'. This adds significant value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Generate one image from a prompt using OpenAI GPT Image 2. Returns a public URL...'. It uses a specific verb ('Generate') and resource ('image'), and distinguishes from siblings by detailing its unique functionality and output format.

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

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

The description provides extensive usage guidelines, including when to use different quality levels (low for drafts, high for production), aspect ratios for various platforms (Google Ads, Meta, web), and ad-policy rules. It also mentions quota impact. This helps the agent decide when and how to invoke the tool effectively.

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

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

Annotations already mark it as readOnly and non-destructive. The description adds context about being a cheap one-call summary but does not contradict annotations.

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

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

Two sentences: first lists returned fields, second gives usage advice. No wasted words.

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

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

For a simple read tool with one optional parameter and no output schema, the description covers what it returns and how to use it. Could mention what 'primary' means but still complete.

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

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

The input schema covers the single parameter with description, so baseline is 3. The description adds no further parameter details beyond the schema.

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

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

The description clearly states it provides a snapshot of the ad account with specific fields (id, name, currency, etc.). It distinguishes itself from siblings like getInsights by noting it's a cheap summary.

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

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

Explicitly recommends pairing with getInsights for performance and implies it's a quick, one-call summary. The optional accountId parameter hints at using it for the primary account or a specific one.

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?

Annotations already declare readOnlyHint and destructiveHint. Description adds that the tool stops paginating at the limit, but doesn't detail rate limits, auth requirements, or return structure. Adequate given annotations.

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

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

Single paragraph with no wasted words. Front-loaded with purpose, then defaults, override options, and alternative tool. Every sentence adds value.

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

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

For a read-only data pull tool with 9 optional params and no output schema, the description covers default behavior, customization, and alternatives. Could mention return format but schema covers inputs sufficiently.

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

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

Schema coverage is 100%, so parameters are well-documented. Description adds that fields default to an 'audit set', and clarifies pagination behavior for limit. No new details beyond schema, baseline 3.

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

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

Description clearly states the verb 'Pull', the resource 'performance insights for the active (or specified) ad account', and specifies sensible defaults (campaign-level, last 30 days, audit-friendly fields). It distinguishes itself from sibling tools like runScript for more complex tasks.

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

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

Explicitly tells when to use overrides for narrower questions and when to use runScript for correlations or cross-account joins. Does not list explicit 'when not to use' scenarios but provides a clear 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?

Annotations indicate readOnlyHint=true and destructiveHint=false; the description adds that it never returns individual user data and aggregates metrics, providing valuable context beyond the annotations.

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

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

The description is concise, front-loaded with key purpose, and each sentence adds value with no waste.

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

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

Despite lacking an output schema, the description adequately explains return values (impressions, reach, reactions, counts) and clarifies what it does not return, making it complete for this 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 covers 100% of parameters; description adds domain-specific meaning for postId (format referencing effective_object_story_id) and mentions default metrics, enhancing understanding beyond the schema.

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

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

The description clearly states the tool aggregates engagement metrics for a Page post, listing specific metrics (impressions, reach, reactions) and distinguishes from siblings by mentioning comparison with getInsights.

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 (boosted post ad) and recommends pairing with getInsights, offering good usage guidance, though it could be more explicit about when not to use.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's addition of 'current monthly' and 'for this account' provides minimal extra behavioral context. The description does not contradict annotations.

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

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

The description is a single, concise sentence that directly states the tool's function with no extraneous words. It is front-loaded and efficient.

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

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

Given the tool's simplicity (no parameters, read-only, no output schema), the description adequately covers what the tool does. It could optionally mention the return format (e.g., numbers), but it is sufficient for an agent to understand the tool's purpose.

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 tool has zero parameters, so the schema covers everything. With no parameters, the description need not add parameter details. The baseline for 0 params is 4, and the description maintains that.

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 shows 'current monthly image generation quota and usage for this account', with a specific verb ('show') and resource. It distinguishes from sibling tools like 'generate_image' or 'getAdAccount' by focusing on quota/usage.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. While the context is clear (check quota before generating images), no alternatives or exclusions are mentioned. This is acceptable but could be improved.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the exact data returned (active account id plus selected accounts), which is not in the annotations. 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 sentences that are concise, front-loaded with the core purpose, and contain no unnecessary information. Every sentence is valuable.

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 zero parameters, no output schema, and a simple listing behavior, the description fully explains what the tool returns and how to use the results. It is complete for its complexity level.

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 are defined, so the schema coverage is 100%. The description does not need to explain parameters, and baseline is 4. It adds no superfluous parameter information.

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

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

The description clearly states it lists Meta ad accounts connected to the session, specifying what is returned (active account id plus selected accounts with id and name). It distinguishes itself from the sibling tool getAdAccount by noting that getAdAccount provides per-account details.

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

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

Explicitly states that the returned ids can be used as accountId for other tools, and directs users to call getAdAccount for additional per-account information. This provides clear context on when to use this tool vs. alternatives.

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

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

Annotations already indicate read-only and non-destructive. Description adds pagination behavior (limit parameter stops after max), scoping logic, and status filtering defaults, providing useful context beyond annotations.

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

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

Two sentences, zero waste. First sentence states purpose and scope, second adds return fields and alternative tool. 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?

No output schema, but description lists returned fields. Covers usage, parameters, alternative, filtering, and scoping. Complete for a listing tool with moderate 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 coverage is 100%, so baseline is 3. Description adds value by explaining limit's pagination stop behavior and statuses default (Meta returns ACTIVE+PAUSED only), going beyond schema descriptions.

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

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

Clearly states it lists ads with account or ad set scoping. Distinguishes from sibling tools like listAdSets, listCampaigns. Specifies returned fields (id, name, status, etc.).

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

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

Provides explicit alternative: 'Use runScript for richer creative inspection.' Implies default account scoping but no explicit when-not-to-use. Clear enough for 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?

Annotations confirm readOnlyHint=true and destructiveHint=false. The description adds value by listing returned fields (status, budget, etc.), which is beyond the annotations. No behavioral surprises are mentioned, but for a read-only list tool, this is adequate.

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

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

Two sentences: first states action and scoping, second lists return fields. No wasted words, front-loaded action, easy to parse.

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

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

For a list tool with 4 parameters and no output schema, the description covers return fields, scoping, and parameter defaults. Could mention sorting or pagination (handled by limit), but overall complete enough for 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 coverage is 100%, so description adds minimal value beyond schema. It clarifies default behavior for accountId and campaignId, but this is largely redundant with schema descriptions. Baseline of 3 is appropriate.

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

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

The description clearly states the tool lists ad sets with specific scoping (by account or campaign) and enumerates return fields. It distinguishes itself from sibling tools like listAds and listCampaigns by specifying its focus on ad sets.

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

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

The description explains the default scope (account) and how to filter by campaign using campaignId. It lacks explicit guidance on alternatives but provides sufficient context for scoping decisions.

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?

Annotations already indicate read-only and non-destructive. Description adds pagination behavior (stops at limit) and return fields, which go beyond annotations. 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 short, front-loaded sentences. No unnecessary words. Each sentence adds value: purpose and alternative.

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 is simple read-only list. Description lists return fields, pagination limit, and account specification. Could mention default account behavior more explicitly, but sufficient for a list tool.

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

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

Schema coverage is 100% with detailed parameter descriptions. Description does not add extra parameter meanings beyond schema, so baseline 3 is appropriate.

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

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

Description uses specific verb 'list', specifies resource 'campaigns under active/ad account', and lists returned fields. Distinct from sibling 'runScript' which does richer 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?

Explicitly states when to use (list campaigns with fields) and when not to (for cross-surface analysis, use runScript). Clear alternative 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?

Annotations declare readOnlyHint=true and destructiveHint=false. Description adds that it lists pages the user manages and does not read content. No contradiction; description adds relevant behavioral context.

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

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

Two sentences, no fluff. Front-loaded with purpose and usage. Every sentence adds value.

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

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

Given tool simplicity with 2 optional params, annotations, and no output schema, description covers purpose, behavior, and return structure adequately.

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

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

Schema coverage is 100% and both parameters have descriptions. Description adds minimal extra meaning (e.g., businessId includes Pages from that business). Baseline 3 is appropriate.

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 tool lists Facebook Pages the user manages for ad creative identity. Specifies return fields (id, name) and what it does NOT do (read content). Distinguishes from sibling tools which are ad/creative related.

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 to use for picking Page identity for ad creatives. Mentions optional businessId for broader Pages. Slightly lacks when-not-to-use or alternatives, but context is clear.

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

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

Annotations indicate idempotent and non-destructive behavior. The description adds valuable context: the creative is not modified and the action is reversible. No contradiction with annotations.

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

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

Two concise sentences front-load the key information. Every word serves a purpose, with no redundancy.

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

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

For a simple pause operation with clear annotations and no output schema, the description covers the essential behavioral details (creative unchanged, reversibility) and purpose adequately.

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

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

Schema description coverage is 50% (only accountId described). The description clarifies that adId refers to the ad to pause, but adds no syntax or constraints beyond the schema. Minimal compensation for 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 'Pause', the resource 'a single ad', and specifies the exact action: sets status=PAUSED and clarifies it does not modify the creative. It distinguishes from siblings like pauseAdSet and enableAd by mentioning reversibility.

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

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

The description provides clear context on when to use (pausing a single ad) and notes reversibility via enableAd. However, it does not explicitly exclude usage scenarios or compare with alternatives like pauseAdSet or pauseCampaign.

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?

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds value by noting reversibility and no impact on the parent campaign, but does not disclose auth needs, rate limits, or side effects on running ads.

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 waste. Front-loaded with the core action and followed by key behavioral notes.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers the essential action, reversibility, and scope. Missing details like return value or error states are acceptable for a straightforward mutation.

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 50%: only accountId has a description. The tool description does not elaborate on parameter usage or defaults, failing to compensate for the missing schema descriptions.

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

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

The description uses a specific verb ('pause') and resource ('ad set'), explicitly states the status change to PAUSED, and distinguishes from siblings by noting that the parent campaign remains untouched.

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

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

Provides clear context that pausing is reversible via enableAdSet and leaves the campaign untouched. While it doesn't explicitly state when not to use or compare to pauseCampaign, the guidance is sufficient for sibling 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?

The description adds behavioral context beyond annotations by stating the specific status change, reversibility, and return of before/after snapshots. Annotations already indicate idempotency and non-destructiveness.

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

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

The description is concise (two sentences) with no wasted words, front-loading the core action and key details.

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

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

Given the absence of output schema, the description helpfully mentions return snapshots. For a simple two-parameter tool, this is adequately complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional parameter semantics beyond what is already in the schema.

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

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

The description clearly states the tool pauses a Meta campaign by setting status=PAUSED, and distinguishes it from siblings like pauseAd and pauseAdSet by specifying the resource type.

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

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

The description provides context on when to use (pausing a campaign) and mentions reversibility via enableCampaign, but lacks explicit exclusions or alternatives beyond the sibling structure.

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

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

The description adds behavioral context beyond annotations by noting that it works on all ad types, including those where status writes are blocked. It does not contradict annotations (readOnlyHint false, destructiveHint false, idempotentHint true).

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 that effectively communicates the core action and a special case. It is front-loaded but could benefit from parameter details without being overly verbose.

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

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

For a simple rename tool with 3 params and no output schema, the description covers the primary function and a notable exception. It lacks mention of idempotency (though in annotations) and return behavior, but is otherwise adequate.

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

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

With 67% schema coverage (adId and accountId described, but name lacks description), the description does not add meaning for the name parameter beyond its constraints. It fails to compensate for the missing schema description.

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

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

The description clearly states the tool renames an ad by setting the name field, and specifies it works on all ad types including boosted-page-post ads where status writes are blocked. This distinguishes it from sibling tools like renameCampaign or updateAdCreative.

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

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

The description implies when to use (rename an ad) and highlights applicability to boosted-page-post ads. However, it does not explicitly state when not to use it or provide alternatives, though the sibling list is available.

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

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

The description notes that the tool only sets the `name` field, which is consistent with the idempotentHint=true annotation. No further behavioral traits are disclosed beyond what annotations provide; annotations already indicate non-destructive and idempotent nature, so the description adds limited value.

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, front-loaded sentence that directly states the tool's purpose with no extraneous information. Every word serves a 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 absence of an output schema and the presence of sibling update tools, the description lacks sufficient context. It does not explain return values, error states, or that the tool only updates the name field, leaving ambiguity about its relationship with `updateCampaign`.

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

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

Schema description coverage is only 33% (only accountId described). The tool description adds context that `name` is the new name, but does not explain `campaignId` or elaborate on `accountId` beyond schema. The description minimally compensates for the low coverage.

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

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

The description clearly states the action ('Rename a campaign') and the specific field affected ('sets the `name` field'). It distinguishes from sibling tools like `renameAd` or `updateCampaign` by focusing solely on renaming.

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 such as `updateCampaign`. It does not specify prerequisites, nor does it differentiate use cases (e.g., 'Use this tool only to change the campaign name, for other fields use updateCampaign').

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds extensive behavioral details: sandboxed runtime, timeout limits (30s default, max 45s), return cap (500KB), log limit (100K chars), no mutations allowed, top-level await, and that return must be JSON-serializable. This goes far beyond annotations.

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

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

The description is long but well-structured with clear sections (WHEN TO USE, BATCHING DISCIPLINE, API SURFACE, COMMON PATTERNS, RULES, ANTI-PATTERNS). It is front-loaded with the core message. While every sentence is informative, it could be slightly more concise without losing value.

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

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

Given the tool's complexity (multiple sub-APIs, constants, helpers, constraints), the description is remarkably complete. It covers the entire API surface, common patterns, rules, limits, and return expectations. No output schema exists, but the description explains return value requirements and limits.

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

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

Schema has 100% description coverage with three parameters (code, accountId, timeoutMs) each having a description. The tool description adds significant context: explains how to use 'code' with the ads namespace, that accountId is optional, and that timeoutMs has a default and max. This adds meaning beyond the schema.

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

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

The description states it runs JavaScript orchestration scripts in a sandboxed QuickJS runtime against the Meta Marketing API. It clearly distinguishes itself from sibling tools by stating it can replace 10+ sequential Graph API calls and owns reads, differentiating from specific tools like getInsights.

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 gives when-to-use scenarios: open-ended analytical questions, correlation tasks, replacing multiple Graph endpoint calls. Also states when not to use: mutations must go to dedicated tools, and getInsights is for single pulls. Includes anti-patterns like calling runScript 5+ times instead of using graphParallel.

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?

Annotations indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true), consistent with description. Description adds behavioral context: prerequisite for creative existence. No mention of side effects or return value, but adequately complements annotations.

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

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

Two sentences only: first states purpose, second adds prerequisite and use cases. No redundant information, 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?

Covers purpose, prerequisite, and use cases. Lacks return value description and potential errors, but for a simple swap with no output schema, it is sufficiently complete for an agent to use correctly.

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

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

Schema coverage low at 33% (only accountId described). Description adds meaning to creative_id by stating it must exist and be created first. adId is implied but not explicitly described. Partial compensation for low coverage.

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

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

The description clearly states the tool swaps the creative on an existing ad, using specific verb 'Swap' and resource 'creative on an existing ad'. It distinguishes from siblings like createAdCreative (which mints a new creative) and rebuilds 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?

Explicitly states prerequisite: new creative must already exist (call createAdCreative first). Suggests use cases: A/B testing or refreshing creative. Does not explicitly mention when not to use, but implies avoidance if creative doesn't exist.

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

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

Annotations already indicate idempotent and non-destructive. The description adds useful context about what fields it covers, though it could mention that targeting replaces the entire spec (which is in schema description). 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: first states purpose and scope, second provides usage guidance and alternatives. No wasted words.

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

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

With 14 parameters and no output schema, the description provides a solid overview and key behavioral notes, but could detail replacement behavior for targeting and schedule. Still fairly complete for an update tool.

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

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

Schema coverage is low (29%). Description mentions key fields (targeting, optimization_goal, etc.) and suggests passing only changed fields, but doesn't fully compensate for undocumented parameters like name, end_time, or accountId.

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 updates ad-set fields beyond status/budget and lists specific fields (targeting, optimization_goal, etc.), distinguishing it from simpler tools like pauseAdSet/enableAdSet.

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 'Pass only the fields that are changing' and recommends simpler tools for simpler edits, providing clear when-to-use and alternatives.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the critical behavioral constraint that Meta blocks the update when the campaign uses CBO, which is not in annotations. It also implies the operation is not read-only (consistent with readOnlyHint=false).

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 superfluous words. The purpose is front-loaded. Every sentence adds value: the first states what it does, the second provides critical usage constraints.

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

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

No output schema, but the operation is straightforward. The description covers the key constraint (CBO blocking). With 4 parameters and no nested objects, the description is adequate. Could mention expected response (e.g., updated ad set ID), but not essential.

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

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

Schema description coverage is only 25% (only accountId has a description). The description adds meaning: budget parameters are in 'account-currency MINOR units' and must be mutually exclusive. It clarifies the budget semantics beyond the schema, compensating for low coverage.

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

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

Clearly states the verb 'Update' and the resource 'an ad set's daily or lifetime budget'. It distinguishes from sibling tools like updateAdSet (which updates other ad set settings) and updateCampaignBudget (which updates campaign budget).

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: 'Pass exactly one of dailyBudget or lifetimeBudget' and warns about Meta blocking when the parent campaign uses CBO. This helps the agent understand constraints and correct usage. No explicit alternatives mentioned, 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?

Annotations already indicate idempotentHint=true and destructiveHint=false; the description adds context that this tool updates multiple fields and is not for simple operations. No contradiction, and it reinforces the non-destructive, idempotent nature. However, it does not mention any additional behavioral traits like permission requirements or immediate effect, but the core is 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?

The description is two sentences long, front-loaded with the core purpose, and contains no filler. Every sentence adds necessary information.

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

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

Given 10 parameters and no output schema, the description is minimal. It covers the main use case but lacks details on required parameters (campaignId is required but not mentioned in the description), response format, or side effects. For a complex tool, it is adequate but not fully complete.

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

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

Schema description coverage is low (30%), and while the description mentions field categories (bid strategy, start/stop time, special_ad_categories), it does not provide detailed semantics for individual parameters (e.g., units for budgets, format for arrays). It adds moderate value over the schema but does not fully compensate for the lack of descriptions.

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

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

The description clearly states it updates campaign fields beyond status/budget/name, listing specific examples like bid strategy, start/stop time, and special_ad_categories. It explicitly distinguishes from sibling tools like pauseCampaign, enableCampaign, updateCampaignBudget, and renameCampaign, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool (for bid strategy, start/stop time, special_ad_categories) and when to use simpler alternatives (pauseCampaign, enableCampaign, updateCampaignBudget, renameCampaign). This clearly delineates usage boundaries.

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

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

The description adds value beyond annotations by explaining unit details ('currency MINOR units', 'no conversion done') and the mutual exclusivity constraint. Annotations already indicate idempotency (idempotentHint: true) and non-destructiveness, which are consistent. The description also hints at the need for currency knowledge via getAdAccount.

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

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

The description is three focused sentences: purpose, parameter constraint, unit clarification, and a pointer to a related tool. Every sentence earns its place with no fluff. It is front-loaded and easy to parse.

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

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

The description covers the key nuance of budget updates (units, exclusivity) but omits details on response behavior, error states (e.g., providing both budgets), or handling of accountId/campaignId. Given no output schema and moderate parameter count, the description is adequate but not thorough.

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

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

The description reinforces the schema's explanation of dailyBudget and lifetimeBudget (units, exclusivity) but does not add meaning for the other two parameters (accountId, campaignId). Schema coverage is 75% (campaignId missing description), but the description does not compensate for that gap. Baseline of 3 is appropriate.

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

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

The description starts with a clear verb+resource: 'Update a campaign's daily or lifetime budget.' It specifies the exact action and resource, and the nuance of daily vs lifetime distinguishes it from generic update tools. The sibling tools include updateCampaign and updateAdSetBudget, and this tool's focus on budget alone is clear from the 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?

The description explicitly states 'Pass exactly one of dailyBudget or lifetimeBudget,' providing a key usage constraint. It also suggests using getAdAccount to check currency. However, it does not explicitly contrast with sibling tools like updateCampaign (which might also update budget) or updateAdSetBudget, leaving some ambiguity about when to prefer this tool.

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