Google Ads MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Several tools overlap in purpose, such as create_sitelink_assets vs create_sitelink_extensions, create_callout_assets vs create_callout_extensions, and get_geographic_report vs get_geographic_performance, which could confuse an agent. However, most tools have distinct resource-action targets and descriptions likely help.
Naming Consistency5/5
All tools consistently follow a verb_noun snake_case pattern (e.g., list_accounts, get_campaigns, create_campaign, update_campaign_status). No mixed conventions or inconsistent verb styles.
Tool Count1/5
With 76 tools, the server far exceeds the reasonable range for a typical MCP server. Many tools are highly granular or redundant (e.g., duplicate extension creation methods), resulting in an overwhelming surface area.
Completeness3/5
The server covers a broad range of Google Ads features but lacks fundamental lifecycle operations such as deleting campaigns/ad groups/ads, updating ad groups, removing keywords, or retrieving single entities. Several resource types have create-only methods without corresponding read/update/delete tools.
Average 2.8/5 across 76 of 76 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'create' but does not explain idempotency, duplicate handling, whether it replaces existing extensions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. It is a single phrase with no useful content, which is not the same as being appropriately minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and minimal parameter documentation. The description fails to provide any context about return values, errors, permissions, or behavioral implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. The schema itself only describes half the parameters (customerId), and the description does not clarify what 'callExtensions' contains or how the fields are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create call extensions' is a direct restatement of the tool name, providing no additional specificity. It does not distinguish this tool from sibling tools like create_sitelink_extensions or create_callout_extensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must disclose side effects, transactional semantics, permissions, or failure behaviors. It contains none of this, leaving the agent completely uninformed about whether operations are atomic, rate-limited, or require special scopes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. While it is only six words, it conveys no information beyond the tool name, failing the 'every sentence earns its place' test and providing no front-loaded value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested operations schema, complete absence of annotations, and no output schema, this description is vastly inadequate. It omits supported resource types, batch size limits, error handling, and output structure, making it nearly impossible to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: customerId has a description but operations has none. The description adds no meaning to the complex operations array structure, leaving resourceType and operationType semantics unexplained, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform bulk edit operations' essentially restates the tool name with a generic verb, offering no specific resource or scope. It fails to distinguish this tool from the many specific edit tools in the sibling list (e.g., update_campaign_status, create_campaign).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this bulk edit tool versus individual create/update/remove tools. There are no exclusions, alternatives, or contextual hints to help an agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but does not. It does not mention that this is a create operation with side effects, required permissions, validation behavior, or post-creation steps. This is a serious omission for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It does not earn its place because it restates the tool name without adding informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a Smart campaign creation tool with 5 parameters and many sibling campaign types, this description is completely inadequate. It provides zero context about the campaign type, required setup, or expected behavior, leaving an agent without enough information to make an informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 5 parameters, so the baseline is 3. The description adds no parameter-specific semantics beyond what the schema already provides; it simply names the tool's purpose without elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a Smart campaign' is a tautology that merely restates the tool name. It provides no information about what a Smart campaign is or how it differs from sibling tools like create_performance_max_campaign or create_demand_gen_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use Smart campaigns versus other campaign creation tools, nor any prerequisites or context. This is a clear gap given the many sibling campaign creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool creates something, implying mutation, but does not describe any side effects, required permissions, response behavior, or constraints. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. It restates the tool name without earning its place, providing zero new information. This is similar to the 'Process' example where extreme brevity is a deficiency, not a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (nested snippets array, enums, two required parameters), the description is completely inadequate. It does not explain what structured snippets are, how to structure the input, or what the tool returns. With no annotations or output schema, the description leaves the agent with no way to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for only customerId (50% coverage), leaving the crucial 'snippets' array with its nested header enum and values array undocumented. The description adds no parameter information, failing to compensate for the schema's incomplete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create structured snippet extensions' is a near-verbatim restatement of the tool name 'create_structured_snippet_assets', merely substituting 'assets' with 'extensions'. It does not add specificity or differentiate from sibling tools like create_sitelink_extensions or create_callout_extensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description simply states the action without any context about appropriate use cases or strategic fit among the many extension-creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'manage'. It does not explain side effects (e.g., whether linking creates an invitation, requires approval, or is reversible), permissions needed, or what happens on success/failure. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it restates the tool name without adding informative content. Conciseness is not valuable when the sentence does not earn its place; it provides no insight beyond what the name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters, no annotations, and no output schema. The description fails to explain return values, side effects, or the expected workflow. This is completely inadequate for an agent to understand the tool's behavior and invocation correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters. The schema covers customerId and targetCustomerId with descriptions, but the action parameter lacks a description and the tool description does not clarify the relationship between the parameters or the meaning of LINK/UNLINK. With 67% schema coverage, the description should compensate for the missing 'action' semantics but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage account linking invitations' is essentially a restatement of the tool name 'manage_link_invitations'. The verb 'manage' is vague and does not specify the concrete actions (LINK/UNLINK) or the resource beyond what the name already implies. It lacks the specificity needed to clearly distinguish it from other management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or exclusions. Since there are many sibling tools, this absence of context leaves the agent without direction on whether this tool is appropriate for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention what data is returned, whether any filters or date ranges apply, access requirements, or any side effects. This leaves the tool's behavior completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified and does not earn its place as it adds almost no information beyond the tool name. For a tool of this complexity, a minimal one-liner is not satisfying.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should explain what the analysis provides and how to interpret results, but it does not. The parameters are documented in the schema, but the description fails to provide any context about the tool's output or usage, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (customerId and conversionId), so the schema already explains their meaning. The description adds no additional parameter semantics, which is acceptable given the high coverage baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get conversion attribution analysis' provides a clear verb ('Get') and a general resource ('conversion attribution analysis'), but the object is vague and does not distinguish it from sibling tools like get_conversion_path_data or get_conversions, which also deal with attribution metrics. The resource could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context is given about scenarios, prerequisites, or why a user would select this instead of related tools like get_conversion_path_data or get_conversions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing side effects, permissions, or mutation semantics. 'Manage' gives no indication of what happens to existing language targets, whether the operation is additive or destructive, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short fragment, but underspecification is not conciseness. It lacks a complete sentence and omits crucial details. While it is brief, it does not effectively use that brevity to convey meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely mutates campaign settings, the description is completely inadequate. There is no output schema, no annotations, and no mention of return values, side effects, or operational context. The description leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers two of three parameters with descriptions, leaving 'languageCodes' undocumented. The tool description adds nothing beyond the schema and fails to clarify how languageCodes are interpreted (e.g., replace vs. append). With moderate schema coverage and no compensatory explanation, the description provides minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a verb ('Manage') and a resource ('language targeting'), but 'manage' is vague and does not specify the specific operation (add, remove, replace, list). It distinguishes the general area from sibling tools but lacks the precision needed for an agent to know what action will be performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context about typical scenarios, prerequisites, or exclusions. The description only implies that it relates to language targeting, but does not state when an agent should invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It provides no behavioral details such as data scope, metrics included, whether it is read-only, pagination, or any side effects. The verb 'get' only repeats the tool name without adding context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specification rather than effective conciseness. It lacks essential details and does not earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description should explain return values and behavioral expectations. It provides none, making the tool ambiguous and hard to use correctly among many similar reporting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Schema coverage is only 50% (customerId described, dateRange not), and the description adds no meaning beyond the schema. It fails to explain what dateRange controls or how customerId is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets performance data broken down by location, using a specific verb and resource. It distinguishes from campaign-level performance tools but does not explicitly differentiate from similar geographic tools like get_geographic_report or get_location_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only repeats the tool's purpose and gives no information about whether the operation is read-only, what data is returned, or any side effects. This is insufficient for an agent to anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short phrase with no wasted words. However, it is under-specified: the structure is front-loaded but omits critical context. It is concise but not appropriately sized for the information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description must provide comprehensive context. It does not explain what 'insights' are returned, how locationIds are used, or what the output looks like. This is a simple tool with only 2 parameters, but the description still leaves the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: customerId has a description, but locationIds does not. The description adds minimal value by implying locationIds are the targeting locations, but it does not clarify their format, semantics, or how they affect the insights returned. The description does not compensate adequately for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('get') and resource ('location targeting insights'), but the phrase 'insights' is vague and does not specify what kind of insights are provided. It does not distinguish itself from sibling tools like get_geographic_performance or get_audience_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any use cases, prerequisites, or exclusions. With multiple sibling tools offering similar insight/reporting capabilities, this lack of differentiation is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any behavioral traits. It does not mention whether existing demographic targets are overwritten, permission requirements, or effects on bidding. The description carries the full burden for behavioral transparency and fails completely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified for a tool with three parameters and a nested object. It provides no structure or details, making it insufficient rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a nested demographics object, the description is grossly incomplete. It lacks usage context, behavioral details, and parameter semantics, leaving the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers two of three parameters with descriptions, and the description says 'age/gender targeting,' which loosely maps to the demographics array. However, it adds minimal meaning about gender/ageRange values or bidModifier, and does not compensate for the nested object's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Add' with the resource 'age/gender targeting', which clearly indicates the tool's function. It distinguishes from sibling tools like add_location_targets and manage_language_targets. However, it omits the ad group scope, which is present in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It only states the obvious action, offering no additional decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Create a Performance Max campaign' with no mention of required settings, side effects, or potential configuration steps. For a creation tool, this transparency is severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than concise—it repeats the tool name without adding value. A concise description would pack necessary context into few words, but this one omits essential information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter creation tool with no output schema and no annotations, a single sentence is grossly incomplete. The description does not explain what happens after creation, what the campaign requires (e.g., asset groups), or any return values, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for only 3 of 6 parameters (50% coverage), leaving targetRoas, targetCpaMicros, and biddingStrategyType undocumented. The description adds no parameter information and does not compensate for the gaps, so the agent must infer meaning from names and enums alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the specific resource ('Performance Max campaign'), which distinguishes it from other campaign creation tools by campaign type. However, it simply restates the tool name and does not elaborate on what a Performance Max campaign entails or how it differs from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_campaign, create_demand_gen_campaign, or create_app_campaign. The description does not mention prerequisites, exclusions, or typical use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get video campaign performance metrics,' which essentially restates the tool name and implies a read operation. It does not mention return format, data granularity, rate limits, or any side effects, adding no behavioral context beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, but this is underspecification rather than effective conciseness. It does not earn its place by adding useful information; it merely states the obvious. A truly concise description would pack more meaning into a few words while avoiding redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a report tool with no output schema and no annotations, the description needs to explain what metrics are returned and what the response looks like. It fails to do so, providing only a vague phrase. This is insufficient for a tool that likely returns complex performance data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents customerId but leaves dateRange without a description (50% coverage). The description itself mentions neither parameter, failing to compensate for the undocumented dateRange. It adds no meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('video campaign performance metrics'), which clearly identifies what the tool does and distinguishes it from sibling report tools like get_campaign_performance or get_search_term_report. However, it does not elaborate on what specific metrics are included, which leaves some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used for video campaigns specifically or that other tools are appropriate for non-video campaigns. There is no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely restates the operation and fails to mention return format, pagination, permissions, or how dateRange affects results, leaving critical behavioral traits unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), but this is under-specification rather than concise efficiency. It fails to provide necessary context, making the brevity a liability rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of two parameters (one undocumented), the description is far from complete. It omits information about return values, parameter behavior, and any filtering or output options, leaving the agent uncertain about the tool's full capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% parameter coverage: customerId is described but dateRange is not. The description does not compensate for the undocumented dateRange or add any usage context for either parameter, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get account change history log', which clearly indicates the action and resource. However, it is nearly a direct paraphrase of the tool name itself, adding little new information. It is distinct from siblings but lacks any scope or additional detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or any exclusions among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies a read operation ('Get') but does not disclose permissions, rate limits, return format, pagination, or what exactly constitutes 'click-level data'. This is a minimal disclosure with no useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—one clause—and avoids fluff. However, it is under-specified rather than concisely informative. It lacks enough detail to be a model of tightly-packed useful information, so it earns a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description is incomplete. It does not mention what the report contains, how results are returned, or any filtering capabilities. For a report-fetching tool among many similar siblings, this description is insufficient for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific meaning. The schema already documents customerId but not dateRange. The description does not explain valid dateRange values or how parameters interact, leaving a gap for the undocumented parameter. With 50% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a resource ('click-level data'), but the purpose is vague. It does not explicitly mention 'report' or 'Google Ads', and it could be confused with sibling tools like get_conversions or get_search_term_report. It provides only a generic sense of retrieving click-related data without distinguishing from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description lacks context about use cases, prerequisites, or exclusions. An agent would not know whether to choose this over other report tools based on the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation through the word 'Get' but does not explain what metrics are returned, how data is aggregated, or if special permissions are required. The description essentially restates the tool name without adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, being a single short phrase, but it is under-specified and merely rephrases the tool name. It does not earn its place because it adds no substantive information beyond what the name already conveys, making it more of a title than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with no output schema, no annotations, and a similarly named sibling (get_geographic_performance), this description is severely inadequate. It does not describe the report's contents, how parameters affect results, or how to distinguish it from other reporting tools. An agent would have no basis for selecting or invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only customerId explicitly described. The dateRange and campaignIds parameters lack descriptions, and the tool description does not clarify their syntax, allowed values, or purpose. The description adds no value beyond the sparsely annotated schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get location performance report' clearly identifies the action (Get) and the resource (location performance report), making the tool's basic purpose understandable. However, it fails to differentiate this tool from the sibling 'get_geographic_performance', which appears nearly identical in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_geographic_performance or get_location_insights. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to guess which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates that bids are adjusted, but does not explain whether adjustments replace existing ones, whether it is a write operation requiring special permissions, or what happens to omitted locations. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified. It is not merely concise; it lacks necessary detail that would make it an adequate description. The structure is front-loaded but the content is too vague to be considered well-crafted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a partially documented nested array parameter, the description is incomplete. It does not explain return values, error conditions, idempotency, or the effect on existing bid adjustments, leaving the agent without enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds minimal meaning beyond the schema. It implies that 'adjustments' contain location-specific bid changes but does not explain the role of 'campaignId', 'locationId', or 'bidModifier', nor the expected format of the array. The description does little to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adjust bids by location' states the core action of the tool (adjust bids) and the resource (by location), but it is vague and does not specify the exact scope (e.g., campaign-level bid modifiers). It also fails to distinguish itself from the sibling tool 'update_bid_adjustments', making its purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or exclusions, and does not indicate whether this tool is preferred over 'update_bid_adjustments' or 'add_location_targets'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create', implying mutation, but does not state whether it requires specific permissions, whether it is idempotent, or what happens on duplicate sitelinks. No return type or error behavior is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient in length. However, it is under-specified and lacks the structural elements that would make it genuinely helpful, such as listing key parameters or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete for a tool with no annotations, no output schema, and nested object parameters. It doesn't explain the meaning of 'sitelinks', the required structure, or what the function returns. This would leave an agent uncertain about how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes customerId with a short description, but the sitelinks parameter and its nested fields (linkText, finalUrls, description1, description2) lack descriptions. The tool description adds no additional meaning to these parameters, just saying 'sitelink ad extensions'. With only 50% schema coverage, the description doesn't compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('sitelink ad extensions'), clearly stating the tool's function. However, it does not distinguish between this and the sibling tool 'create_sitelink_assets', which may be similar; the term 'extension' vs 'asset' could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives like 'create_sitelink_assets' or 'create_callout_extensions'. It does not specify any prerequisites, such as needing a campaign or customer ID, or whether this is for legacy extensions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates that the tool creates extensions, implying mutation, but provides no additional transparency about side effects, permission requirements, idempotency, or impact on existing resources. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, making it concise. However, it is under-specified rather than appropriately detailed, omitting essential context. It is front-loaded but not sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the minimal description, the tool is incomplete. An agent cannot determine what callout extensions are, how to structure the callouts parameter, or how this tool relates to similar extension-creation tools. The description leaves critical gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes customerId but leaves callouts undefined. The description adds no meaning to the parameters, failing to explain what calloutText represents or what structure the callouts array should follow. With only 50% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (callout extensions), which distinguishes it from unrelated tools. However, it does not differentiate from similar sibling tools like create_callout_assets or create_call_extensions, making the purpose clear but not uniquely distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_callout_assets or create_sitelink_extensions. It lacks any context about prerequisites, use cases, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose write characteristics, required permissions, idempotency, response format, or side effects, providing only a bare verb phrase.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, it is succinct but under-specified. It merely restates the tool name with slightly more wording, offering no additional value; it is not a concise form of richer information but rather a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a minimal description, the tool is under-described. It doesn't explain the relationship to labels (e.g., labels must be created before applying them) or any return behavior. Sibling tools suggest a broader workflow, but the description doesn't connect to it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes customerId but not the labels array or its fields (name, description, backgroundColor). The description adds no parameter information, failing to compensate for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create organizational labels' uses a specific verb (create) and resource (organizational labels), clearly indicating the tool's function. It distinguishes from sibling 'apply_labels' which applies labels to resources, though it doesn't explicitly mention that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'apply_labels' or 'get_labeled_resources'. There are no prerequisites, exclusions, or context signals, leaving the agent to infer the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral context, but it only states the action. It does not indicate whether the operation is read-only, whether it requires specific date ranges, or what the output format is, nor any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler words, front-loading the core action. It is concise and structurally clear, but lacks substance; however, this dimension measures economy, not depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description only states the purpose, leaving out operational details like required inputs, optional parameters, and expected results, making it insufficient for correct invocation in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only customerId is described) and the description does not elaborate on any parameter. It fails to explain the role of keywordTexts, dates, or bid amounts, leaving the agent to guess how to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'generate' with resource 'traffic and conversion forecasts', clearly stating what the tool does. It does not explicitly distinguish from sibling tools, but the function is unique enough among the listed siblings to earn a high score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_bid_simulations or get_keyword_ideas. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only restates the tool's purpose without disclosing any behavioral details such as whether it is read-only, what data it includes, or how it aggregates insights. The verb 'Get' implies a read operation, but no safety or side-effect context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is easy to parse. It is appropriately concise for a simple get operation, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too minimal. It does not clarify what 'performance insights' actually contain, how the parameters interact, or what kind of response to expect. This leaves the agent under-informed for a tool that should surface metric data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both customerId and audienceId have descriptions. The tool description adds no additional parameter semantics, but the schema already documents the parameters clearly, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get audience performance insights' names a clear verb and resource, but 'insights' is vague and does not specify what kind of performance data is returned. It does not distinguish this tool from siblings like get_audiences or get_auction_insights, which could also be seen as related reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or situations where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Apply audience targeting to a campaign' reveals nothing about side effects, prerequisites, whether it appends or replaces existing audiences, or the result of the operation. The description is entirely silent on behavior beyond the bare action, making it nearly useless for anticipating the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core action. However, it may be too terse, missing opportunities to add useful context without being verbose, so it does not achieve a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. The description fails to explain whether the operation is additive, whether it requires any prerequisites (e.g., audience already exists, campaign is active), or what the outcome is. Even though the parameter schema is complete, the behavioral context is severely lacking, making the description incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all three parameters (audienceId, campaignId, customerId), meeting the schema_description_coverage high threshold. The description adds no parameter-specific meaning beyond what the schema already states, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Apply audience targeting to a campaign' clearly identifies the action (apply) and the resource (audience targeting to a campaign), distinguishing it from sibling tools like remove_audience_from_campaign. However, it is essentially a paraphrase of the tool name without adding broader scope or explicit differentiation, so it does not fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives. There is no mention of scenarios where adding an audience is appropriate, nor any exclusions or references to sibling tools such as remove_audience_from_campaign or get_audiences. This is a clear lack of usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It only says 'apply labels' without disclosing whether labels are added, replaced, or removed, whether the operation is idempotent, or any side effects. As a mutation tool, this lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it concise and front-loaded. However, it is arguably too terse, bordering on under-specification, though that is more a completeness issue than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 4 required parameters, no annotations, and no output schema. The description provides only the basic action and resource, without addressing the ad_group option, prerequisites, or operational behavior. It is insufficient for an agent to correctly invoke the tool in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only customerId has a description). The description does not clarify that resourceType must be one of campaign, ad_group, or ad, nor that resourceIds must match that type. It doesn't explain the relationship between labelIds, resourceIds, and resourceType beyond the tool name, providing minimal compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Apply labels') and the target resource ('campaigns/ads'), which clearly differentiates it from sibling tools like create_labels (creating labels) and get_labeled_resources (retrieving labels). However, it omits 'ad_group' even though resourceType enum includes it, making the stated scope slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., labels must already exist via create_labels), exclusions, or typical use cases. The minimal description leaves usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It merely restates the tool name and provides no information about side effects, permissions, response behavior, or reversibility. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundant words. It is concise and front-loaded, earning its place as a minimal definition, though at the cost of depth in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and five required parameters, the description is drastically incomplete. It fails to explain how the campaign is created, what happens on success or failure, or any operational context. The tool supports app promotion, but the description offers no useful context beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so most parameters already have meaningful descriptions. The tool description adds no parameter-specific information beyond the schema, which aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (Create) and resource (App promotion campaign) clearly, and the campaign subtype distinguishes it from generic create_campaign. However, it does not elaborate on what an App promotion campaign involves, so differentiation from other campaign types is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like create_campaign, create_smart_campaign, or create_performance_max_campaign. There is no mention of prerequisites, selection criteria, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the core action ('Create') but does not disclose expected effects, permission requirements, whether assets are added or replaced, or any response behavior. For a mutation tool, this is a minimal disclosure that leaves significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no filler or repetition. It is efficient and structurally sound, but so terse that it sacrifices valuable context. Still, conciseness is about waste, and this has none, so it earns a strong score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is far from complete. It omits any information about return values, side effects, required permissions, or relationship to other entities (only the schema implies customerId). The description offers only the most basic action, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only customerId is described). The description adds no additional parameter semantics. It mentions 'callout' which loosely maps to the 'callouts' parameter, but does not explain what calloutText should contain or how the callouts array is structured. The description fails to compensate for the documentation gap in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-action ('Create') and resource ('callout extensions'), making the tool's purpose unambiguous. However, it does not distinguish this tool from the sibling tool 'create_callout_extensions', which appears to have the exact same purpose. This lack of differentiation prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement of action without any contextual direction. This leaves the agent to infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Create a custom audience list' which is essentially the tool name restated. It does not mention potential side effects, required permissions, return values, or whether the operation is idempotent. This is effectively no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is concise and front-loaded. However, it is so minimal that it lacks structured detail, though it does not waste words. It earns its place by stating the purpose but could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description should explain what happens after creation, any prerequisites, or how it relates to other audience tools. It provides none of these. The complete schema mitigates some issues, but the description is inadequate for an agent to fully understand the tool's context and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters have descriptions in the schema. The tool description itself adds no parameter meaning, but the baseline for high schema coverage is 3. The schema clearly explains name, customerId, description, and membershipDurationDays.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (custom audience list). It is specific enough to indicate a creation operation, but it does not distinguish this tool from sibling tools that also create audience types like create_customer_match_list or create_lookalike_audience. Thus it meets the 'clear but no sibling differentiation' level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_customer_match_list or create_lookalike_audience. There are no prerequisites, context, or exclusions mentioned, leaving the agent without direction on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the creation action and does not mention required nested fields, permissions, response behavior, idempotency, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It is appropriately short for a simple tool, though it could benefit from a bit more structural guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a nearly identical sibling tool, the lack of usage guidance, and no output schema or annotations, the description is not complete enough for reliable tool selection. It leaves important gaps around input requirements and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage; only 'customerId' is described. The description adds no meaning to the 'sitelinks' parameter or its nested fields like 'linkText' and 'finalUrls', so the agent must infer semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Create sitelink extensions'. However, it does not distinguish this tool from the sibling tool 'create_sitelink_extensions', which appears to be nearly identical in name and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'create_sitelink_extensions' or other asset creation tools. The description gives no context or exclusions, leaving the agent unsure which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that performance metrics are retrieved, but does not explain what metrics are included, whether data is aggregated, pagination behavior, or any limitations. This is a significant gap for a reporting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that essentially restates the tool name, providing minimal informative value. It is not effectively concise; it is under-specified and does not earn its place by adding new information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a brief description. It fails to explain what 'performance metrics' means (e.g., impressions, clicks, conversions), what date ranges are supported, or how to interpret results. This is incomplete for a tool that returns sophisticated data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (100% coverage), so the schema supplies the necessary meaning. The description adds no parameter detail itself, but the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves campaign performance metrics, using a specific verb ('get') and resource ('campaign performance metrics'). It is distinguishable from sibling tools like get_campaigns (which lists campaigns) and get_asset_performance (which focuses on assets), though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, filters, or scenarios where other tools might be more appropriate. Users are left to infer usage solely from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states the basic action and does not mention return format, pagination, whether multiple resource types are included, or how empty results are handled. This leaves significant behavioral uncertainty for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no filler or repetition. It efficiently conveys the core purpose, though it may be too terse to capture necessary nuances, which is penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 well-documented parameters, but the lack of an output schema and annotations creates ambiguity about the response structure. The ambiguous 'resources' term also prevents the agent from knowing the tool's full scope. This is a minimally viable description but not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (labelId and customerId) with 100% coverage. The description 'by label' adds minimal context by indicating that labelId is the filter key, but it does not explain the role of customerId beyond what the schema implies (account scope). The description adds little value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find resources by label' uses a clear verb and identifies the core functionality (label filtering). However, the term 'resources' is vague and does not clarify which Google Ads entity types (campaigns, ad groups, ads, etc.) are returned, making it ambiguous relative to sibling tools like get_campaigns or get_ad_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, without mentioning scenarios, limitations, or suggesting other tools for different use cases, such as querying specific resource types directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It says 'get' implying a read-only operation, which is a typical safe operation, but it doesn't disclose whether the report is aggregated, what data is included, any limits or side effects. Reads are generally safe, but the description adds no context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It's front-loaded with the main verb and resource. However, it's so terse that it might be under-specification, so a 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a reporting tool with 5 parameters, no output schema, and no annotations. The description is one sentence, providing no information about response format, required permissions, or how the report is structured. Given the complexity, the description is inadequate for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 60% of parameters with descriptions, but the description itself mentions no parameters. It doesn't clarify the dateRange defaults, how campaignIds filtering works, or how minImpressions affects the report. The description adds no value beyond what the schema already provides, and the undocumented parameters remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and resource 'search query performance report', clearly indicating a reporting tool for search query data. It distinguishes from sibling tools like get_campaign_performance or get_keywords, as 'search query' is a distinct concept. However, it doesn't elaborate on the report's contents, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. It doesn't mention alternatives, exclusions, or appropriate contexts. This leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a write operation but does not mention required permissions, potential side effects, idempotency, or response format. Minimal detail is given beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified. While brevity is positive, the lack of meaningful content makes it less useful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 3 enums) and absence of annotations or output schema, the description is insufficiently complete. It does not explain what a conversion action is, when to create one, or what happens after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all six parameters. The description adds no additional parameter semantics, which is acceptable per the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new conversion action'), with a purpose ('for tracking'). This distinguishes it from sibling tools like update_conversion_action, though it could be more specific about what a conversion action entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_conversion_action or import_offline_conversions. The description simply states what it does without contextualizing its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a lookalike/similar audience' without mentioning required permissions, whether the seed audience must exist, what happens on invalid input, reversibility, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of one short sentence. However, it largely restates the tool name and adds little value ('lookalike/similar' is a synonym), so it does not fully earn its place as a meaningful addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema. The description lacks any contextual detail about prerequisites, return values, or behavior. Given the presence of many sibling audience tools, the description is not complete enough to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter ('New audience name', 'Google Ads customer ID', 'Seed audience ID'). The description adds no extra parameter meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('lookalike/similar audience'). It is specific enough to understand the tool's purpose, but it does not explicitly differentiate from sibling tools like create_custom_audience or create_customer_match_list, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where a different audience creation method would be more appropriate. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states a basic action. It does not disclose whether the operation is read-only, requires specific permissions, returns paginated results, or has rate limits, so the agent has little insight into behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary wording. It is immediately front-loaded and easy to parse, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and ambiguous parameter semantics, yet the description provides no context about expected results, use cases, or the purpose of the keywordSeed parameter. It is incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema partially covers parameters (customerId is described, keywordSeed is not), but the description adds no parameter meaning. Since schema_description_coverage is only 50%, the description should compensate for the missing keywordSeed semantics but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('keyword suggestions and ideas'), which conveys the tool's basic purpose. It distinguishes from sibling 'get_keywords' via the term 'ideas', but does not explicitly differentiate from other suggestion-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as 'get_keywords' or 'generate_forecast_metrics'. There are no examples, prerequisites, or exclusions, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits itself. It simply states 'Get' without disclosing whether this is a read-only operation, how recommendations are filtered, or what the response contains. This is insufficient for the agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'Get Google optimization recommendations', with no unnecessary words. It is front-loaded and efficient, though minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain what the tool returns and any relevant context. It does not mention response format, filtering behavior, or how recommendations connect to sibling tools like 'apply_recommendation'. For a two-parameter tool with no output schema, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'customerId' but leaves 'types' unexplained. The description adds no parameter information, failing to clarify what values 'types' accepts or what 'types' filters. With only 50% schema coverage, the description does not compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'Google optimization recommendations', clearly indicating this tool retrieves optimization recommendations. However, it does not distinguish itself from sibling tool 'get_budget_recommendations', which is a narrower variant, so the purpose is clear but not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_budget_recommendations' or how it relates to 'apply_recommendation'/'dismiss_recommendation'. There is no context about recommended use cases or exclusions, so the agent is left without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a write operation ('upload') but fails to disclose any behavioral traits such as idempotency, validation requirements, error conditions, or whether it appends or replaces data. Minimal info beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but may border on under-specification. It is a single clause that efficiently states the high-level purpose, but lacks any structured details like prerequisites or usage notes. It earns its place but does not go beyond a minimal phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested conversions array and sits among many conversion-related tools, the description is too sparse. It does not mention expected data format, relationship to conversion actions, or return behavior. No output schema or annotations exist to compensate, leaving significant gaps for an agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for customerId and conversions, including nested fields. The description adds no additional parameter semantics, so the schema already does the heavy lifting. Baseline of 3 is appropriate because it neither adds nor detracts from schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Upload') and target ('offline conversion data'), which is a specific resource. It distinguishes from read-only or definitional siblings like get_conversions and create_conversion_action, though it does not explicitly name them. Lacks explicit scope beyond 'offline', but enough to infer the primary use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or typical scenarios. The description is just a single phrase with no context for decision-making. Does not mislead, but offers no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only source of behavioral disclosure. It states that the tool 'applies' a recommendation, implying a mutating action, but it does not disclose potential irreversibility, permission requirements, or the impact on the account. This is a significant gap for a modification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. There is no redundant information or unnecessary detail, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations and no output schema, yet the description only states the basic action. It does not explain what happens after applying, whether it is reversible, or any prerequisites. The simple schema does not compensate for this lack of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (customerId and recommendationId) with 100% coverage. The description adds no additional parameter-specific context, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Apply a Google recommendation' clearly identifies the action (apply) and resource (recommendation), and it is distinct from sibling tools like get_recommendations and dismiss_recommendation. However, it lacks detail on what 'applying' entails or the specific scope of the recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_recommendations or dismiss_recommendation. There is no mention of prerequisites, typical workflow, or situations where applying is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Create' implies a write operation, but there is no disclosure about permissions, idempotency, side effects, or the returned resource. It also omits how the type enum maps to targetCpa/targetRoas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter creation tool with no output schema and no annotations, this description is too sparse. It lacks information about type-specific parameters, response format, and operational constraints, leaving the agent to rely on the incomplete schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents most parameters. The description adds no extra semantics, such as conditional requirements between 'type' and target metrics, keeping it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'automated bidding strategy', clearly indicating the action. It differentiates from read-only sibling tools like get_bidding_strategies, though it does not explicitly mention strategy types or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as update_bid_adjustments or create_campaign. It does not state prerequisites, such as an existing customer account, or the relationship between this strategy and campaign creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states a read operation via 'Get' but does not describe return format, whether customerId must be an MCC account, rate limits, or any side effects. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. There is zero wasted words, making it appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about what the hierarchy includes, how the customerId is used, and what the caller should expect. The current text explains the basic purpose but lacks sufficient detail to fully set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (customerId) already described as 'Google Ads customer ID'. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get account structure and hierarchy' clearly identifies the verb (Get) and the resource (account structure/hierarchy). It distinguishes from sibling 'list_accounts' by implying a hierarchical view rather than a flat list, though it could be more explicit about the nature of the hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_accounts or get_campaigns. There is no mention of prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'Get ads', which implies a read operation, but does not clarify pagination, return structure, or the relationship between required customerId and optional adGroupId. The phrase 'customer or ad group' is also ambiguous about parameter requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no wasted words. It is front-loaded with the verb and resource, immediately conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema, but with no annotations and no output schema, the description should provide more behavioral context (e.g., return format, filtering behavior). It fails to do so, leaving significant gaps in expectations for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (100% coverage). The description's 'customer or ad group' aligns with the schema but adds no new format or semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('ads') with clear scoping ('customer or ad group'), making the purpose clear. It implicitly distinguishes from siblings like get_ad_groups or get_campaigns by focusing on ads, though it does not name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives such as get_ad_groups or get_keywords. The description does not state prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether assetId is optional, what happens when it is omitted, how metrics are aggregated, or whether results are time-bound. This is a significant transparency gap for a performance metrics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is front-loaded and easy to parse, but it is terse to the point of under-specification. For conciseness alone, it earns a 4, though it sacrifices substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description fails to explain what metrics are included, how assetId affects the result, or any usage context. It is minimally adequate but leaves many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics; it relies entirely on the schema to explain assetId and customerId, which is acceptable but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get asset performance metrics' clearly identifies the action (get) and the resource (asset performance metrics), but it does not explicitly distinguish it from sibling performance tools like get_campaign_performance or get_extension_performance. A more precise statement about asset-level metrics would differentiate it further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context about scope, date ranges, or required fields. The description simply states a function without any usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool 'gets' forecasts without explaining what a bid simulation is, what data is returned, how far into the future forecasts extend, or any limitations. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. However, it is almost too terse, omitting useful context, but conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters, no output schema, and no annotations. The description is too minimal to convey the purpose, behavior, or expected results of a bid simulation forecast. Sibling tools like generate_forecast_metrics suggest overlap, so more context is needed to avoid misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents customerId and resourceId with helpful descriptions, and resourceType has an enum. The description adds no parameter-level detail, so it does not exceed the schema baseline. Since schema coverage is 67%, the description could have clarified the resourceType values but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('bid simulation forecasts'), indicating the tool retrieves bid simulation forecast data. It is distinct enough from generic 'get' tools, though it does not explicitly differentiate from the sibling 'generate_forecast_metrics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like generate_forecast_metrics or get_budget_recommendations. There is no mention of preferred use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full responsibility for disclosing behavioral traits. It only restates the function without mentioning read-only nature, expected output format, dependencies, or side effects, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that is front-loaded and free of unnecessary words. It is efficient, though it lacks additional sections or guidance, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only two parameters, the description should offer more context. It does not explain what the returned recommendations contain, how they are scoped, or any limitations, making the tool feel incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema with clear names and descriptions, so the baseline is 3. The description adds no additional insight into parameter usage or formatting, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Google budget optimization recommendations. It is specific about the resource but does not explicitly differentiate from the sibling tool get_recommendations, which likely covers broader recommendation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool versus alternatives such as get_recommendations, apply_recommendation, or get_shared_budgets, leaving the agent without decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but does not disclose what data is returned, any limitations, permissions, or whether the operation is safe. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It avoids unnecessary words, but is so minimal that it misses opportunities to add valuable context. It is efficient, though not as exemplary as descriptions that combine purpose with usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimal description, the tool is under-specified. The description does not explain what 'conversion path data' consists of, any filters beyond the two parameters, or what the response will look like. Given the breadth of sibling tools, more context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both customerId and dateRange described adequately. The description adds no additional parameter semantics, which is acceptable since the schema already provides full coverage. Baseline of 3 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and a specific resource ('customer journey conversion path data'). It clearly states the tool retrieves conversion path data, but does not differentiate it from similar reporting tools like get_conversions or get_conversion_attribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling conversion/reporting tools. There is no mention of use cases, exclusions, or alternatives. The description does not help the agent decide between this and near-neighbor tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to provide safety or side-effect context, and the description only says 'Get conversion actions and their performance metrics.' It does not disclose behavior such as pagination, default date-range behavior, required permissions, or the shape of returned data. The description carries the full burden but offers very little.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is efficient, though it could benefit from a brief clarifying clause about how it differs from similar conversion tools without much cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks critical context for a conversion-related tool: it does not state what metrics are included, how the dateRange is defaulted, or what the response contains. With no output schema and no annotations, this leaves the agent uncertain about the tool's exact use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full documentation for both parameters (customerId and dateRange), including the enum values for dateRange. With 100% schema coverage, the description need not add param details, and it does not, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('conversion actions') along with the additional scope of 'performance metrics.' It is understandable and distinct from related conversion tools, though it does not explicitly contrast with siblings like get_conversion_attribution or get_conversion_path_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like get_conversion_attribution, get_conversion_path_data, and create_conversion_action handle different aspects of conversions, but the description gives no exclusions or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that this is a 'get' report, which implies a read operation, but does not describe data aggregation, filtering behavior, time range handling, or response format. This is a significant gap for a report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically clear sentence with no filler. It front-loads the action and resource, making it easy to parse. It earns its place by stating the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and no output schema, the one-sentence description is far from complete. It does not explain what the report contains beyond age/gender, how date range or campaign filtering works, or what the return structure looks like. An agent would need to guess or inspect the schema, which itself is partially undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics. The input schema has only 33% coverage (customerId has a description, but dateRange and campaignIds do not). With such low schema coverage, the description was expected to compensate, but it does nothing to explain what these parameters control or how they relate to the report.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('age and gender performance report'). It distinguishes itself from sibling report tools like get_geographic_report and get_search_term_report by naming the exact dimensions (age and gender).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of suitable use cases, exclusions, or references to sibling tools like get_audience_insights or get_geographic_report. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get', implying a read operation, but doesn't disclose what data is returned, whether extensions are required to be filtered, any rate limits, or other behavioral traits. This is a significant gap for a tool that could be expected to provide detailed metrics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and readable, though it borders on under-specification. However, as a structural and sizing evaluation, it earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters, no output schema, and no annotations. Given this context, the description is not complete. It fails to explain return format, time ranges, filtering behavior, or how it relates to similar performance tools. A more complete description is needed to support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions), but those descriptions are terse: 'Google Ads customer ID' and 'Type of extension'. The tool description does not add any meaning beyond the schema. The baseline for high coverage is 3, and the ambiguity of 'Type of extension' (no enum or examples) is not compensated, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Get extension performance metrics'. It distinguishes the resource (extension performance) from more generic performance tools, but doesn't explicitly differentiate from sibling tools like get_asset_performance or get_campaign_performance, so a small deduction is applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, common use cases, or exclusions. The only implicit signal is the name itself, which is insufficient for an agent deciding between multiple performance-reporting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it does not. It fails to mention that this is a read-only operation, any pagination behavior, or the structure of returned data. The verb 'get' implies read-only, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and easy to parse, though it is minimal and misses opportunities to add useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what image assets are returned, their format, or any limitations. It does none of this, leaving the tool under-specified for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for customerId, which is described as 'Google Ads customer ID'. The description's phrase 'for a customer' aligns with this parameter but adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get image assets for a customer' clearly identifies the action (get) and resource (image assets) with a customer scope. It is specific enough to understand the basic purpose, but lacks explicit differentiation from sibling tools like get_video_assets or upload_image_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone should convey behavioral traits. It only states the action and target, but does not disclose what is returned, whether negative keywords are included, or any read-only safety context. The verb 'get' implies a read operation, but additional detail would be needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is front-loaded with the verb and resource, and all content is relevant. It could be slightly more informative, but it avoids bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and complete schema, the description provides adequate context to understand the basic purpose. However, with no output schema or annotations, it leaves gaps about the return format and the exact nature of 'keywords' (e.g., includes negative keywords?). It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's 'customer or ad group' mirrors the schema parameters but adds no new meaning beyond what the schema already documents. It does not explain how adGroupId filters results or any format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves keywords, with the scope being a customer or ad group. This distinguishes it from write operations like add_keywords and from keyword idea generation (get_keyword_ideas), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus related tools such as get_keyword_ideas or add_keywords. It implies use when needing existing keywords, but there is no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'update', implying mutation, but does not explain whether adjustments are merge/replace, any permission requirements, or constraints on bid modifier values. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb. It wastes no words, though it is too sparse to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, plus a nested 'adjustments' parameter, the description is far too minimal for safe invocation. It does not cover return behavior, side effects, or edge cases, making the tool risky to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (customerId described, adjustments not). The description adds the phrase 'device/location' which hints at the adjustments structure, but it does not explain the array semantics, the meaning of bidModifier, or how resourceId is used. It provides marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('device/location bid adjustments'), making the basic purpose evident. However, it does not distinguish this tool from the sibling 'set_location_bid_adjustments', which overlaps with the location aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'set_location_bid_adjustments' or 'manage_language_targets'. There is no mention of prerequisites, exclusions, or decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reiterates the action of uploading, implying mutation, but fails to mention side effects like whether an existing asset is overwritten, required authentication, file format restrictions, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, entirely free of fluff. It is appropriately concise, though it adds little beyond the function name. The structure is acceptable for such a simple statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema, this description is too thin. It does not explain return values, upload constraints (e.g., image type/size), or whether this is a create operation, leaving significant gaps for an AI agent to reason about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with brief descriptions, so the parameter semantics are already documented. The tool description adds no extra meaning beyond the schema, which lands at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Upload image asset for ads' clearly states the verb and resource, and it is distinct from sibling tools like get_image_assets and get_video_assets. It could be more explicit about whether it creates a new asset or replaces an existing one, but the core 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.
Usage Guidelines2/5
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 when to upload an image asset versus creating an asset group or using get_image_assets. The usage context is only implied by the phrase 'for ads', with no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It does not mention whether keywords are appended or replaced, whether existing keywords are checked for duplicates, default matchType behavior, or any permission requirements. The description adds no behavioral information beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is appropriately concise for a simple operation and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It omits what happens on success/failure, whether the operation is atomic across multiple keywords, and any preconditions (e.g., ad group must exist). The schema covers parameter names but not behavioral context. This is insufficient for an agent to fully anticipate tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented. However, the parameter descriptions ('Keywords to add', 'Ad group ID', 'Google Ads customer ID') are minimal labels that restate the schema names. The description adds no extra semantics like default values, relationship between cpcBidMicros and matchType, or array limits. Baseline 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add keywords to an ad group' clearly states the action (add), the resource (keywords), and the target (ad group). It effectively distinguishes from sibling add_negative_keywords by implying positive keywords, and from get_keywords which is a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like add_negative_keywords or when to avoid it. The description only states what it does, leaving the agent to infer usage context from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. Saying 'List video assets' only implies a read operation, but does not explicitly state read-only nature, pagination, return format, or any side effects. It lacks details that would help an agent understand what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no fluff, but it is under-specified as a sentence fragment. While brevity is a strength, the three-word phrase lacks the structure of a complete description and conveys minimal helpful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple one-parameter schema and no output schema, the description is incomplete. It does not mention what the returned list contains, whether it includes metadata, supports pagination, or requires specific permissions, leaving the agent with incomplete expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter, customerId, as 'Google Ads customer ID.' The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List video assets' uses a specific verb and resource, clearly indicating the tool retrieves video assets. This distinguishes it from sibling tools like get_image_assets and get_video_report, despite not elaborating on the asset details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_image_assets or get_video_report. There are no contextual cues, exclusions, or explicit use cases given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether adding targets appends or replaces existing targeting, or any side effects, permissions, or limitations. The verb 'add' is the only behavioral hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of filler. Every word is relevant to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations or output schema, the description is too sparse. It fails to explain expected behavior (append vs replace), required campaign existence, or any operational context, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% but the critical 'locations' parameter lacks description. The tool description adds no parameter-level meaning, leaving the structure and semantics of location objects (e.g., bidModifier) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add), resource (geographic targeting), and target (campaigns). It differentiates from sibling tools like add_demographic_targets and set_location_bid_adjustments by the specific object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, prerequisites, or exclusions. The description simply states what it does without contextualizing the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the creation action and does not explain that creating an experiment will affect traffic allocation, require specific permissions, or produce a new experiment entity. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant content. However, it is so brief that it borders on under-specification, but it is not a tautology like 'Process' and earns a slightly above-average score for clarity and economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotation support, no output schema, and four required parameters. The description gives no context about the operation's side effects, return values, or the relationship between baseCampaignId and trafficSplitPercent, making it incomplete for an agent to invoke correctly and anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all four parameters, providing clear meanings like 'Experiment name' and 'Traffic split percentage'. The description adds no additional detail beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the specific resource ('a campaign A/B test experiment'). It distinguishes from sibling tools like create_campaign, which creates a regular campaign, and get_campaign_experiments, which reads experiments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the need for an existing base campaign, nor does it contrast with related tools like create_campaign or get_campaign_experiments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only restates the action ('create') and introduces 'shared budget' but doesn't explain implications like shared budget semantics, defaults for deliveryMethod, whether it replaces existing budgets, or permission requirements. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, immediately stating the purpose. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The one-sentence description omits context about required permissions, return values, or how to associate the budget with campaigns. Given the tool's complexity, this is inadequate for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 75% of parameters with descriptions. The description adds no information about any parameter, including the undocumented deliveryMethod enum or how amountMicros should be formatted. It doesn't compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies a distinct resource ('shared budget') with its scope ('for multiple campaigns'), clearly differentiating it from sibling tools like create_campaign or get_shared_budgets. It's a clear, non-tautological statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites (e.g., customerId must exist), relationship to campaigns, or when one might create individual budgets instead. It merely states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses nothing about behavior such as error handling, rate limits, query limitations, or output behavior. The one-line description is entirely insufficient for a generic query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded and to the point, though it sacrifices significant behavioral detail. It earns its place as a minimal statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that accepts arbitrary GAQL queries, the description is notably incomplete. It does not explain what GAQL is, what query types are supported, any constraints, or what the response looks like. Given no output schema and no annotations, more context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (query, customerId, outputFormat) have descriptions in the schema, reaching 100% coverage. The description itself adds no additional semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Execute' with a precise resource 'custom GAQL query'. It clearly distinguishes itself from sibling tools that have predefined purposes (e.g., get_campaigns, get_keywords) by emphasizing custom queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ad-hoc queries not covered by specialized endpoints, but it does not explicitly state when to use it versus alternatives. There is no mention of exclusions or when not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description carries the full burden of behavioral disclosure. It only states the action without mentioning data scope, required permissions, or limitations (e.g., auction insights may not be available for all campaigns), so the agent receives no safety or behavior hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, meaningful sentence with no redundant words. It is front-loaded and efficient, earning its place without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 2-parameter read tool, the description is minimally viable but somewhat vague. It does not specify what data will be returned or how to use the parameters effectively, and with no output schema or annotations, a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for its 2 parameters, so the baseline is 3. The description adds no extra meaning about how campaignId filters insights or why customerId is required, but the schema already covers these basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets competitive analysis and auction insights, using a specific verb and resource. However, it does not differentiate from sibling insight tools like get_audience_insights or get_location_insights, missing the chance to clarify its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, exclusions, or recommended scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'List' which implies a read operation, but does not explicitly state non-mutating behavior, return format, pagination, or any side effects. Minimal extra insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant wording. It is appropriately sized for a simple list operation and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description conveys the core function but omits details like return fields, pagination, or filtering behavior. It is adequate for basic understanding but not fully complete for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with customerId described as 'Google Ads customer ID'. The description adds no additional parameter detail, but the schema is already self-explanatory, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List all available audiences and user lists', using a specific verb and resource. It distinguishes from most siblings by being a read-only listing operation, though it does not explicitly differentiate from get_audience_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives like get_audience_insights or create_custom_audience. The description implies a simple listing use case but does not offer exclusion criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It only says 'Get campaigns for a customer,' which implies a read operation but does not disclose any behavioral details such as return format, pagination, filtering, or permissions. The description essentially restates the tool name without adding meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence ('Get campaigns for a customer') that is front-loaded and contains no redundant words. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is minimally adequate. However, it could be more complete by explicitly stating that it returns a list of campaign objects, and by noting any differences from performance reporting tools. The lack of return value documentation and usage context makes it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents customerId with a description ('Google Ads customer ID (10 digits)'), resulting in 100% schema coverage. The description's 'for a customer' aligns with this parameter but adds no additional semantic detail beyond what the schema already provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get campaigns for a customer' clearly states the action (get), resource (campaigns), and scope (customer). It is specific enough to distinguish from sibling tools like get_campaign_performance, which focuses on performance metrics rather than campaign objects. However, it could be slightly more explicit about returning a list of campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention if it should be used instead of get_campaign_performance, get_ad_groups, or others, nor does it state any prerequisites or exclusions. The only implied context is that a customerId is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the listing action without mentioning pagination, required permissions, response format, or any read-only caveats. While 'List' implies a safe read, critical behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately concise for a simple list operation, following the pattern of the highest-scoring example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one param, no output schema), the description lacks context about what data is returned or how the list is scoped. It is adequate for a basic list but leaves gaps such as whether budgets include amounts, statuses, or other fields. No output schema means the description should have provided more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the customerId parameter already described as 'Google Ads customer ID'. The tool description adds no additional meaning beyond the schema, aligning with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'shared campaign budgets', making the tool's purpose obvious. It distinguishes from siblings like create_shared_budget and get_budget_recommendations, though it doesn't explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_budget_recommendations or create_shared_budget. It does not mention exclusions or prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits fully. It only states 'update' without addressing potential side effects, required permissions, reversibility, or how partial updates are handled. There is no contradiction, but the description adds minimal behavioral context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise and front-loaded. It avoids redundancy, though it may be too terse to be fully useful. Still, it is properly sized for a simple update operation and earns its place without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a mutation tool, the description should provide more context such as how to identify the conversion action, behavior of the updates object, or any limitations. It only states the basic action, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since all three parameters (customerId, conversionId, updates) have descriptions. The tool description does not add any parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing conversion action' uses a specific verb ('update') and resource ('conversion action'), and the word 'existing' clearly distinguishes it from creating new conversion actions (sibling: create_conversion_action). This fully clarifies the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for modifying actions created previously, nor does it direct users to get_conversions to obtain the necessary conversionId. The word 'existing' implies exclusion of creation but no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. However, it only repeats the tool's name ('Create asset group') with a context qualifier ('for Performance Max') and adds no information about side effects, required relationships, auth needs, or response behavior. The description essentially restates the name without explaining what creating an asset group entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word ('Create', 'asset group', 'for Performance Max') contributes to purpose clarity. It is appropriately sized for the tool's simple nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a creation tool with 4 required parameters and no output schema. It lacks context about the relationship to Performance Max campaigns, the role of finalUrls, and what the agent should expect after invocation. The schema covers parameters but the description does not provide operational context, leaving the agent with insufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (name, campaignId, customerId have descriptions), so the baseline is 3. The description adds no additional parameter meaning beyond the schema. The 'finalUrls' parameter lacks a schema description and is not clarified in the description, which is a gap, but the overall schema coverage is high enough that the description does not need to compensate heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (asset group), and the context (for Performance Max). This distinguishes it from sibling tools like create_ad_group or create_performance_max_campaign, and there is no other asset group creation tool among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as needing an existing Performance Max campaign, nor does it explain that asset groups are a required component of Performance Max campaigns. No alternatives or exclusions are noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure, but only states 'create a customer match audience list.' It does not mention required prior steps (e.g., data upload), permissions, side effects, or how uploadKeyType impacts behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no extraneous words. It is appropriately sized for a simple creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, and no output schema, the description is too minimal. It does not clarify what a customer match list is, how it differs from other audience tools, or what the uploadKeyType values imply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema fields; it does not explain the relationship between customerId, name, and uploadKeyType.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific resource (customer match audience list). The term 'customer match' differentiates this from sibling tools like create_custom_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like upload_customer_match_data or create_custom_audience. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create' which implies mutation, but does not mention permissions required, side effects, or return behavior. This is minimal and insufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is extremely concise and free of filler. Every word earns its place, making it easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a campaign creation operation with no output schema and no annotations, and the description is too terse to cover the behavioral or contextual aspects. Given the complexity of Google Ads campaign types, this description is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 75% of parameters with descriptions, so most parameter meanings are available. However, the description adds no additional parameter context beyond what the schema already provides, and the 'targetAudience' enum lacks description in both schema and tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and identifies a distinct resource type 'Demand Gen campaign', clearly distinguishing it from sibling tools like 'create_campaign' or 'create_performance_max_campaign'. This provides immediate clarity on 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use Demand Gen campaigns versus other campaign types. It does not mention any prerequisites, exclusions, or alternative tools, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a non-mutating read operation, but the description does not disclose return format, pagination, permissions required, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words or redundant details. It is ideally sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is minimal but lacks important contextual information such as return contents, scope of results (all strategies vs. filtered), and relationship to adjacent tools like 'create_bidding_strategy'. It does not fully satisfy the informational needs of an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'customerId' as 'Google Ads customer ID' (100% coverage). The description adds no additional parameter context, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('automated bidding strategies'), making the tool's purpose unambiguous. It is distinct from sibling tools like 'create_bidding_strategy' or 'get_bid_simulations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives such as 'create_bidding_strategy' or 'get_bid_simulations'. It gives no context about prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'upload' without explaining side effects (e.g., whether data is merged or overwritten), required data hashing format, or any validation or response behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core action. No wasted words; it earns its place while remaining appropriately terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a data upload operation with no annotations and no output schema. The description fails to provide essential context such as prerequisites (list must exist), data formatting requirements (hashed identifiers), or what happens to existing list data. This leaves the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; all three parameters (customerId, userListId, customerData) are already described in the schema. The tool description adds no additional meaning beyond reiterating the upload operation. Baseline 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload), the object (customer data), and the destination (customer match list). It is specific enough to distinguish from sibling tools like create_customer_match_list (which creates the list) and import_offline_conversions (which handles conversion data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that the customer match list must already exist (via create_customer_match_list) or clarify whether this is for appending vs. replacing data. The description gives no contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It implies a read-only operation but does not mention pagination, data scope, required permissions, or what an experiment includes. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('List campaign experiments') with no superfluous words, making it easy to parse and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is adequate but lacks details about return values or experiment scope. It does not explain what constitutes a campaign experiment, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter customerId, which is described as 'Google Ads customer ID'. The description adds no parameter-specific information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List campaign experiments' uses a specific verb and resource, clearly distinguishing it from sibling tools like get_campaigns or create_campaign_experiment. It precisely states 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios where listing experiments is appropriate or how it differs from related read tools like get_campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates a mutation (remove) but does not disclose side effects, reversibility, idempotency, or any consequences beyond the immediate action. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. Every word contributes to meaning, making it concise and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with three clearly documented parameters and no output schema, the description is minimally adequate. However, it lacks any context about the operation's effects or how it fits into the broader workflow (e.g., what happens to the campaign after removal). Given the absence of annotations, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (audienceId, campaignId, customerId) described in the schema. The description adds no additional parameter meaning beyond what the schema already provides, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and identifies the exact resource ('audience targeting from a campaign'). It clearly distinguishes from sibling tool add_audience_to_campaign by stating the opposite action. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where removal is appropriate. The description only states the action, leaving the usage context entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a critical non-default behavior: campaigns are created in PAUSED state, which prevents accidental spend. However, it does not disclose return values, error handling, or permission requirements, leaving significant behavioral gaps. The single disclosed behavior is valuable, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and a key state detail. There is no fluff or repetition. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a detailed schema, the description is too sparse for a tool with no annotations and no output schema. It lacks high-level workflow context such as what the tool returns (e.g., campaign resource name), how it relates to the many specialized campaign-creation siblings, and the implication of the PAUSED state (e.g., need to call update_campaign_status to activate). This leaves the agent under-informed for real-world use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all six parameters, including meaningful details like budget units (micros) and the enum for channel type. The description adds no parameter-level information, but the schema already does the heavy lifting. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Create a new campaign.' The parenthetical '(in PAUSED state)' adds a key behavioral detail that distinguishes it from update_campaign_status and signals its creation semantics. This is unambiguous and distinct from specialized campaign creators like create_performance_max_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided. The mention of PAUSED state hints at a follow-up activation step, but it does not say when to use this tool versus the specialized campaign creation siblings (e.g., create_performance_max_campaign, create_demand_gen_campaign). There are no exclusions or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Dismiss' implies a state-changing action, but it does not disclose side effects, reversibility, permission requirements, or what happens to the recommendation afterward. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It conveys the core purpose efficiently, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two clearly documented parameters, the description is adequate but not complete. It lacks details about the expected response (e.g., success/failure indicators) and any post-dismissal effects. Since there are no annotations and no output schema, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (customerId and recommendationId), giving 100% schema coverage. The description itself does not add extra parameter details, but the schema is sufficient, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Dismiss a Google recommendation' uses a specific verb ('dismiss') and a clear resource ('recommendation'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like 'apply_recommendation' and 'get_recommendations' by implying the action of rejecting or discarding a recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by contrasting with sibling tools (apply vs. dismiss), but it does not explicitly state when to use this tool over alternatives. There is no mention of prerequisites, when dismissing is appropriate, or that it differs from simply ignoring a recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not mention return format, pagination, required permissions, or filtering nuances. Minimal detail for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with the action. Perfectly concise and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no output schema. The description explains the core purpose and the schema documents parameters, but it does not disclose return value shape or explicitly state that campaignId is optional. Adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions, and the phrase 'for a customer or campaign' maps directly to customerId and campaignId. The description adds no additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource ('ad groups') and the scope ('for a customer or campaign'), making it specific and distinct from sibling tools like get_campaigns and get_ads. The verb 'Get' unambiguously indicates a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you use this when you need ad groups for a customer or campaign. However, there is no explicit comparison to alternatives like get_ads or get_campaigns, nor any guidance on when not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Update' without mentioning that REMOVED is likely destructive or irreversible, whether permissions are required, or how the API responds. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool, though it borders on under-specification; still, conciseness itself is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should provide more context about side effects, especially the implications of setting status to REMOVED, and any required permissions. The current description leaves the agent without essential behavioral information, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described (customerId, campaignId, status). The description adds no extra meaning beyond the schema; the enum values in the description duplicate the schema's enum. Baseline score of 3 is appropriate when the schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('campaign status'), and lists the allowed status values (ENABLED, PAUSED, REMOVED), which clearly distinguishes it from sibling tools like create_campaign or get_campaigns. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever a campaign's status needs to be changed to one of the three listed values. It does not explicitly name alternatives or exclusions, but the tool's name and the status enum provide clear context, making it easy for an agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It states the operation ('add negative keywords') but discloses no side effects, idempotency, required permissions, or potential conflicts with existing negative keywords. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any filler. It is concise and well-structured, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three well-described parameters and no output schema. The description covers the essential action and target. While it lacks details like whether the operation replaces existing negatives or requires specific permissions, for a straightforward add operation it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter (keywords, adGroupId, customerId) clearly described. The description adds no additional meaning beyond the operation name, but the schema already explains the parameters sufficiently, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add negative keywords to an ad group' uses a specific verb ('add') and clearly identifies the resource ('negative keywords') and target ('ad group'). It distinguishes itself from the sibling tool 'add_keywords' by the word 'negative', 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (adding exclusions to an ad group) but does not explicitly state when to use this tool versus alternatives like 'add_keywords' or 'get_keywords'. There is no mention of prerequisites or when not to use it, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'accessible' but does not specify what fields are returned (e.g., account names, IDs), whether it includes child accounts, or any authorization implications. The scope of 'accessible' is undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and perfectly sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter listing tool, the description is mostly sufficient. However, since there is no output schema, it leaves the return format (e.g., IDs, names, structure) unspecified, which is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter information, and there is nothing to compensate for in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and a clear resource 'Google Ads accounts', with scope 'accessible' which distinguishes it from sibling tools like get_account_hierarchy. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of use cases. It does not clarify how this differs from get_account_hierarchy or other account-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses one key trait—the ad group starts in PAUSED state—but does not mention other important behaviors such as whether the ad group is immediately available, whether the operation is idempotent, or what the response contains. It is partially transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the action and key state detail. It contains no filler or redundant information, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema's completeness, the description covers the core purpose and the paused-state behavior. However, it lacks guidance on the creation result (e.g., generated ad group ID) and any follow-up steps, which would make it more complete. It is adequate but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all parameters, so the schema already provides the meaning. The description adds no extra parameter-level context beyond what's in the schema, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new ad group'), and adds a specific detail ('in PAUSED state') that distinguishes it from other creation tools. It unambiguously identifies what the tool does relative to siblings like create_campaign or create_responsive_search_ad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating ad groups, but it does not explicitly state when to use it versus alternatives, mention prerequisites (e.g., a valid campaignId), or explain the significance of the PAUSED state. No exclusions or context are provided, so it's merely implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full disclosure burden. It does disclose the important behavioral trait that the ad is created in a PAUSED state, which prevents unintended live serving. However, it does not mention other relevant details such as what happens to existing ads, whether the operation is idempotent, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, informative sentence that immediately communicates the action and a key behavioral detail (PAUSED state) without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple 5-parameter schema fully documented in the schema and a clear one-line description, the tool is adequately specified for an agent to create an RSA. The only notable gap is the lack of any indication of the response format, which might matter given there is no output schema. Still, the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter descriptions, covering constraints like 'Headlines (3-15, max 30 chars each)' and 'Descriptions (2-4, max 90 chars each)'. The description itself adds no parameter-level meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' and names the exact resource 'responsive search ad', clearly distinguishing it from sibling tools like 'create_ad_group' or 'create_smart_campaign'. The added detail of 'in PAUSED state' further clarifies the tool's behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like create_smart_campaign or create_performance_max_campaign. Usage is implied by the name and resource type, but no contextual conditions or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-ads-mcp-server MCP server](https://glama.ai/mcp/servers/anegash/google-ads-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/anegash/google-ads-mcp-server)

Score Badge

Copy to your README.md:

[![google-ads-mcp-server MCP server](https://glama.ai/mcp/servers/anegash/google-ads-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/anegash/google-ads-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anegash/google-ads-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server