NotFair-GoogleAds

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

Annotations provide idempotentHint=true and destructiveHint=false. The description adds key behavioral context: atomicity requirement, auto-spawn behavior for treatment arm, return values (trial campaign resource name and changeId), and the sequence (apply change before scheduling). 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?

The description is somewhat long but every sentence provides necessary context for a complex multi-step tool. It is front-loaded with the step number and key constraint, making it efficient for the agent.

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

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

Given the complexity of the experiment workflow and the lack of an output schema, the description adequately explains the tool's role, return values, and how they should be used (apply change before scheduling). It does not cover error cases or failure modes but is sufficient for correct usage.

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

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

Schema description coverage is 100%, so the schema already documents all parameters well. The description does not add significant new semantic information about individual parameters beyond what is in the schema, but it does contextualize the arms array and the return values.

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 'Step 2 of 5. Create both arms (control + treatment) in ONE atomic call' and explains the Google constraint, making the tool's purpose highly specific and distinct from sibling tools like createExperiment or scheduleExperiment.

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

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

The description clearly indicates when to use (as step 2, for creating arms atomically) and mentions the constraint that prevents incremental addition, but does not explicitly state when not to use or provide 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 indicate it is idempotent and non-destructive. The description adds that keywords start enabled and returns changeId, but omits details about idempotency, error cases, or permission requirements, which are not covered by 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 extremely concise, using two sentences that front-load the purpose and include a sibling alternative and return value. No extraneous words.

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

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

The description covers purpose, usage guidance, and output, but given the complexity of 6 parameters and low schema coverage, it should include more parameter context to be fully complete. 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 only 33% schema coverage, the description adds no information about parameters beyond what the schema provides. It does not explain fields like matchType, keyword format, or the acknowledgeExperimentImpact parameter, 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 the tool creates/adds a new positive keyword in an ad group and contrasts it with bulkAddKeywords for multiple keywords, distinguishing it from siblings like addNegativeKeyword.

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 specifies when to use this tool (single new keyword) and provides an alternative (bulkAddKeywords for many keywords), giving clear guidance on tool selection.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the tool returns a changeId but no further behavioral traits beyond what annotations provide. No 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?

Two sentences: first states purpose and effect, second mentions return value. No wasted words, front-loaded with key information.

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

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

With no output schema, description mentions returns changeId. All four parameters are covered by description or schema. Annotations provide complete safety profile. The tool is simple and the description is fully adequate.

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

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

Schema coverage is 100%, with baseline 3. Description adds context: explains how to obtain sharedSetId via runScript, notes default matchType, and clarifies accountId can be omitted for primary account. This exceeds baseline.

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 'Add', the resource 'keyword to a shared negative keyword list', and the effect 'blocked across all campaigns linked to this list'. It distinguishes from siblings like addKeyword (adds positive keyword) and addNegativeKeyword (per 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 when to use this tool (to block a keyword across all campaigns linked to a shared list) but does not explicitly state when not to use it or name alternatives. It provides guidance on obtaining sharedSetId via runScript.

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 idempotentHint=true and destructiveHint=false, and the description adds context about re-enabling and the return of changeId. It does not contradict annotations and provides useful behavioral details beyond what annotations specify.

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-load the primary purpose and add a secondary use case efficiently. Every sentence earns its place 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 tool with 5 parameters (2 required) and no output schema, the description explains the return value and a key behavioral nuance. It lacks explicit mention of related sibling tools or error conditions, but is adequate overall.

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 80% of parameters with descriptions, so the description adds no additional parameter semantics. Baseline of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the action 'add a negative keyword to a campaign' and explicitly notes the secondary use case of re-enabling removed negatives. This distinguishes it from siblings like removeNegativeKeyword and addKeywordToNegativeList.

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 (adding and re-enabling negatives) but does not explicitly exclude scenarios like removing or managing negative lists, which are handled by sibling tools.

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

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

Annotations indicate it's not readOnly (writes) and not destructive. The description adds that it sends a message, creates a ticket, and the user gets an email response within 1 day. No contradictions, and 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?

The description is well-structured with usage rules and exclusions. A bit wordy but each sentence adds value. Could be slightly more concise, but overall efficient.

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

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

No output schema. The description mentions the email response but does not describe what the tool returns (e.g., success status, ticket ID). For a communication tool that generates a ticket, this is a minor gap. Otherwise covers purpose, usage, and parameters 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%, so the schema already describes parameters. The description restates the first-person writing guidance for 'message' and context for 'context', but adds no new information beyond what's in the schema. Baseline is 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?

The description clearly states it contacts NotFair support, generates a ticket, and specifies response time. It distinguishes from sibling tools by listing exclusions and an alternative (fileInternalNotFairToolFeedback), 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?

Explicitly tells when to use (user explicitly asks, or after exhausting help) and when not to use (routine questions, internal issues, questions not tried). Provides clear guidance on appropriate 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?

Discloses atomic default behavior, pre-validation, skip-on-error, dry-run, and experiment acknowledgment. Adds context beyond annotations, which only provide readOnlyHint, destructiveHint, idempotentHint.

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?

5 sentences, front-loaded with main purpose. Every sentence adds value. No redundancy.

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

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

Covers key behaviors, error handling, and return format. Despite no output schema, description suffices for selection and invocation.

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

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

Adds meaning beyond schema: bulk variant, atomic by default, pre-validation, return structure. Schema covers 71% of params, description compensates with behavioral context.

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

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

Explicitly states it's for bulk-creating up to 100 positive keywords to an ad group. Distinguishes from addKeyword by calling itself the bulk variant. No ambiguity.

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

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

Explains when to use (bulk creation) and key options (continueOnError, dryRun). Implicitly distinguishes from single-keyword tool. Lacks explicit when-not or alternative guidance.

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

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

Discloses atomic default behavior, pre-validation, and the effect of continueOnError. Annotations already indicate destructive and idempotent, but description adds value with atomicity and error handling 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?

Five concise sentences that are well-structured and front-loaded with the core functionality. No unnecessary words.

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

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

Covers atomicity, validation, error handling, and return results. Lacks explicit output schema but mentions per-keyword results with changeIds, which is adequate 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 coverage is high (80%), but description adds meaning for dryRun, continueOnError, and the positive keyword constraint, which are not fully captured in parameter 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 verb 'Pause', the resource 'POSITIVE keywords', and scope 'up to 100 in one call'. It distinguishes from sibling tools like pauseKeyword and provides explicit handling for negative keywords.

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 not to use (for negative keywords) and provides alternative tool names. Also explains the use of continueOnError and dryRun for different 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?

Adds significant detail beyond annotations: atomicity, pre-validation, continueOnError behavior, dry run, guardrails, and per-keyword results with changeIds. Contradicts no annotations (destructiveHint=true is consistent).

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, front-loaded with core action, then explanations. Every sentence adds value; no redundant or missing 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?

No output schema, but description covers return value and error behavior. Explains pre-validation, guardrails, and references setGuardrails. Complete for a bulk 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 description coverage is 80%, high. Description clarifies guardrail cap and acknowledgeExperimentImpact as a danger override, adding 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 'Update up to 50 keyword bids in one call,' specifying verb and resource. It distinguishes from siblings like 'updateBid' (single) and other bulk operations (add, pause) by focusing on bid updates.

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

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

Provides context for flags (continueOnError, dryRun) and guardrails, including iterative multi-step ramps. While it doesn't explicitly say when not to use, the bulk vs single distinction is clear from sibling 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?

Annotations indicate idempotentHint true, but the description does not elaborate on what that means (e.g., no duplicate creation). It mentions returning changeId, but fails to disclose important behavioral aspects like the acknowledgeExperimentImpact parameter, which is a 'danger override' noted only in 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 with no waste. Essential information is front-loaded: what it creates, optional paths, and return value.

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

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

With 9 parameters, 5 required, and no output schema, the description is too brief. It omits critical context about required fields, the relationship to ad group, and the return format beyond changeId. For a complex creation tool, more completeness is needed.

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 78%, so the schema already documents most parameters. The description adds value by explaining display URL paths (path1/path2) with an example, but does not clarify other parameters like accountId, campaignId, or the required arrays.

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

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

The description clearly states it creates a Responsive Search Ad in an ad group, which is specific and distinct from sibling tools that create other resources (e.g., campaigns, ad groups, keywords). It uses a specific verb+resource combination.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclude scenarios. Given the many sibling creation tools, explicit usage guidelines are lacking.

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 readOnlyHint, idempotentHint, and destructiveHint. The description adds that the ad group starts enabled and returns changeId, offering some behavioral context beyond annotations. However, it doesn't mention the 'danger override' parameter or permissions needed.

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

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

Single sentence of 10 words, no fluff. Front-loaded with action and key details (initial state, return value). 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?

Adequate for a simple creation tool with 4 params and no output schema. Covers core function, initial state, and return type. Lacks mention of the dangerous parameter and accountId optionality, but overall sufficient given annotation coverage.

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, the description adds no parameter explanations. It does not clarify campaignId or adGroupName beyond what the schema shows. The schema itself documents accountId and acknowledgeExperimentImpact, so the description adds minimal value.

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

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

The description clearly states the verb 'create' and the resource 'ad group' with the context 'in a campaign', distinguishing it from sibling tools like createCampaign or createAd. The initial state 'starts enabled' adds specificity.

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 over alternatives like updateAdGroup or other creation tools. Missing context on prerequisites (e.g., campaign must exist) or 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?

The description provides comprehensive behavioral details beyond the annotations: it explains that the tool internally creates a SEARCH_CUSTOM experiment, clones the RSA to a trial campaign, patches the clone, and leaves the experiment in SETUP. It warns that RSA assets are atomic and that supplying headlines requires also supplying descriptions. Annotations already indicate idempotentHint=true and destructiveHint=false, and the description does not contradict them.

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 relatively long but well-structured. It starts with the key purpose, then explains the internal process, followed by usage requirements and return values. Some sentences, like the one about Google's verified API path, could be considered extraneous, but overall the information density is appropriate for the tool's complexity.

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

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

Given the tool's complexity (13 parameters, bundles three operations, no output schema), the description is quite complete. It explains the internal mechanics, preconditions, atomicity rules, and even lists the return fields. It also specifies the next step (scheduleExperiment). While it could mention error cases or performance implications, the current level of detail is sufficient 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 covers 77% of parameters with descriptions, so the baseline is 3. The description adds critical usage semantics beyond the schema: it explains that baseAdId must be a Responsive Search Ad, that if headlines are provided, descriptions must also be provided due to atomicity, and that finalUrl is a replacement. It also clarifies the role of suffix and treatmentTrafficSplit defaults. This is valuable contextual 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 explicitly states it is a 'RSA-asset A/B test shortcut' that bundles three operations. It clearly distinguishes from sibling tools like createExperiment and addExperimentArms by mentioning it combines them with asset patching. The verb 'create' is used, and the resource 'AdVariationExperiment' is uniquely described as a way to A/B test an RSA's headlines, descriptions, or final URL.

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 (to A/B test RSA assets) and includes important preconditions such as requiring at least one of headlines, descriptions, or finalUrl. It also notes the atomicity requirement when patching copy. However, it does not explicitly state when not to use it or mention alternatives like createExperiment for non-RSA experiments, but the context is clear from the sibling tools listed.

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 that the campaign starts paused and returns a changeId, which goes beyond annotations. However, it does not clarify idempotency behavior (hinted by annotation) or mention permissions, rate limits, or async behavior.

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

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

The description is concise at three sentences, front-loading the main purpose. Every sentence adds necessary context (purpose, App ID requirement, asset note, paused state, return 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?

The description covers core creation details but lacks prerequisites (e.g., app store listing) and fails to explain the default bidding strategy or the absence of output schema. For a complex tool with 12 params, more guidance on post-creation steps would improve completeness.

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

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

With 92% schema coverage, the description adds little extra value for parameters. It mentions App ID requirement and asset handling, but does not significantly deepen understanding beyond the schema's parameter 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 install-focused app campaign for Apple App Store or Google Play Store. It includes specific details like requiring App ID and starting paused, which distinguishes it from other campaign creation tools.

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

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

The description mentions adding assets manually via UI, implying the tool only creates the campaign structure. However, it does not explicitly differentiate from sibling tools like createCampaign or createVideoCampaign, nor does it specify when to use this tool over 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?

Discloses return values (changeId + biddingStrategyId) and conditional parameter requirements. Annotations indicate idempotentHint=true, which is not contradicted but could be clarified.

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?

Four sentences, front-loaded with main purpose, no unnecessary words. Each 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?

Complete for a creation tool: covers purpose, parameters, return values, and references sibling tool for next step. Output schema not needed.

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?

Adds context beyond schema: explains that targetCpa is required for TARGET_CPA, targetRoas for TARGET_ROAS, and specifies units (dollars, multiplier). Schema coverage is 80%.

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 portfolio bidding strategy' and lists supported types (TARGET_CPA, TARGET_ROAS, etc.), distinguishing it from siblings like linkCampaignToBiddingStrategy and updateBiddingStrategy.

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?

It specifies when to use this tool and notes that linkCampaignToBiddingStrategy should be used to attach to campaigns. It also provides conditional requirements per type.

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

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

Annotations indicate a write operation (readOnlyHint=false, destructiveHint=false) and idempotent. The description adds valuable behavioral details: atomic mutate, default call conversion reporting state, and return values (changeId, assetId, link resource names). 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 is a single short paragraph of about 4 sentences, front-loading the main action. It is concise but could benefit from clearer separation of sections (e.g., when to use, return values).

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 100% schema coverage and no output schema, the description adequately covers the tool's behavior, including return values and default state. It complements the schema well, though it could mention potential side effects or prerequisites.

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 the schema already documents parameters well. The description adds minimal extra meaning beyond the schema, such as emphasizing atomic linking. No significant new parameter insights beyond what the schema provides.

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

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

The description clearly states the tool creates a call asset with phone number and country code, and optionally links it to targets. It distinguishes from sibling asset creation tools (e.g., createCalloutAsset) by specifying phone number and call tracking context.

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

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

The description mentions call assets display phone numbers and enable call tracking, implying use case, but does not explicitly compare to alternatives or state when not to use. It provides some guidance on target level restrictions (no asset_group) but lacks clear when-to-use vs. siblings.

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

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

Discloses that the operation is an atomic mutate, returns changeId/assetId/link resource names, and includes a 'danger override' parameter for experiments. Annotations already indicate idempotent and non-destructive; description adds valuable context about what is returned and the safety override.

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 a code reference to `targets` and `linkAsset`. Front-loaded with the primary action and constraint. 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?

Covers all critical aspects: purpose, constraint, linking options, return values, alternative tool, and the acknowledgeExperimentImpact parameter. No output schema is needed as return values are described.

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. The description summarizes the parameters but does not add substantial new meaning beyond the schema. The linking guidance is helpful but not required.

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

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

The description explicitly states 'Create a callout asset' with a clear example and maximum length constraint. It differentiates from sibling tools like createSitelinkAsset and createCallAsset by specifying the exact 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?

Provides explicit guidance on when to use this tool vs. linkAsset: use this to create and optionally link in one mutate, and linkAsset for attaching to more targets later. Also specifies the character limit.

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?

Adds behavioral context beyond annotations: campaign starts paused and returns changeId. Annotations already indicate it's a mutation (readOnlyHint=false) but not destructive. Description doesn't 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?

Three sentences: first states purpose, second provides state and return value, third lists alternatives. Front-loaded and 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?

Covers creation, state, return, and alternatives. Missing minor details like ad group naming convention, but overall sufficient for an agent given complexity (11 params, nested objects).

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 91%, so schema handles parameter documentation. Description only mentions components (budget, ad group, etc.) without adding extra meaning to individual 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?

Description specifies 'Create a Search campaign' with clear components (budget, ad group, keywords, Responsive Search Ad). It distinguishes from siblings by listing separate tools for other campaign types (createShoppingCampaign, 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?

States campaign starts PAUSED and directs to use enableCampaign.goLive. Also lists alternative tools for non-Search campaign types, providing explicit when-not-to-use guidance.

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

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

Description mentions return value and optional ECFL, but contradicts idempotentHint=true by using 'create' which typically implies non-idempotent. No disclosure of permissions, rate limits, or duplication behavior.

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

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

Two sentences, front-loaded with purpose, no redundant text. Efficient and clear.

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

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

For a tool with 12 parameters and many enums, the description is too brief. Missing explanation of type differences, defaults, countingType, etc. Agent may need more context to select correct 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 coverage is 83%, so baseline 3. Description adds only 'returns changeId' and optional ECFL, which is already in schema. No extra meaning for other 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?

Description clearly states it creates a conversion action for offline, web, or call tracking. It distinguishes from most siblings by specifying the resource verb, but doesn't explicitly differentiate from updateConversionAction.

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?

Implied usage for tracking conversions, but no explicit guidance on when not to use or alternatives (e.g., updateConversionAction for existing actions, uploadClickConversions for sending data).

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 idempotent and non-destructive hints. The description adds that the campaign starts PAUSED and returns a changeId, which is useful behavioral 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?

The description is concise, with two sentences front-loaded with the core purpose and key behavioral details. 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?

Given the complexity (11 params, no output schema), the description adequately covers platform, campaign type, initial status, and return value. It also hints at needing to add image assets in UI. Could mention additional steps but is 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 91%, so parameters are well-documented. The description adds minimal extra meaning beyond the schema, but mentions the campaign starts paused and returns changeId, which are not 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 creates a Demand Gen campaign serving on YouTube/Gmail/Discover, which is distinct from sibling tools like createCampaign (generic) or createVideoCampaign.

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?

It implies usage for Demand Gen campaigns but does not provide explicit when-to-use or when-not-to-use guidance compared to other campaign creation tools. No alternatives or exclusions are mentioned.

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

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

Adds behavioral details beyond annotations: default PAUSED state and return of changeId. Annotations indicate idempotent hint and non-destructive, but description provides additional context about the tool's operation.

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

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

Three sentences, each with key information: purpose, prerequisite, default state, return value. No unnecessary words, front-loaded with the tool's 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?

Covers main purpose, prerequisites, default state, and return value. However, given the complexity (15 parameters, nested objects, no output schema), it could also mention how bidding defaults work or what the full response structure is. Still, it provides a solid overview.

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 high (93%), and parameter descriptions in schema are already detailed. The description only adds emphasis on image asset prerequisites, offering minimal extra meaning beyond what the schema provides.

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

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

Description clearly states it creates a Display Network campaign with a Responsive Display Ad, distinguishing it from other campaign creation siblings. Specifically outlines prerequisites, default state (PAUSED), and return value (changeId).

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 provides a prerequisite (upload image assets first via createImageAsset) but does not explicitly contrast with alternatives like createCampaign, createVideoCampaign, etc. The context is clear but lacks explicit when-to-use vs when-not-to-use guidance.

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

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

Annotations indicate readOnlyHint false (write operation) and destructiveHint false. The description adds that it creates in SETUP status and doesn't serve traffic until scheduleExperiment. This provides clear behavioral 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 with three sentences, front-loading the purpose and key workflow steps. Every sentence adds essential information with no redundancy.

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

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

Given the tool's complexity (8 parameters, no output schema), the description covers the entire workflow, type selection, status, and next steps. It is sufficiently complete for an agent to understand how to invoke it correctly.

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

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

Schema description coverage is high (88%), so baseline is 3. The description adds value by explaining the type enum values with concrete use cases and noting the recommended start/end date guidance (e.g., ≥14 days for significance). This is meaningful extra context.

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

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

The description clearly states it creates a Google Ads experiment in SETUP status and is Step 1 of 5. It specifies the verb 'create' and the resource 'Google Ads experiment', distinguishing it from sibling tools like addExperimentArms, scheduleExperiment, 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?

The description explicitly explains when to use this tool (as first step), what to do next (addExperimentArms), and when to use each type parameter (SEARCH_CUSTOM vs SEARCH_AUTOMATED_BIDDING_STRATEGY). It also clarifies that traffic doesn't serve until scheduleExperiment is called.

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=false, destructiveHint=false, and idempotentHint=true. The description adds behavioral info: image type restrictions (PNG/JPEG), URL format, max 5 MB, serving slot constraints, and the effect of acknowledgeExperimentImpact. It does not contradict annotations and provides transparency about mutation behavior.

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

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

The description is slightly long (4 sentences) but every sentence adds value. It is front-loaded with the core purpose and includes necessary details. Could be slightly more compact, but still concise given the complexity.

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

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

No output schema, but the description covers return values (changeId, assetId, link resource names). It addresses input format, field type selection, target linking, and experiment impact. It is fully adequate for a 6-parameter image asset creation tool with rich annotations.

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 descriptions for all parameters. The description adds meaning beyond the schema: it clarifies that targets should be objects with a level discriminator (not bare resource strings), explains dimension requirements per fieldType, and warns about acknowledgeExperimentImpact. This significantly aids 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 the tool uploads a PNG/JPEG image from an HTTPS URL, and specifies field types based on serving slot (MARKETING_IMAGE, SQUARE_MARKETING_IMAGE, AD_IMAGE). It distinguishes itself from sibling tools like createCallAsset and createSitelinkAsset by focusing on images, and mentions return values (changeId, assetId, link resource names).

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

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

The description provides explicit guidance on when to use each fieldType based on serving slot, including dimension requirements and supported levels. It also differentiates this tool from linkAsset by noting that to attach an existing image to more targets later, one should call linkAsset. This gives clear context for 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 mutation (readOnlyHint=false), idempotentHint=true, and not destructive. The description adds the return format (changeId + sharedSetId) but does not disclose any additional behavioral traits (e.g., uniqueness of list name, potential idempotency issues). The coverage is adequate but not exceptional.

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 purpose, then workflow. 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?

No output schema, but description mentions return values (changeId + sharedSetId). It covers the creation step and points to next steps. For a simple creation tool, this is complete. Could add a note about idempotency or naming constraints, but not necessary.

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 both parameters documented. The description does not add meaning beyond the schema (e.g., no explanation of what 'shared' implies or how accountId works beyond 'omit for primary'). Baseline score of 3 is appropriate since schema does the heavy lifting.

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 shared negative keyword list' with a specific verb and resource. It distinguishes from sibling tools like addKeywordToNegativeList and linkNegativeListToCampaign by focusing on creation and mentioning the return of changeId and sharedSetId.

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

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

The description explicitly tells the user what to do after creation: 'After creating, add keywords with addKeywordToNegativeList and link to campaigns with linkNegativeListToCampaign.' This provides clear guidance on when to use this tool versus its siblings.

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

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

Annotations indicate idempotent and non-destructive. The description adds that the campaign starts PAUSED and requires manual asset addition before full serving, which is crucial behavioral context that annotations do not cover. No 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 three sentences, front-loaded with the main purpose, and each sentence adds distinct value. No fluff or repetition.

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

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

Given 13 parameters and no output schema, the description covers key behaviors (paused state, retail linking, manual asset step). It mentions the return of changeId. It is sufficient for an agent to understand how to invoke the tool correctly.

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

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

With 92% schema coverage, parameters are already well-described in the schema. The description adds value by linking merchantId and salesCountry for retail PMax, and implying that finalUrl and other basics are standard. This provides meaningful context beyond the schema.

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

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

The description clearly states the tool creates a Performance Max campaign, which differs from other campaign types. It specifies that it serves across all Google channels via asset groups and mentions the retail variant with merchantId+salesCountry. This leaves no ambiguity about the tool's function.

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 contextual guidance for retail PMax (requiring merchantId+salesCountry) and notes that the campaign starts PAUSED with a need to add assets manually. However, it does not explicitly compare to sibling tools or state when not to use this tool, leaving some ambiguity.

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 non-readOnly, non-destructive, idempotent. The description adds that the campaign starts PAUSED and returns a changeId, which are behavioral details 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?

Three sentences, each adding value: purpose, optional parameter, and initial state/return. 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 no output schema, the description covers return (changeId). It explains key aspects: campaign type, linking to feed, initial state, and optional filter. Missing explicit mention of required parameters, but schema covers that.

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 92%, so baseline is 3. The description adds context for inventoryFilter (scopes to product_type or custom_label) but does not significantly enhance understanding of other parameters beyond the schema.

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

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

The description clearly states the tool creates a Standard Shopping campaign linked to a Merchant Center feed, which is a specific verb+resource. It distinguishes from sibling tools like createCampaign, createAppCampaign, 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?

The description mentions 'Standard Shopping' but does not provide explicit guidance on when to use this tool versus alternatives like createAppCampaign or createVideoCampaign. No when-not or alternative tool suggestions.

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 the tool as non-read-only (readOnlyHint=false), non-destructive, and idempotent. The description adds context: it creates a new asset, returns changeId, assetId, and link resource names, and enforces character limits and pairing requirements. 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?

Description is four sentences, front-loaded with purpose, then constraints, then return values, then a pointer to an alternative tool. No extraneous information. Every sentence is necessary and earns its place.

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

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

Given 100% schema coverage and no output schema, the description covers key behavioral aspects: what it creates, constraints, optional linking, return fields, and related tool. Missing details like error cases or behavior for invalid targets, but these are typical and not essential for a creation tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by summarizing the pairing requirement for descriptions (which is already in schema but reinforced) and by explaining the targets structure: 'Each target is an OBJECT with a `level` discriminator — bare resource strings are rejected.' This reduces ambiguity beyond what the schema descriptions provide.

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 sitelink asset' with specific resource components (link text, URL, optional description pair). Distinguishes from sibling asset creation tools (call, callout, structured snippet) by mentioning sitelink-specific constraints like text ≤25 chars and description pairing. Also references linking via targets, which is unique to sitelinks.

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 explicitly says when to use (to create a sitelink asset) and provides an alternative: 'To attach an existing sitelink to more targets later, call linkAsset.' It also clarifies that descriptions must be provided as a pair, guiding correct usage. Lacks explicit 'when not to use' for other asset types, but the sibling list implies 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 value beyond annotations by detailing return values (changeId, assetId, link resource names) and alias handling. Annotations already provide idempotentHint=true, and the description does not contradict any 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 and front-loaded, covering the core action, constraints, optional parameters, and cross-reference in two sentences. No superfluous 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 parameter count and no output schema, the description fully covers creation, constraints, optional linking, return values, and points to a sibling tool for further actions. It is complete for an agent to use correctly.

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

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

With 100% schema coverage, the baseline is 3. The description adds meaning by summarizing header aliases, value length constraints, and target structure examples, providing practical context beyond the schema.

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

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

The description explicitly states the tool creates a structured snippet asset, specifying the header and value constraints and optional target linking. It clearly distinguishes from sibling tools like createCalloutAsset or createSitelinkAsset by naming the asset 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 indicates when to use this tool (creating a structured snippet) and points to linkAsset for subsequent target linking. However, it does not explicitly exclude usage for other asset types or provide alternatives for similar tasks.

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

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

Beyond annotations (which indicate a non-destructive, idempotent write), the description adds that the campaign starts PAUSED and returns a changeId. It could mention potential rate limits or authentication needs, but provides useful 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?

Three concise sentences, each adding essential information: action, prerequisite, behavior, and output. No filler or redundancy.

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

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

Given the tool's complexity (13 parameters, nested bidding object) and no output schema, the description covers key return value and default state. It omits minor details like default bidding strategy, but that is in the schema.

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

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

Schema description coverage is 92%, and the schema descriptions are detailed (e.g., youtubeVideoId explains how to derive the ID). The description adds no extra parameter meaning beyond stating requirements, so it meets the baseline for high 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 it creates a 'YouTube TrueView in-stream video campaign', which is a specific resource. It also adds key constraints (requires existing YouTube video ID, starts PAUSED) and return value (changeId), distinguishing it from sibling campaign creation tools.

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

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

The description provides a clear prerequisite ('Requires an existing YouTube video ID') and behavioral note ('Starts PAUSED'), implying when to use. However, it does not explicitly contrast with sibling tools (e.g., when to use createCampaign instead).

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 idempotentHint=true and destructiveHint=false; the description adds that the tool returns a changeId and implies mutation, but it omits side effects like what happens if the ad is already enabled or whether specific permissions are needed.

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

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

The description is exceptionally concise with two short sentences, front-loading the action and return value without extraneous text.

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

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

Given 5 parameters and no output schema, the description lacks prerequisites (e.g., ad must be paused), parameter dependencies (campaignId, adGroupId, adId), and the impact of acknowledgeExperimentImpact, leaving the agent underinformed.

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 no parameter-level meaning, failing to compensate for undocumented parameters (e.g., adId, accountId) or explain acknowledgeExperimentImpact's 'Danger override' context.

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

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

The description 'Re-enable a paused ad. Returns changeId.' clearly states the verb (re-enable), the resource (paused ad), and the return value, distinguishing it from sibling tools like pauseAd, removeAd, 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 provides no guidance on when to use this tool versus alternatives such as enableCampaign or enableKeyword, nor does it mention prerequisites or exclusion criteria.

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

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

Annotations indicate mutation, idempotent, non-destructive. The description adds the return value (changeId) but does not disclose behavior like whether calling on an already-enabled campaign has no effect or if the 'acknowledgeExperimentImpact' parameter exists. 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?

Single sentence delivering purpose and return value with no unnecessary words. 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 3 parameters and annotations, the description omits important context like prerequisites (campaign must be paused), effects of the 'acknowledgeExperimentImpact' parameter, and behavior when called on non-paused campaigns. Incomplete for safe usage.

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

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

The description does not explain any parameters. Schema covers 2 of 3 parameters (67%), but the required 'campaignId' lacks description. Without tool description help, agents may misuse the required 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 re-enables a paused campaign and returns a changeId. It effectively differentiates from siblings like pauseCampaign and removeCampaign.

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

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

The description implies usage context (only for paused campaigns) but does not explicitly mention when not to use it or suggest alternatives. It is clear enough for basic guidance.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false; description adds that it returns a changeId. No contradiction. Could be improved by noting idempotency or error conditions, but sufficient 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?

Two concise sentences: first states purpose, second adds usage nuance and return value. Every word earns its place; 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?

Describes return value (changeId) but doesn't mention prerequisites (e.g., keyword must be paused), error states, or idempotency behavior. Acceptable for a simple action but leaves gaps for more robust help.

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 67% (adGroupId lacks description). Description explains required params (adGroupId + criterionId) and provides context for criterionId (query via runScript). Partially compensates for missing schema description, but adGroupId remains 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?

Description clearly states 'Re-enable a paused keyword' – a specific verb and resource. Distinguishes from sibling tools like pauseKeyword by mentioning the different parameter requirements.

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 'Only needs adGroupId + criterionId (no campaignId, unlike pauseKeyword)', providing clear context on when to use this tool versus an alternative. Lacks explicit when-not-to-use guidance, e.g., if keyword is already enabled.

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 details beyond the annotations: it confirms the tool is a mutation that is idempotent and not destructive, and it explains the 'changeId' return for undo support. 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 is extremely concise with two sentences that contain all necessary information without any fluff. Every word earns its place.

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

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

Given the tool's complexity (4 parameters, no output schema), the description is fairly complete. It covers the action, prerequisites, and return value. The 'acknowledgeExperimentImpact' parameter is well-documented in the schema, so its omission 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?

The schema already provides 100% coverage for all 4 parameters. The description adds minimal extra context for 'assetGroupId' (suggesting a query via runScript), which is helpful but not substantial. 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?

The description clearly states the action ('Re-enable') and the resource ('a paused Performance Max asset group'), with the purpose 'so it can serve ads again'. It effectively distinguishes this tool from its sibling 'pausePmaxAssetGroup'.

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?

It provides clear guidance on how to find asset group IDs using 'getPmaxAssetGroups', and mentions the return of a 'changeId' for undo support. While it doesn't explicitly state when not to use the tool, the context of re-enabling a paused group is well implied.

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

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

Adds that trial keeps state but stops traffic, and returns changeId. Does not contradict annotations; provides useful context beyond readOnlyHint/destructiveHint.

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 with no fluff; 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?

Fully covers purpose, usage, preconditions, and return value for a tool with 2 parameters and no output schema.

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

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

Adds precondition for status and return value, complementing schema's descriptions (50% 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 it stops an experiment immediately without applying changes, distinguishing it from graduateExperiment/promoteExperiment.

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 (enough data, don't want changes) and status precondition (ENABLED/INITIATED/HALTED).

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 states it stores an evaluation row (a write operation), but annotations declare readOnlyHint=true, creating a contradiction. It does not disclose permissions, reversibility, or other side effects beyond storing.

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?

One sentence efficiently conveys the tool's action and outputs without 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?

No output schema, so description should explain return format ('conservative verdict' is vague). Missing details on errors, prerequisites, and expected outcomes.

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 (25%). The description hints at baselineWindowDays and afterWindowDays via '7-day before window' and 'post-change window', but does not explain parameter semantics fully. accountId is only parameter with 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 evaluates an Impact Monitor intervention by comparing time windows, counting confounders, storing results, and returning a verdict. It distinguishes from sibling tools like getChangeIntervention and reviewChangeImpact.

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

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

No explicit guidance on when to use this tool vs alternatives like reviewChangeImpact or getChangeIntervention. The description implies it's for evaluation after a change, but does not mention exclusions or prerequisites.

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

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

The description discloses behavioral traits beyond annotations: it states filing is a single tool call, does not need user permission, should be done immediately at the moment of friction, and has a volume limit of 5 per session. It also reveals that submissions go directly to the NotFair team and the user does not see the channel. No contradiction with annotations (readOnlyHint=false, destructiveHint=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?

The description is relatively long but well-structured with clear sections: purpose, exclusions, auto-surface triggers, timing rules. Every sentence adds useful information. Slight redundancy (e.g., 'not customer support' repeated) but overall front-loaded with the core 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 no output schema and the tool's nature (internal feedback submission), the description covers all necessary context: what happens when filed (goes to team, user doesn't see), volume limits, timing, and what to avoid. It is comprehensive 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 is 100% with detailed parameter descriptions (e.g., category enum, maxLength constraints). The description enhances the parameter usage by providing context like 'Be specific. Reference tools by name and propose a concrete change.' It adds value beyond the schema by guiding how to fill the fields effectively.

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

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

The description clearly states the tool's purpose: 'Internal NotFair tool-feedback channel. Privately report MCP/tool friction...' It uses a specific verb ('report') and resource ('tool-feedback channel'), and it distinguishes itself from customer support and user feedback. No sibling tool serves a similar function.

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 the tool (e.g., 'AUTO-SURFACE THIS WHEN' list with five scenarios) and when not to use it (DO NOT call for individual operation errors, confirming success, etc.). It also clarifies that it's an internal engineering signal and not to be announced to the user.

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 this is not read-only, not idempotent, and not destructive. The description adds important behavioral details: counts against monthly quota, precise latency estimates for each quality level, and output format/background constraints. It does not cover authorization or side effects beyond quota, hence 4.

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

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

The description is lengthy but well-structured with clear sections (Prompt craft, Ad-policy rules, Aspect ratios, etc.). Every section adds value for the agent. Slight wordiness in prompt advice reduces conciseness, but overall it earns its length.

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

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

Given the complexity of image generation with platform-specific rules and multiple parameters, the description is remarkably complete. It includes practical ad compliance guidance and integration hints. Absence of output schema is mitigated because return value (public URL) is simple and clearly stated.

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 100% schema coverage, baseline is 3. However, the description adds substantial context beyond schema: detailed quality pipeline explanation, platform-specific aspect ratio advice, background handling rules, and model override options. This significantly enhances parameter understanding.

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 'Generate one image from a prompt using OpenAI GPT Image 2.' and specifies the return type as a public URL. It distinctly separates itself from sibling tools, which are all ad management operations, by focusing on image generation.

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 guidance on prompt crafting, ad-policy rules, aspect ratio recommendations per platform, and quality-latency tradeoffs. It also mentions downstream integration with creative-asset tools, giving clear context for when to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explicitly stating 'Pure read — does not mutate' and describing the return format, which provides behavioral 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 two sentences long, with the first sentence defining the purpose and scope and the second providing usage guidance and return type. Every sentence is necessary and contributes clear information without redundancy.

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

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

Despite lacking an output schema, the description explains the return array structure with four fields. It covers the tool's purpose, usage, and safety, but does not address potential errors or edge cases for a simple list tool.

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

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

Schema coverage is 100%, with both parameters having descriptive definitions. The description does not add additional meaning beyond what the schema provides, so it meets the baseline of 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?

The description starts with a specific verb 'List' and identifies the resource 'links for an asset' across all four levels, clearly distinguishing it from sibling tools like 'linkAsset' and 'unlinkAssetLinks' by noting its read-only discovery purpose.

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

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

The description explicitly states to use this tool before 'unlinkAssetLinks' to discover link resource names, and notes it is a pure read operation. While it provides clear context, it could be more explicit about when not to use it beyond stating its read-only nature.

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

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

Annotations indicate readOnlyHint=true, so this is a safe read operation. The description adds that it returns linked operations and latest evaluation, providing useful behavioral 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?

Single sentence with clear verb and resource, front-loaded with key information. No unnecessary words.

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

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

No output schema, but description mentions returned linked operations and latest evaluation, which is helpful. Low parameter count and simple structure mean the description covers the essentials, though it could benefit from more return value details.

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

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

Schema coverage is 50%: accountId is described, but changeInterventionId only has type and constraints. The description does not add any parameter-level explanation, leaving ambiguity about what changeInterventionId is or where to find it.

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 it retrieves a single Impact Monitor intervention along with its linked operations and latest evaluation. This is specific and distinguishes from listChangeInterventions (list) and evaluateChangeIntervention (evaluate).

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. It implies use when needing details of a specific intervention, but does not contrast with alternatives like listChangeInterventions or evaluateChangeIntervention.

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 context about reading NotFair's internal Postgres log and explains changeGroups to prevent misinterpretation of bulk edits, going beyond annotations 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 front-loaded with the main purpose and provides essential details in a few sentences. It is concise but could be more structured (e.g., bullet points for parameters). 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?

Explains return value (changeId, changeGroups) and data source, and provides alternative for Google-side changes. However, without an output schema, more details about the structure of changes and changeGroups would improve completeness.

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

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

Schema description coverage is only 33% (accountId has a description, limit and campaignId do not). The description does not elaborate on how parameters affect the output, leaving the agent with incomplete parameter understanding.

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 returns recent changes made to the account via NotFair, distinguishes it from Google's change_event API, and mentions changeId and changeGroups. It effectively differentiates from sibling tools.

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

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

Explicitly states when to use (get recent changes) and when not to (for Google-side edits, use runScript). Provides clear guidance on the return value and 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 already declare readOnlyHint=true and destructiveHint=false. Description adds value by explaining the fallback behavior (account-level defaults if campaign-specific not set) and specifying the exact fields returned. This provides behavioral context beyond annotations 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?

Extremely concise: two sentences front-loaded with the main action. Every sentence adds essential information without redundancy. No filler words or vague phrasing.

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

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

Given the tool has no output schema, the description adequately explains the return value (specific fields and hierarchy). It covers scope (campaign vs account) and content. Lacks mention of error scenarios or pagination, but for a simple read operation, it is complete enough.

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 (accountId and campaignId). The tool description does not add significant new meaning beyond the schema, such as format or constraints. Baseline 3 is appropriate as schema covers parameter semantics 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 the verb 'Get' and resource 'guardrail limits'. Specifies what is returned (campaign-specific vs account-level defaults) and enumerates the fields shown (target CPA, monthly cap, max change percentages). Differentiates from sibling tools like setGuardrails by focusing on read-only retrieval.

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

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

Description implies use when checking guardrails, but does not explicitly state when to use or not use this tool versus alternatives like setGuardrails. No mention of prerequisites or context like 'use this to view before setting limits.' Lacks explicit guidance for optimal agent decision-making.

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 readOnly and non-destructive. Description adds value by stating no Google Ads account connection required and that it works for all users, clarifying access requirements.

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

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

Four sentences covering purpose, inputs, outputs, and important notes. No redundancy, well 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?

Without output schema, description compensates by listing return fields. Covers inputs, prerequisites, and clarifies that it's a separate API. No gaps for a 5-param 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?

Despite 100% schema coverage, description adds context: explains that seed keywords and URL can be combined, clarifies how to use geoTargetIds with searchGeoTargets, and describes return values (avg monthly searches, competition, CPC, bids).

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 gets keyword ideas with real data from Google Ads Keyword Planner, listing specific metrics. It distinguishes from sibling tools like runScript by explicitly noting it's a separate API and should be used instead.

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 when to use (discover keyword opportunities) and prerequisites (use searchGeoTargets first). Mentions alternative (runScript) and advises not to use it. Lacks explicit 'when not to use' beyond that.

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, indicating safe read-only behavior. The description adds context about the return values (field metadata) but does not detail other behavioral aspects like rate limits or response size. This is adequate given 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 with two sentences and an example, front-loading the key information (discover fields). Every sentence adds value, and the structure is 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 discovery tool with two parameters and no output schema, the description is complete. It explains what the tool returns, when to use it, and provides an example, leaving no critical gaps.

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

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

The input schema covers both parameters with descriptions (100% coverage). The description adds examples for resourceName (e.g., 'campaign') but does not significantly extend the schema. 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?

The description clearly states the tool's purpose: discovering available fields for a GAQL resource. It specifies the return values (selectable, filterable, sortable fields with data types) and distinguishes itself from sibling tools like runScript by advising to call it before querying an unfamiliar resource.

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 advises calling this tool before writing a runScript that queries an unfamiliar resource, providing clear context for use. It does not list alternatives or exclusions, but the guidance is sufficient for correct 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 declare readOnlyHint=true and destructiveHint=false, so the description's behavioral burden is lower. The description adds that the data is monthly and account-specific, but does not disclose details like data freshness, rate limits, or whether historical trend data is available. It provides moderate additional context.

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

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

The description is a single, concise sentence of 12 words that immediately conveys the purpose. Every word adds value; no redundancy.

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

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

Given no parameters, no output schema, and simple safety annotations, the description sufficiently explains the tool's output scope (quota and usage). It could further specify the output format (e.g., integers, percentages), but it is largely complete for its 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?

There are zero parameters, and the schema coverage is 100% (nothing to cover). The description does not need to add parameter info. Baseline for 0 parameters is 4.

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

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

The description uses a specific verb 'Show' and clearly identifies the resource as 'current monthly image generation quota and usage for this account'. This distinguishes it well from sibling tools, which are primarily for creating, updating, or managing campaigns and assets, not for quota display.

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

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

The description implicitly states when to use (to check quota/usage), but lacks explicit guidance on when not to use or mention of alternatives. However, given its unique purpose among siblings and zero parameters, the context is clear enough.

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

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

Annotations provide idempotentHint true, destructiveHint false. Description adds that it's permanent, returns changeId, and requires enabled experiment. No contradiction with annotations, though idempotency is not explicitly discussed.

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 concise sentences. First states action, second clarifies what agent must supply and that resource is auto-resolved, third gives usage guidance and precondition. 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?

Covers purpose, usage, and return type (changeId). However, parameter mismatch weakens completeness. No output schema but return value mentioned. Sibling differentiation is implicit but not explicit.

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

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

Description says agent only needs to supply new budget, implying experimentResourceName is auto-resolved, but schema requires it as a required parameter. This contradicts schema and could mislead. Schema covers accountId and campaignBudgetResourceName, but experimentResourceName lacks description. Description adds little value beyond schema for 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?

Description clearly states it permanently forks a trial campaign into a standalone campaign alongside the base. Distinguishes from siblings like promoteExperiment by specifying that both control and treatment are retained.

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 when both control and treatment are valuable and you want to keep them running independently. Also gives status precondition (experiment must be ENABLED). Lacks exclusion criteria or alternatives, but clear enough.

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

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

Discloses atomic mutate, auto-generated asset rejection, return values (changeId and link resource names), and field-type-level interactions beyond what annotations provide (idempotentHint).

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 starts with main action, flows to bulk behavior, field/level details, constraints, and return info. Every sentence adds value without redundancy.

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

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

Covers all essential aspects: purpose, inputs, behavioral rules, return values, error preconditions (auto-generated rejection), and cross-references to unlinkAssetLinks. Adequate for a mutate tool with no output schema.

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

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

Adds significant meaning beyond input schema: enumerates field types, explains target level discriminator shapes, notes accountId default, and warns about acknowledgeExperimentImpact. Schema coverage is 100%, but description enriches semantics.

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

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

Description clearly states the tool links an existing asset to serving targets atomically. Differentiates from sibling tools like unlinkAssetLinks and getAssetLinks by specifying the action and inputs.

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 explains bulk-by-default behavior, provides alternative tool (unlinkAssetLinks) for removals, and describes level support constraints per field type, guiding correct 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?

Description discloses that linking replaces existing campaign-level bidding config, which is a key behavioral trait. It does not contradict annotations (idempotent, not destructive). Additional details like return value (changeId) add value 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 concise sentences that front-load the purpose, provide key behavioral info, a usage tip, and return value. 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 adequately states returns changeId. It covers main purpose, effect, and one parameter hint. Missing details on error conditions or permissions, but for a straightforward linking action, 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 50% schema description coverage, the description adds value for biddingStrategyId by referencing listBiddingStrategies. However, campaignId lacks any additional explanation. The description does not fully compensate for the schema gaps in the two undocumented 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?

Description clearly states the tool links a campaign to a portfolio bidding strategy, specifies it replaces standard bidding config, and includes a sibling hint (listBiddingStrategies). This distinguishes it from other bidding tools like createBiddingStrategy or updateBiddingStrategy.

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 provides context on when to use (to apply shared strategy) and mentions listBiddingStrategies for ID lookup. However, it does not explicitly specify when not to use or compare with alternatives like updateCampaignBidding, which would strengthen guidance.

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

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

Annotations provide idempotentHint=true and destructiveHint=false. Description adds that it links and blocks keywords, but doesn't discuss behavior if list already linked, experiment implications (though acknowledged in parameter), or error conditions. 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?

Two sentences, front-loaded with the verb and resource. Every sentence adds value. No extraneous information.

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

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

Missing context about prerequisites (list must exist, campaign must exist), experiment side effects (only in parameter description), and idempotency behavior. Minimal for a mutation tool with 4 parameters.

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

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

Schema coverage is 75%. Description does not elaborate on parameters; the action implies campaignId and sharedSetId. No additional semantics beyond schema.

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

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

Description clearly states the action (link a shared negative keyword list to a campaign), its effect (keywords blocked), and return value (changeId). Distinguishes from siblings like 'unlinkNegativeListFromCampaign' and 'addNegativeKeyword'.

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

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

No explicit guidance on when to use this tool vs alternatives. No prerequisites or conditions mentioned. Parameter descriptions hint at experiment impact but the main description omits this 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns only enabled experiments, and lists returned fields (campaign IDs, names, traffic split, etc.), going beyond annotations 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?

Two sentences: first defines purpose and output, second provides usage guidance. No wasted words, essential information 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?

No output schema, but description clearly lists returned data. Two parameters are well-documented. Context signals indicate low complexity. Description fully covers what an agent needs to know to invoke 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 is 100% with descriptions for both parameters (days, accountId). The description does not add additional meaning beyond what's in the schema, so baseline 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?

Clear verb+resource: 'View of currently running Google Ads experiments'. Explicitly states it returns ENABLED experiments only, distinguishing from a full raw GAQL approach. Purpose is unambiguous.

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

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

Explicitly states when to use ('before experiment analysis or planning campaign mutations') and when not to ('do not stitch raw experiment + experiment_arm GAQL unless you need historical/removed'). Provides a clear alternative condition.

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 read-only, non-destructive. Description adds return content details (status, summary, etc.) but lacks pagination behavior or any other side effects beyond what annotations cover.

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 efficiently state purpose and return fields with no fluff.

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

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

For a 5-parameter list tool with no output schema, the description omits crucial usage details like pagination, filtering semantics, and parameter explanations, making it incomplete for correct invocation.

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

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

Schema description coverage is only 20% (only accountId has a description). Description does not explain the meaning or usage of the other four parameters, such as status filter or campaignId.

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 interventions grouped at campaign episode level. However, it does not distinguish from sibling tools like getChangeIntervention (singular) or evaluateChangeIntervention.

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, no prerequisites, no context about filtering or accountId optionality.

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 value by specifying that it returns accountIds, which is beyond what annotations provide.

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 purpose, 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?

Description is complete for a simple read-only tool with no parameters. It explains purpose and output, though could mention authentication or 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?

No parameters, so baseline is 4. Description adds meaning by stating it returns accountIds, which is helpful given no output 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 the tool lists Google Ads accounts connected to the session, with a specific verb ('List') and resource ('Google Ads accounts'). Distinguishes from siblings by focusing on listing connected accounts.

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

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

Explicitly indicates that the returned accountIds are for use with all other tools, showing this is a prerequisite. Lacks explicit exclusion or alternatives but provides clear context for 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 confirm read-only behavior; description adds interpretation of empty/non-empty lists and typical failure causes, going 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?

Three sentences, front-loaded with the verb, every sentence adds value. 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?

Fully covers the tool's purpose, expected usage, and result interpretation given the simple input schema and annotations.

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 only 25% schema description coverage, the description does not explain individual parameters, though parameters (pageSize, pageToken, experimentResourceName) are relatively self-explanatory.

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

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

The description clearly states the tool reads errors from the most recent scheduleExperiment or promoteExperiment LRO, which is specific and distinct from sibling tools like createExperiment or promoteExperiment.

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 guidance ('Call this after every scheduleExperiment / promoteExperiment') and explains how to interpret results, but lacks explicit when-not-to-use or alternatives.

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

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

Annotations already indicate read-only and non-destructive. The description adds safety-oriented defaults (positive keywords only, enabled criteria only, excluding REMOVED parents), providing useful behavioral 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?

Three sentences, front-loaded with purpose, then usage guidance, then defaults. No redundant information; every sentence adds value.

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

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

No output schema, but description mentions returning keyword criterion IDs. With high schema coverage and clear defaults, the description is sufficiently complete for this list tool. Minor gap: no mention of pagination or return structure beyond IDs.

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 3 is appropriate. The description does not add per-parameter details but summarizes overall defaults. No contradictions or 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 tool provides a typed keyword inventory for mutation preparation, mentioning specific use cases (bulkPauseKeywords, bulkUpdateBids, moveKeywords). It distinguishes from runScript for performance analysis, 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?

Explicitly says when to use (keyword IDs for mutations, inspecting keyword state) and when not to use (performance analysis, metrics, runScript). This direct guidance helps the agent select the right tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the context of listing resources and a workflow suggestion, but does not detail pagination, response size, or other behavioral traits beyond what annotations provide.

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 succinct sentences: the first states the core purpose with examples, and the second provides the recommended usage flow. Every word adds value, making it 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 listing tool with no output schema and one optional parameter, the description is complete. It explains what the tool returns (queryable resources), how to use it in context with sibling tools, and the parameter is self-explanatory from the schema. No further information is needed.

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 only parameter, accountId, is described in the schema with 'Account ID (omit for primary)'. The description does not add any additional meaning or nuances about this parameter. Since schema coverage is 100%, the 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 it lists all queryable GAQL resources with examples like campaign, ad_group, and keyword_view. It distinguishes itself from sibling tools by referencing pairing with getResourceMetadata and runScript, which directly shows its role in the workflow.

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 guides usage by advising to pair with getResourceMetadata to discover fields and then write a runScript. This provides clear context and distinguishes from sibling tools, though it does not explicitly state 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.