Google Ads MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clear, distinct purposes with good descriptions, but there is overlap among multiple status update tools (batch_status_change, bulk_update_ad_group_status, update_ad_group_status, etc.) and among various performance report tools that operate at different levels.
Naming Consistency4/5
Tool names consistently use the `google_ads_verb_noun` pattern, with only minor deviations like `google_ads_recommendations` alongside `google_ads_get_recommendations`. The naming is clear and predictable overall.
Tool Count3/5
142 tools is very large but justified by the complexity of Google Ads. However, there is significant redundancy (e.g., multiple ways to update status) that could be consolidated, making the count feel excessive for an MCP server.
Completeness4/5
The tool surface covers nearly all major areas of Google Ads management, including campaigns, ad groups, keywords, extensions, conversions, recommendations, and shopping. Minor gaps exist, such as lack of tools for listing/updating ad extensions beyond creation.
Average 3.7/5 across 142 of 142 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Compare performance' and returns a 'Comparison report', but fails to mention whether the operation is read-only, what metrics are compared, or any side effects. The tool likely performs a read-only query, but this is not explicitly stated.
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 short and starts with a clear one-line purpose. However, the listing of parameters in a docstring format adds redundancy since it largely repeats the schema. This could be more concise by integrating parameter details into a narrative or omitting the list if it adds no value.
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?
Although an output schema exists, the description's 'Returns: Comparison report' is too vague. It does not mention what metrics, dimensions, or format are included. The parameter 'date_range' lacks details on accepted values. Overall, the description leaves significant gaps for a tool with 4 parameters and a meaningful output.
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 0%, so the description must compensate. For 'customer_id', it adds '(without hyphens)', which is helpful. But for 'ad_id_1', 'ad_id_2', and 'date_range', it merely repeats parameter names without adding format, constraints, or examples. The default value for 'date_range' is not explained, and possible values are not given.
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 compares performance between two ads for A/B testing. The verb 'compare' and resource 'ads' are specific, and the tool name includes 'compare_ad_performance', making its purpose distinct from siblings like 'google_ads_campaign_comparison'. However, it does not explicitly differentiate itself from other comparison 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 given on when to use this tool versus alternatives such as campaign comparison or period comparison. The intended use case (A/B testing two ads) is implied by the purpose, but no explicit context or exclusions are provided.
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 says 'Get detailed information', which is vague. It doesn't mention that the operation is read-only, any authentication requirements, rate limits, or size of returned data. This fails to inform the agent of important behavioral traits.
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 short and structured with Args/Returns sections, but it is slightly too sparse. It could include more detail without being verbose. The returns section is a single line that adds little. Every sentence earns its place, but the Returns part is weak.
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 existence of an output schema, the returns description can be brief, but the description lacks broader context. It does not explain what 'detailed information' entails or relate to the large set of sibling tools. The agent may not know how this tool fits into a workflow.
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 no descriptions (0% coverage). The description adds 'without hyphens' for customer_id and implies both are required. This adds meaningful constraint beyond schema structure. However, it does not specify format for campaign_id or other semantic details, leaving some gap.
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 detailed campaign information, identifying the resource (campaign) and action (get details). It specifies required parameters (customer_id, campaign_id). However, it does not differentiate from many similar get_* sibling tools like google_ads_get_ad_group_details, so clarity is slightly reduced.
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 indicate when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Given numerous sibling get_* tools, agents would benefit from explicit context, which is absent.
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 provided, so the description carries full burden. It states it 'adds' keywords but omits important behavioral traits like idempotency, duplicate handling, permission needs, or side effects. For a mutation tool, this 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?
Well-structured with Args, Returns, and Example sections. The example is minimal but relevant. No unnecessary sentences, though could be more streamlined.
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 numerous sibling tools, the description does not differentiate from 'batch_add_keywords' or 'add_keywords.' Output schema exists but is not leveraged to describe return values, leaving agent uninformed about success details.
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 0%, but the description adds value by listing allowed match types, default, and optional bid. However, it lacks format constraints for IDs and keyword texts, limiting completeness.
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 'Bulk add multiple keywords with the same match type,' specifying the action and resource. However, it does not differentiate from the sibling tool 'batch_add_keywords,' which likely performs a similar function, reducing clarity.
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 like 'add_keywords' or 'batch_add_keywords.' Missing prerequisites or exclusions, leaving the agent to infer 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 full burden for behavioral disclosure. It implies a read-only operation (performance comparison) but does not explicitly state safety, permissions, or side effects. The lack of behavioral context 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 concise, with a clear one-liner purpose and an example that demonstrates usage. It avoids unnecessary details and is front-loaded with the main action.
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 that an output schema exists, the description does not need to detail return values. However, it could mention what metrics are compared (e.g., clicks, impressions) or provide more context about the comparison scope. The example helps but the description is somewhat minimal for a tool with 5 required parameters.
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 description adds value beyond the input schema by specifying format requirements (YYYY-MM-DD) and clarifying that customer_id should be without hyphens. However, it only covers the 5 parameters with brief notes; schema coverage is 0%, so the description partially compensates but could be more detailed (e.g., allowed date ranges).
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 compares performance between two time periods. However, it does not explicitly distinguish from sibling tools like google_ads_campaign_comparison or google_ads_compare_ad_performance, which are similar in nature.
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 simply describes the function without indicating context or exclusions, leaving the agent uninformed about 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?
No annotations provided, so description should disclose behavioral traits. It does not mention read-only nature, potential rate limits, required permissions, or any side effects. The description merely states the function without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with Args, Returns, and Example sections. It uses minimal words effectively, though the example could be integrated more naturally. No redundant content.
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 low complexity and presence of output schema, description covers basic purpose and parameter usage. However, it lacks usage guidelines and behavioral transparency, which are necessary for complete contextual understanding. It is minimally adequate.
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 has 0% description coverage, so description must compensate. It adds meaning by describing customer_id format ('without hyphens') and providing an example date_range value ('LAST_30_DAYS'). However, it does not list all valid date_range options or constraints, leaving some ambiguity.
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 clearly states 'Get account-wide conversion summary' with specific verb and resource. However, it does not explicitly differentiate from sibling tools like google_ads_get_conversion_performance or google_ads_account_performance, which also deal with conversions or summaries.
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 google_ads_get_conversion_performance or google_ads_campaign_performance. The description lacks context for when an account-wide summary is preferred over more granular reports.
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 disclose behavioral traits. It only states it returns 'detailed ad information' but does not mention rate limits, authentication needs, or the nature of the operation (read-only). The lack of detail hinders 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 concise and well-structured: a clear purpose sentence followed by labeled sections for arguments and returns. Every sentence adds value, though the returns section is redundant with the output schema.
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 existence of an output schema, the description does not need to detail return values. However, it lacks information on prerequisites or the scope of 'detailed information,' and the parameter descriptions are minimal. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It provides brief descriptions for all three parameters, including a useful note about customer_id format ('without hyphens'). However, it does not elaborate on expected formats for ad_group_id or ad_id, leaving ambiguity.
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 verb 'get' and the resource 'ad', specifying it provides detailed information. However, it does not differentiate from sibling tools like 'get_ad_performance' or 'check_ad_approval_status', which have similar purposes.
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. There are no exclusions, context, or references to other tools, leaving the agent without direction 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?
Annotations are absent, so the description carries the full burden. It states 'Get detailed information', implying a read operation, but does not disclose any behavioral traits like required permissions, rate limits, error handling, or what happens if the ad group is not found. This is minimal 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 very short (4 lines) and front-loads the purpose. It wastes no words, but the brevity sacrifices important details. Nonetheless, it is concise and to the point.
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?
An output schema exists, so return value details are covered elsewhere. However, given the complexity of the Google Ads API and numerous sibling tools, the description lacks context on what 'detailed information' includes (e.g., name, status, targeting settings). This leaves an agent uncertain whether this tool is appropriate.
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?
Input schema has 0% description coverage; the description adds notes: 'Customer ID (without hyphens)' and 'Ad group ID', which provide useful formatting guidance beyond the schema titles. This is helpful but still minimal, as it does not explain the expected format or constraints beyond the hyphens note.
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+resource ('Get detailed information about an ad group'), clearly indicating the tool's purpose. However, it does not distinguish this tool from siblings like 'google_ads_get_ad_group_performance' or 'google_ads_list_ad_groups', which also deal with 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 usage guidelines are provided. There is no indication of when to use this tool versus alternatives, such as when detailed information is needed compared to performance metrics or a list of ad groups.
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 merely says 'Get conversion performance metrics' and returns data, but does not state if the operation is read-only, requires specific permissions, or has any side effects. The return format is vague ('Conversion performance data').
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 relatively concise, using a docstring format with arguments, returns, and an example. It is front-loaded with the purpose, though the example and returns sections add some redundancy.
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 3 parameters and no nested objects, the description includes an example but does not leverage the existing output schema to explain results. It omits prerequisites like account access or rate limits, which are not covered by any annotations.
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 0%, meaning the description must add value. It provides extra context for 'customer_id' (without hyphens) and 'conversion_action_id' (optional specific conversion), which are not in the schema. However, 'date_range' lacks additional meaning beyond the schema default.
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 'Get conversion performance metrics', which is a specific verb+resource. However, among many sibling tools with 'conversion' in their name (e.g., google_ads_conversion_summary_report, google_ads_app_conversions), the description does not differentiate this tool from others, lacking sibling 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?
The description provides no guidance on when to use this tool versus alternatives like google_ads_conversion_summary_report or other performance reports. It lacks explicit context for selection 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 provided. The description implies a read operation but does not explicitly state safety, rate limits, or other behavioral traits. It lacks transparency about data freshness or scope.
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 docstring is concise and structured with Args/Returns sections, but it is not front-loaded with a clear one-sentence purpose. The format is typical for Python but could be improved for AI consumption.
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 0% schema coverage and no annotations, the description should compensate but remains minimal. It does not explain what metrics are included, data aggregation, or output format, leaving gaps despite the presence of an output schema.
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 description adds value beyond the bare schema by specifying format for customer_id, optionality for ad_group_id, and examples for date_range. However, it does not list all possible date_range values or explain the return structure.
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?
Describes the tool as getting 'keyword performance metrics', which is a specific verb and resource. However, it does not differentiate from sibling tools like `get_keyword_quality_score` or `list_keywords` that also deal with keywords.
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. There is no mention of prerequisites, limitations, or specific contexts where this 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, the description should disclose behavioral traits. It only mentions return data is a 'Search terms report with performance data' but does not address safety (read-only), rate limits, or any side effects. The tool appears to be read-only but is not explicitly stated.
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 concise, using clear sections for args and returns. Every sentence adds value, though the 'Args' section could be slightly more compact. No filler or repetition.
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 description covers the basic purpose and parameters, but given the presence of an output schema, it does not elaborate on return structure or usage contexts like pagination or filtering. It is adequate 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?
The description adds value by explaining the customer_id format (without hyphens) and listing date range options. However, schema coverage is 0% and the description mostly paraphrases schema fields without adding deeper semantic meaning like allowed patterns or validation.
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 search terms that triggered ads for keywords in an ad group. However, it does not distinguish this from the sibling tool 'google_ads_search_terms', which likely serves a similar or overlapping 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?
No guidance is provided on when to use this tool versus alternatives, such as the broader 'google_ads_search_terms'. There is no mention of prerequisites, exclusions, or typical 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?
With no annotations, the description should disclose behavioral details. It only states it lists conversion actions but does not mention read-only nature, permissions, pagination, sorting, or rate limits. The docstring adds no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Main description is a single clear sentence. The docstring is structured with Args, Returns, Example. However, some critical info (like parameter details) is missing from the main description, making it less effective.
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 3 parameters and an output schema, the description should explain what the tool returns and how parameters affect results. It doesn't mention default behavior of include_removed (false) or response_format. The example is minimal.
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 0% description coverage, so the description must explain parameters. It merely lists parameter names without explaining their meaning or behavior (e.g., include_removed, response_format). The example only shows customer_id.
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 all conversion actions in the account' clearly states the verb (list), resource (conversion actions), and scope (in the account). This distinguishes it from sibling tools like get_conversion_performance or create_conversion_action.
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, exclusions, or context for selecting this tool over other list tools such as google_ads_list_accounts.
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 fully disclose behavioral traits. It only states the action and return type, omitting details like whether it requires specific permissions, if the list is exhaustive, or any side effects. This leaves significant uncertainty for an 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 very short, with a clear structure: a summary line followed by Args and Returns sections. Every sentence is necessary, but it could be more concise by omitting the explicit 'Args' and 'Returns' labels, though this structure aids readability. No waste, but slightly overly terse.
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 (list keywords) and the presence of an output schema (not shown), the description adequately states the input and output. However, it lacks contextual details like pagination, permission requirements, or scope limitations (e.g., maximum results). For a basic tool, it is minimally sufficient but not 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?
Schema description coverage is 0%, so the description must compensate. It adds basic meaning: 'customer_id: Customer ID (without hyphens)' provides a format hint, and 'ad_group_id: Ad group ID' identifies the parameter. However, the descriptions are minimal and do not clarify the expected format or constraints beyond the schema's type.
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: 'List all keywords in an ad group.' It specifies the verb (list), resource (keywords), and scope (ad group), making it distinct from sibling tools like add_keywords or get_keyword_performance. However, it does not differentiate from other list tools (e.g., list_ads, list_ad_groups), but the purpose is still clear.
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 prerequisites, such as needing an ad group ID, nor does it exclude scenarios where other tools (e.g., get_keyword_performance) would be more appropriate. A user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must fully disclose behavior. It mentions it returns metrics but does not explain auth requirements, rate limits, error handling, or any side effects. The 'all-conversions data' hint is useful but 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?
Well-structured with Args, Returns, Example. Concise but informative. No unnecessary words.
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?
With an output schema present, the description need not detail return fields. However, it lacks mention that the campaign must be a Performance Max campaign and does not clarify the scope of 'all-conversions data'. Adequate but could be more 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 description adds value by explaining customer_id format and date_range options, and provides an example. However, campaign_id is not described, and schema coverage is 0%. The docstring partly compensates for schema gaps.
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 it retrieves performance insights for Performance Max campaigns, including all-conversions data. However, it does not differentiate from sibling tools like 'campaign_performance' or 'performance_insights', which 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?
No explicit guidance on when to use this tool versus alternatives. The description provides an example but lacks context on selection criteria or prerequisites.
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 must disclose behavior. It only states 'Update ad group status' with possible values and returns 'Success message'. There is no information on whether the operation is synchronous, reversible, or has side effects (e.g., impact on campaigns). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded, with a clear structure: purpose, args, returns. Every sentence is necessary, though it could be slightly more informative without increasing length significantly.
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 lacks context about when to use this single-update tool versus bulk or other update tools. It also does not describe the output schema (though one exists), just 'Success message'. For a simple tool, more context is needed to avoid ambiguity.
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?
With schema description coverage at 0%, the description compensates by explaining each parameter: customer_id format, ad_group_id as ID, and status with enumerated values (ENABLED, PAUSED, REMOVED). However, it does not clarify if these are the exact allowed strings or provide additional constraints. This is adequate but not excellent.
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 updates ad group status to enable, pause, or remove. However, it does not differentiate from sibling tools like 'google_ads_bulk_update_ad_group_status' which performs the same action in bulk, leaving the AI agent without guidance on which to choose for a single update.
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 guidelines are provided. The description lacks information on prerequisites (e.g., ad group must exist), when to use this tool versus alternatives (e.g., bulk update or other update tools), or any constraints. The agent has no context for appropriate use.
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 solely convey behavioral traits. It only says 'Returns: Performance metrics' without specifying what metrics (e.g., impressions, clicks, cost) or side effects. The generic term 'performance metrics' lacks the detail needed for transparent execution.
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 concise, front-loading the purpose, then clearly separating Args and Returns sections. It is easy to parse, though the Args section could be more structured (e.g., markdown bullet list). Overall efficient and well-organized.
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 existence of an output schema (not shown), description need not detail return values, but it fails to provide usage context among many siblings, behavioral notes, or parameter provenance (e.g., how to find ad_group_id). This leaves an AI agent underinformed for correct selection and invocation.
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?
With 0% schema description coverage, the description adds meaningful context: clarifies customer_id format ('without hyphens'), lists example date_range constants, and hints at parameters' roles. This significantly aids parameter understanding beyond the bare 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 tool retrieves performance metrics for an ad group over a date range, specifying the resource 'ad group'. However, it does not distinguish itself from sibling tools like google_ads_get_ad_performance or google_ads_get_keyword_performance, missing an opportunity to clarify scope differences.
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, when not to use it, or any prerequisites. It only states the basic operation, leaving an AI agent without context for selection among many similar 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?
With no annotations, the description should reveal behavioral traits like idempotency, side effects, or error handling. It only states it 'adds' and returns a result, leaving agent unaware of behavior if extension already exists or if there are 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?
Description is well-structured with separate sections for purpose, parameters, returns, and an example. No unnecessary repetition, but minor redundancy in explaining call extension purpose in first paragraph could be tightened.
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?
Covers purpose, parameters, and return, but lacks usage guidelines and behavioral transparency. For a tool with no annotations and 5 parameters, additional context about idempotency or preconditions would improve completeness.
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?
Schema coverage is 0%, but description compensates with detailed parameter explanations: customer_id format, campaign_id numeric, phone number format, country_code default, and track_calls boolean. This adds significant value beyond schema titles and types.
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 clearly states 'Add call extension to a campaign' and explains its function. While the name and first sentence differentiate it from sibling extension tools (e.g., add_callout_extension), it does not explicitly distinguish itself from other 'add' operations.
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 other extension tools or prerequisites (e.g., campaign must exist). The example is provided but lacks conditional context or alternatives.
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 provided; the description only states it pauses campaigns (a destructive action) but omits prerequisites (e.g., permissions), error handling for invalid IDs, behavior on partial failures, or any rate limits. The return is vaguely described as 'Batch operation result.'
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 short and front-loaded with the action; includes an example. Slight redundancy with schema but acceptable; no wasted sentences.
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 existence of an output schema, the description lacks completeness for a batch operation: no mention of batch limits, error handling, or what 'Batch operation result' contains. For a mutation tool with no annotations, more behavioral context is needed.
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 0%, so the description must compensate. The 'Args' section adds meaning beyond the schema: customer_id format (10 digits, no hyphens) and campaign_ids as comma-separated list. However, it does not specify that IDs are numeric or maximum length, and the description is minimal.
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 explicitly states 'Pause multiple campaigns in a single batch operation,' clearly indicating the verb (pause) and resource (campaigns), and distinguishes from sibling tools like batch_enable_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?
No explicit guidance on when to use this tool vs. alternatives (e.g., pausing campaigns individually or using batch_status_change). The example implies usage but lacks context about when it's 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?
No annotations are present, so the description must fully disclose behavior. It only says 'Get ad performance metrics' and returns an 'Ad performance report', which is vague. It does not mention whether data is aggregated, what metrics are included, or any limitations like rate limits or data freshness.
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 concise with a clear one-sentence purpose and structured Args/Returns section. However, the Returns section is too vague ('Ad performance report') and could be more informative without adding much length.
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?
With 3 parameters, an output schema, and many sibling tools, the description is adequate but lacks details on what metrics are included, whether it returns per-ad data or summaries, and how it differs from similar tools. The output schema likely specifies the structure, but the description doesn't bridge that gap.
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?
Schema description coverage is 0%, so the description compensates by explaining parameters: customer_id format (without hyphens), ad_group_id as optional filter, and date_range with example values (TODAY, YESTERDAY, etc.). This adds meaningful context 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 states 'Get ad performance metrics' which is a clear verb+resource pair. However, it does not differentiate from sibling tools like google_ads_campaign_performance or google_ads_get_ad_group_performance, leaving ambiguity about what exactly 'ad performance' entails compared to other 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?
No guidance is provided on when to use this tool versus alternatives. Given many sibling performance reporting tools, the description should indicate when this is appropriate (e.g., for individual ad-level metrics) versus for campaigns or ad groups.
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 states the output is aggregate insights, with no disclosure of side effects or auth requirements. The read-only nature is implicit but not stated, which is a 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 concise and well-structured with sections for Args, Returns, and Example. It front-loads the purpose and quickly provides essential details. No redundant sentences.
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 an output schema exists, the description minimally explains return values. It covers the basics but lacks detail on the exact fields in 'aggregate recommendation insights'. Could mention what counts as 'potential impact'.
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?
Schema has 0% description coverage, but the description adds meaning: customer_id format ('without hyphens') and campaign_id as optional filter. The example reinforces usage. This adds value beyond the bare 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 tool gets aggregate insights about recommendations with total projected impact, grouped by type. This distinguishes it from related tools like get_recommendations (individual details) or get_bid_recommendations. The purpose is specific and adequately described.
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 implies use when a high-level summary is needed, but does not explicitly differentiate from siblings like google_ads_get_recommendations. No guidance on when not to use this tool or when alternatives are better.
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 should fully disclose behavior. It only states it returns a list of recommendations, without mentioning pagination, rate limits, or read-only nature. This is insufficient for a mutation-free 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 concise but includes an args section that largely repeats the schema. It is front-loaded with the main purpose but could be tighter.
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 has 4 parameters and no annotations, the description covers parameter semantics adequately and mentions return type. However, it lacks behavioral context and differentiation from siblings, making it minimally viable.
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 description adds meaningful details beyond the schema titles, such as customer_id format ('without hyphens'), example recommendation types, limit range (1-100), and response_format values ('markdown' or 'json'). This compensates for the 0% 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 clearly states it retrieves recommendations using 'Get AI-powered optimization recommendations', but it does not differentiate from the sibling tool 'google_ads_get_recommendations' which likely has similar functionality.
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 google_ads_get_recommendations, apply_recommendation, or others. The description does not mention 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 provided, the description carries the full burden of disclosing behavioral traits. While 'view' implies a read-only operation, there is no explicit statement about safety, required permissions, or rate limits. The description does not mention potential side effects or authorization needs, which 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 concise and well-structured, with a clear purpose statement followed by an easy-to-scan Args section and a Returns note. Every sentence contributes meaning, and there is no redundancy or 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?
Given the tool's complexity (5 parameters, output schema present) and the abundance of sibling tools, the description covers the basics but lacks details on the specific performance metrics returned. The output schema exists, so the return values are partially covered, but the description does not mention query scope (e.g., account-level vs campaign-level) or historical limitations, leaving some gaps for a well-informed 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 0%, so the description must compensate. It provides brief explanations for each parameter (e.g., 'Customer ID without hyphens' for customer_id, 'Optional campaign ID to filter' for campaign_id). These add value beyond the schema titles, but lack details like valid date range formats or allowable values. Overall, it offers moderate additional meaning.
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's purpose: 'View actual search queries that triggered your ads' and explains it shows the search terms report with performance metrics for identifying keyword opportunities and negatives. The verb 'view' and specific resource are well-defined, though it does not differentiate from similar sibling tools like google_ads_get_search_terms_for_keyword.
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 mentions identifying keyword opportunities and negative keyword candidates as use cases, but provides no guidance on when to use this tool versus alternatives (e.g., google_ads_get_keyword_performance, google_ads_campaign_performance). There is no comparison or exclusion criteria, 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 were provided, so the description bears full responsibility for behavioral disclosure. It only states 'Update conversion action settings' without describing side effects, idempotency, permission requirements, or consequences of optional parameters like null values.
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 highly concise: a single-purpose sentence, clearly separated args with brief explanations, a returns note, and an example. No unnecessary words or redundancy.
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 simplicity of the tool (4 params, simple mutation) and presence of an output schema, the description covers the basics but omits potential pitfalls (e.g., required permissions, effect of setting conversion_value to null). It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing additional context for customer_id (no hyphens) and status enum values. However, it does not explain the semantics of conversion_value ('New default value' is vague) or behavior when set to null. Partial but not exhaustive.
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 'Update conversion action settings', directly identifying the verb and resource. While it doesn't explicitly differentiate from sibling tools (e.g., google_ads_create_conversion_action), the name and description make the specific use 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?
No guidance on when to use this tool versus alternatives like create or other update tools. There is no context about prerequisites, when to avoid, or how it fits into a workflow.
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 exist, so the description must fully disclose behavioral traits. It only states the upload action and parameter formats, but does not mention idempotency, duplicate handling, required permissions, error conditions, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with an Args section, Returns note, and an example. It is reasonably concise, though the example is lengthy but provides necessary clarification for the nested structure.
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 description adequately explains input parameters and return value, but lacks behavioral details (e.g., idempotency, error handling) and usage context. For a tool with no annotations and a complex nested parameter, it is functional but not comprehensive.
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 input schema has 0% description coverage, leaving the description to explain parameters. It adds crucial semantics for call_conversions, including field names, format hints (E.164, datetime), optional fields, and an example. It does not detail customer_id or conversion_action_id, but their purpose is clear from context.
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 ('Upload call conversion data') and the resource ('phone calls that converted'). It distinguishes from sibling upload tools by specifying 'call conversions' as opposed to offline conversions, customer match, etc., though it does not explicitly contrast with them.
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 (e.g., google_ads_upload_offline_conversions). There are no prerequisites, exclusions, or contextual hints about typical use cases.
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?
The description mentions that the tool is a placeholder and requires Keyword Plan API setup, which adds transparency. However, it lacks details on what happens if the API is not set up, any rate limits, or the exact behavior of the traffic estimation process.
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 structured with clear sections (Args, Returns, Note) and is reasonably concise. It front-loads the main purpose and includes important notes, making it easy to parse.
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 estimating keyword traffic in Google Ads, the description is too brief. It does not explain the output format or how to interpret the traffic estimates, and the note about being a placeholder suggests incomplete implementation. Sibling tools with similar purposes are not addressed.
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?
Given the low schema description coverage (0%), the description compensates well by explaining each parameter: customer_id format (no hyphens), keywords as a list, and location_ids optional with an example. This adds semantic 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 'Get traffic estimates for keywords,' using a specific verb and resource. However, it does not differentiate from siblings like keyword_forecast or keyword_ideas, which could lead to confusion about which tool to use.
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 keyword_forecast or keyword_ideas. The note about being a placeholder and requiring Keyword Plan API setup is a prerequisite, but not a usage guideline.
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 says 'Get performance' without explaining metrics, aggregation, or permissions, leaving significant behavioral gaps.
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 concise with a clear purpose, args list, returns, and example. It is front-loaded and without redundancy, though the args list repeats some schema info.
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 tool with 3 parameters and an output schema, the description provides basic usage but lacks details on location granularity, returned metrics, and date range options. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds customer_id format ('without hyphens'), notes campaign_id is optional, and provides an example with 'LAST_30_DAYS', but does not enumerate possible date_range values or describe the location format.
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 'Get performance by geographic location,' using a specific verb and resource. It distinguishes from sibling tools like google_ads_account_performance and google_ads_campaign_performance by focusing on geographic breakdown.
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. It does not mention when not to use it or provide comparisons to other performance 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. It only states 'Get...information' and 'Returns: Quality score details', which is vague. No mention of read-only nature, data freshness, rate limits, or dependencies (e.g., keyword must be active). Insufficient for safe autonomous invocation.
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 brief (5 lines), with the main purpose upfront. No filler. However, the Returns line is overly vague, which slightly reduces efficiency.
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?
There is an output schema, so return value detail is not required. But for a specialized tool, the description lacks context: what constitutes 'detailed quality score information' (e.g., components, scale). Minimal but adequate for a tool with structured output.
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 0%, so the description must compensate. It lists three parameters but adds only format hint for customer_id ('without hyphens'). For ad_group_id and criterion_id, it merely restates the names, providing no value beyond the schema itself.
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 explicitly states 'Get detailed quality score information for a keyword', using a specific verb and resource. Among siblings like get_keyword_performance, this clearly targets quality score details, distinguishing it effectively.
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 like get_keyword_performance or list_keywords. No mention of prerequisites or exclusion criteria, 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, and the description does not disclose behavioral traits beyond basic functionality. It does not mention side effects (e.g., whether updating a field resets others), permissions required, or the impact of partial updates. The returns section says 'Success message with updated configuration' but lacks detail on the response structure.
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 well-structured with Args, Returns, and an Example section. The initial sentence is clear. However, the Args list is somewhat verbose for a tool with 7 parameters; it could potentially be streamlined without losing clarity.
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 description covers all 7 parameters and includes an example. An output schema exists but is not detailed; the description mentions 'Success message with updated configuration,' which suffices. Missing guidance on optimal parameter combinations for different strategy types, but overall adequate for a simple update tool.
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?
With 0% schema description coverage, the description must fully explain parameters. It adds meaning by describing each parameter's purpose (e.g., 'New target CPA in currency units') and linking them to strategy types. However, it could be more precise (e.g., specifying currency or decimal format for target_roas).
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 'Update an existing portfolio bidding strategy's settings,' which indicates the verb and resource. It distinguishes from sibling tools like 'create_bidding_strategy' and 'assign_bidding_strategy,' but could emphasize the 'portfolio' aspect more strongly to differentiate from other update 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 explicit guidance is provided on when to use this tool versus alternatives like 'create_bidding_strategy' or 'assign_bidding_strategy.' There is no mention of prerequisites (e.g., the strategy must exist) or conditions for using specific 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, and the description does not disclose behavioral traits such as idempotency, rate limits, or authorization requirements. It only states that it returns metrics, which implies a read-only 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 concise with a clear header, metric list, parameter info, return type, and an example. Every sentence serves a purpose.
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 description covers the tool's purpose, key parameters, and provides an example. It does not mention the output schema structure, but an output schema exists. The date_range default is in the schema but not in the description.
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 description includes an Args section with clear explanations for `customer_id` (no hyphens) and `date_range` (with example values like 'LAST_30_DAYS'). Since schema coverage is 0%, the description adds significant 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 'Get account-level performance overview' and lists specific metrics, distinguishing it from campaign-level or ad-level tools. However, it does not explicitly contrast with sibling 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 does not provide guidance on when to use this tool versus alternatives like `google_ads_campaign_performance`. It only describes what it does.
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?
The description discloses that the default status is PAUSED 'for safety', implying it creates campaigns without immediate activation. However, it does not explain side effects, required permissions, or cost implications. With no annotations, more behavioral context would be beneficial.
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 uses a clean bullet-point list for parameters and a brief return statement. It is front-loaded with the purpose and each line is specific. It is slightly long but appropriate for 13 parameters.
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?
All parameters are explained, but missing high-level context such as error handling, prerequisites (e.g., billing), or how to choose between this and specialized creators. The return value is vague.
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 description adds useful meaning beyond the schema titles: e.g., customer_id format, budget example, conditional parameters for bidding strategies. Since schema description coverage is 0%, the description compensates well.
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 'Create a new Google Ads campaign' and enumerates all parameters. However, it does not differentiate from sibling tools like google_ads_create_performance_max_campaign or google_ads_create_shopping_campaign, which have more specific purposes.
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 guidance on when to use this tool versus the many specialized campaign creation tools. It does not mention prerequisites, when not to use it, or alternatives.
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 states it returns a performance breakdown, with no mention of read-only nature, data freshness, pagination, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one-line purpose, then args, returns, and an example. No unnecessary text, and the purpose is 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?
The tool has an output schema, so return values need not be detailed. However, the description could be more complete about what the time breakdown includes (e.g., metrics). With 3 params and an output schema, it is minimally adequate but lacks depth.
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 0%. The description adds context: customer_id format (without hyphens), campaign_id as optional filter, and date_range as 'Date range'. However, date_range lacks accepted format or examples beyond the default.
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 'Get performance by hour of day and day of week', which specifies the verb (get) and resource (performance with time dimension). This distinguishes it from sibling performance tools like campaign_performance or device_performance.
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 guidance on when to use this tool versus alternatives. The description does not contrast with other performance tools or provide when-not-to-use scenarios.
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 provided, so description carries full burden. It only states 'Update' without mentioning side effects, permissions, or that it overwrites existing bids. Minimal disclosure.
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?
Concise with clear Args/Returns sections. Slightly verbose but no superfluous sentences. Effective front-loading.
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?
Does not explain interaction with bidding strategies or that it only works for manual CPC. Missing behavioral context beyond basic action. Output schema exists but not detailed.
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?
Schema coverage is 0%, but description adds meaning: customer_id format (no hyphens), ad_group_id, and cpc_bid with currency units and example. Compensates well for lack of schema descriptions.
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?
Description clearly states 'Update ad group CPC bid' – a specific verb and resource. It distinguishes from sibling tools like google_ads_update_ad_group (general update) and google_ads_update_keyword_bid (keyword bid).
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 (e.g., batch updates or other bid types). No prerequisites or context about campaign type compatibility.
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?
Minimal behavioral disclosure beyond the action; no mention of permissions, reversibility, or side effects. Annotations are absent, so the description carries the full burden but fails to provide depth.
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?
Highly concise with structured Args/Returns format. Every sentence is essential with no redundancy.
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?
Adequately describes the function and parameters but lacks guidance on when to use this tool over sibling tools, especially batch/bulk variants. Output schema exists but description's return mention is vague.
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 0%, but the description adds parameter details: customer_id format, available status enum values. However, it does not explain ad_group_id and criterion_id sufficiently for easy lookup.
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 (update) and resource (keyword status) with explicit possible statuses (enable, pause, remove). It is distinct from sibling tools like bulk or bid updates.
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 like batch or bulk update tools. It does not specify exclusions or prerequisites.
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?
The description contradicts the input schema: it claims 'All parameters are optional' but customer_id and asset_group_id are marked required in the schema. This is a critical inconsistency. Beyond that, it only mentions AI mixing behavior, lacking details on side effects, error handling, or what happens to existing assets. With no annotations to fall back on, the description fails to disclose key behaviors.
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 well-structured with a brief intro, bullet-pointed parameters, and an example. It is concise and front-loaded with the main action. However, the misleading statement about parameter optionality adds unnecessary confusion, costing a slight deduction.
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 (5 parameters, output schema exists), the description lacks essential context: it does not explain whether assets are appended or replaced, what happens on duplicate names, or error scenarios. It also omits prerequisites like having an existing asset group. The contradiction further undermines completeness. While output schema reduces need for return value details, other gaps remain.
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?
Despite 0% schema description coverage, the description's Args section adds significant meaning: format of customer_id (10 digits, no hyphens), character limits (headlines max 30 chars, up to 15; descriptions max 90 chars, up to 5; long headlines max 90 chars, up to 5), and an example. This goes well beyond the bare schema types. The optionality error slightly detracts but does not affect the parameter descriptions themselves.
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: 'Upload text assets to a Performance Max asset group.' It specifies the resource (PMax asset group) and action (upload), and lists the asset types (headlines, descriptions, long headlines). This distinguishes it from other upload tools like offline conversions or call conversions, making 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 provides usage guidance by stating 'All parameters are optional - provide only the asset types you want to add,' which instructs on partial usage. However, it fails to differentiate from sibling tools (e.g., when to use this vs. google_ads_create_asset_group or other upload tools) and does not mention when not to use or prerequisites. The guidance is present but minimal.
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, and the description does not disclose behavioral traits like request limits, authentication needs, or that the operation modifies the campaign. It only indicates creation without detailing side effects or restrictions.
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 well-structured with an Args section and an example, but it contains redundant explanations (e.g., repeating 'Structured snippets highlight...'). Still, it is efficient and front-loads the 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?
Given the presence of an output schema, return values are covered. The description adequately explains parameters and provides an example, but lacks details on error handling, prerequisites (e.g., campaign must exist), or limitations.
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 0% description coverage, so the description adds value by specifying customer_id format (10 digits, no hyphens), header options, and values_json constraints (3-10 items). However, campaign_id is not elaborated, and some parameters remain opaque.
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 "Add structured snippet extension to a campaign" with a specific verb and resource. It distinguishes from sibling tools like google_ads_add_callout_extension by focusing on structured snippets.
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 an example and lists common headers, offering implicit usage context. However, it does not explicitly state when to use this over alternative extensions or provide contraindications, so guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the purpose but does not disclose whether the operation is read-only, requires specific permissions, or has 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, args, returns. It is front-loaded. However, the Args section repeats parameter names already in the schema, but since schema has no descriptions, this is acceptable.
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 description provides the basic purpose and parameters, but lacks guidance on output structure (despite having an output schema, the description only says 'Approval status details'), and no usage context. Adequate but incomplete.
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 description lists all three parameters with brief explanations, including the important note that customer_id should be 'without hyphens'. This adds value beyond the input schema which has no descriptions.
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 'Check ad approval and policy status' which is a specific verb-resource combination. It distinguishes from sibling tools like 'get_ad_details' which likely return broader ad information.
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 guidance on when to use this tool versus alternatives (e.g., get_ad_details, list_ads). The description does not mention prerequisites or context for use.
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 a read operation ('Get performance') without detailing pagination, error handling, or data availability. The return type is vaguely described as 'Performance breakdown by device'.
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 brief and to the point, using a standard docstring format with an example. Every sentence adds value, and the structure is clear. Slightly verbose due to the example but acceptable.
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 there is an output schema (not shown), return value details are not required. The description covers the basic purpose and parameters adequately for a tool with 3 parameters and 0% schema coverage. It could be improved with more detail on date_range options.
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 0%, so the description adds meaning beyond the schema. It explains customer_id format, optional campaign_id, and default date_range with an example. However, it does not enumerate valid date_range values or clarify the nature of campaign_id.
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 'Get performance by device type (mobile, desktop, tablet)', which is a specific verb+resource combination. It distinguishes itself from sibling tools like google_ads_campaign_performance or google_ads_account_performance by focusing on device breakdown.
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 an example and indicates optional campaign_id filtering, implying usage when device-level breakdown is needed. However, it does not explicitly state when to use this tool over other performance tools or mention any prerequisites or limitations.
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 provided, so description carries full burden. It only states 'list all ads' without disclosing pagination, ad status filtering, or permission requirements. Lacks details on behavior beyond the basic function.
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?
Very short and to the point with a clear structure (description, args, returns). Efficiently conveys the essential information, though it could benefit from slightly more detail without becoming verbose.
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 (2 parameters, output schema exists), the description is adequate but missing important details like whether the list is paginated or if it includes all statuses. Output schema may cover returns, but usage context like pagination is not addressed.
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?
Adds meaning beyond schema by specifying that customer_id should be provided 'without hyphens'. This is a useful constraint not present in the schema's title alone. Schema description coverage is 0%, so this additional context is valuable.
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?
Description clearly states it lists all ads in an ad group, using a specific verb and resource. It distinguishes itself from sibling tools like google_ads_get_ad_details (specific ad) and google_ads_create_ads (creation).
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. It does not mention when not to use it or compare with sibling tools like google_ads_get_ad_performance or google_ads_check_ad_approval_status.
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 behavioral traits. It states that the tool lists adjustments and returns markdown, but it does not explicitly confirm idempotency, read-only nature, rate limits, or any side effects. The read-only implication is weak.
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 well-structured with clear sections (Args, Returns, Example) and is relatively concise. The example is helpful but slightly verbose for a two-parameter tool. Overall, it is easy to scan and understand.
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 two simple parameters and an output schema that exists (but is not shown), the description explains the arguments adequately. However, the return value description ('All bid adjustments in markdown format') is vague and does not detail the fields or structure. Coverage is adequate but not 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 two required parameters with only titles and types. The description adds basic semantic info: 'Customer ID (without hyphens)' and 'Campaign ID'. This clarifies format for customer_id but does not explain length constraints or validation rules. Schema coverage is 0%, and the description provides partial compensation.
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 ('List') and identifies the resource ('bid adjustments') and the scope ('for a campaign'). It enumerates the types of adjustments covered (devices, locations, demographics, ad schedule), which clearly distinguishes it from sibling tools like setter functions.
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 reading bid adjustments (vs. setting them) through the verb 'List', but it does not explicitly state when to use this tool over alternatives. No exclusions or when-not-to-use guidance is provided.
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 provided, so description must cover behaviors. It does not state if it's a partial or full update, effects of omitting optional fields, or error conditions (e.g., invalid status). Only says 'Update ad group settings'.
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?
Well-organized with Args and Returns sections. Information is clear but slightly repetitive of schema. Could be more concise by omitting obvious parameter details.
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?
Covers all parameters and return type. Lacks information on partial update behavior, validation, or side effects. Output schema exists but description adds minimal value beyond 'Success message with updated fields'.
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?
Schema has 0% description coverage; the description adds meaning for all 5 parameters, including format hints (customer_id without hyphens) and optionality. It clarifies purpose of each parameter beyond the schema's titles.
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 'Update ad group settings' with specific parameters. It distinguishes from sibling tools like 'update_ad_group_bid' and 'update_ad_group_status' by covering multiple fields.
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 other update variants (e.g., batch status change, bid update). Does not mention prerequisites or restrictions.
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 burden but only states 'Update ad status' without disclosing effects, permanence, permissions, or side effects of the status change.
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 concise with a clear summary and bulleted arguments. The return value 'Success message' is vague but acceptable for a simple update.
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 presence of an output schema (not shown), the description is adequate for a simple mutation tool but lacks details on error handling, id formats beyond customer_id, and prerequisites.
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?
Despite 0% schema coverage, the description explains customer_id format (without hyphens) and valid status values (ENABLED, PAUSED, REMOVED), adding meaning beyond the schema's titles.
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 'Update ad status (enable, pause, or remove)' which specifies the verb and resource. It distinguishes itself from sibling tools like google_ads_bulk_update_ad_status by being a single ad update.
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 vs alternatives such as bulk update or other ad modification tools. Does not mention 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?
No annotations provided. The description does not disclose side effects, permissions needed, or whether optional fields update incrementally or require full specification. The return value description is minimal ('Success message with updated fields').
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 concise with a clear one-line purpose followed by a structured argument list. It avoids unnecessary prose, fitting the 6-parameter tool well.
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?
Covers all parameters and return type but lacks examples, error handling, or behavior on omitted fields. Given an output schema exists but is unused, the description is adequate but not comprehensive.
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?
Schema coverage is 0%, so the description fully carries parameter meaning. It lists all 6 parameters with explanations, including format hints (e.g., 'YYY-MM-DD'), allowed status values, and optionality. However, it does not explicitly mark customer_id and campaign_id as required, which the schema shows.
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 'Update campaign settings' with a specific verb and resource. Among siblings like google_ads_update_campaign_status_v2, this tool covers multiple settings (name, status, dates), distinguishing it from more specific update 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 explicit guidance on when to use this tool vs alternatives such as google_ads_update_campaign_status_v2 or google_ads_update_campaign_budget_v2. The description does not mention context or prerequisites.
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?
The description only states 'Update campaign status' implying mutation, but fails to disclose side effects, permission requirements, or immediacy of changes. No annotations exist to compensate, leaving the agent unaware of behavioral traits.
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 very concise, using a docstring-like format with clear sections. The purpose is front-loaded. Minor redundancy from the 'Args' and 'Returns' lines, but overall efficient.
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 output schema exists, return details are not needed. However, the description lacks context on prerequisites (e.g., campaign must be active), the effect of REMOVED status, and any irreversible actions. With many siblings, more completeness would aid selection.
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?
Despite 0% schema coverage, the description adds meaning by explaining each parameter: customer_id (no hyphens), campaign_id, and allowed status values. However, it omits format details like case sensitivity for status.
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 'Update campaign status (enable, pause, or remove)', specifying the verb, resource, and allowed statuses. This differentiates from sibling tools like bulk_status_change or update_campaign that handle broader updates.
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. With many sibling tools for campaign updates and status changes, the description lacks context for appropriate 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 exist, so description carries full burden. It says 'Enable' implying a state change, but fails to disclose consequences (e.g., campaigns become active, what if already enabled), permissions, idempotency, or effects on serving.
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?
Description is concise with clear sections (Args, Returns, Example). Every sentence adds value, and the example demonstrates usage. No filler or redundancy.
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?
Has output schema (not shown) which reduces burden. Includes parameter constraints and example. However, lacks behavioral details and usage guidelines. Adequate but missing context for an agent to fully understand side effects.
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?
Schema coverage is 0%, but description adds meaningful constraints: customer_id '10 digits, no hyphens' and campaign_ids 'comma-separated list'. This goes beyond the schema's title and type, aiding correct invocation.
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?
Description clearly states 'Enable multiple campaigns in a single batch operation,' specifying the verb (enable), resource (campaigns), and batch nature. This distinguishes it from sibling tools like google_ads_batch_pause_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?
No explicit when-to-use or when-not-to-use guidance. The provided example shows usage, but there is no mention of prerequisites, conditions, or alternatives. Missing context on when to prefer this over other batch status change 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?
No annotations are provided, so the description carries full burden. It mentions the action is mutation (dismiss) and returns a success message with count. However, it does not disclose potential side effects, idempotency, rate limits, or whether dismiss is reversible. The example partially compensates.
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 uses a clear docstring format with Args, Returns, and Example sections. It is well-structured and not overly verbose. However, the Args section largely duplicates the schema, and some sentences could be merged.
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?
Given the tool's simplicity (2 required params, no enums, output schema exists), the description provides a clear use case with an actionable example. It covers the essential information for an agent to invoke the tool correctly, though it lacks usage guidelines and deeper behavioral details.
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 0%, so the description must compensate. It provides format guidance for customer_id and recommendation_resource_names with examples, but does not explain the semantics beyond the names. The example clarifies usage, but full parameter meaning is still implicit.
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 'Dismiss multiple recommendations at once,' which is a specific verb+resource combination. It clearly distinguishes from siblings like google_ads_dismiss_recommendation (single) and google_ads_apply_recommendation (different action).
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 does not provide guidance on when to use this tool versus alternatives like google_ads_dismiss_recommendation (single) or google_ads_apply_recommendation. It only implies bulk dismissal but lacks context on prerequisites or conditions.
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 provided, so description must disclose behavior. It only states the action and return value, without mentioning idempotency, limits, or side effects. Minimal behavioral disclosure.
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?
Extremely concise: one line for purpose, followed by parameter definitions and return note. Front-loaded, no wasted words.
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?
With output schema present, return details are covered. However, lacks usage context and behavioral notes. Adequate for a simple update but could be more complete.
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?
Adds meaning beyond schema: customer_id format (no hyphens), daily_budget units (currency units, example). Schema coverage is 0%, so description compensates well.
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 specifies 'Update campaign daily budget', which clearly identifies the action and resource. It distinguishes from siblings like batch updates or campaign-level updates, as it focuses solely on budget.
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 vs alternatives like google_ads_batch_update_budgets or google_ads_update_campaign. The description lacks context for appropriate 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, the description carries the full burden. It only states the update action and return type, but does not disclose whether changes are immediate, require specific permissions, or have 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line summary, then a clear Args block with each parameter explained in one line, plus a Returns line. Every sentence has value with no 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?
Given the tool's simplicity and the presence of an output schema, the description covers the essential parameters and return. However, it lacks behavioral context and usage guidance, making it only minimally complete for the overall task.
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?
Despite 0% schema coverage, the description adds meaningful detail for all four parameters: customer_id (no hyphens), cpc_bid (currency units with example). This clarifies usage beyond the schema's type-only definitions.
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 states 'Update keyword CPC bid' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like google_ads_batch_update_bids or google_ads_update_ad_group_bid that update bids at a different 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?
The description provides no guidance on when to use this tool versus alternatives such as batch updates or other bid-related tools. There is no mention of prerequisites, context, or exclusions.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool adds keywords and returns a success message with a count, but does not detail side effects like duplicate handling, overwrite behavior, or permission requirements. Transparency is adequate but not thorough.
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 front-loaded with the main purpose and includes structured arg descriptions and an example. It is reasonably concise, though the example could be trimmed. Each sentence adds value without 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?
Given the tool's moderate complexity and presence of an output schema (not shown), the description covers the inputs well and indicates the return type. It lacks details on error handling or batch size limits, but is largely complete for the intended functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description significantly enhances the input schema by specifying format details (customer_id without hyphens), required fields for keyword objects (text and match_type), and allowed values for match_type (EXACT, PHRASE, BROAD). It also clarifies the cpc_bid as optional and in currency units. With 0% schema description coverage, the description fully compensates.
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 'Add keywords to an ad group' with a specific verb and resource. It provides an example with keyword match types, making the action unambiguous. However, it does not differentiate from siblings like google_ads_batch_add_keywords or google_ads_bulk_add_keywords, so the purpose is clear but not fully distinguished from similar 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 such as batch or bulk versions. It does not mention prerequisites, limitations, or context for use, leaving the agent to infer appropriate 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 fully disclose behavioral traits. It identifies the action as adding negative keywords (a mutation) but does not mention any side effects, limits (e.g., maximum keywords per call), overwriting behavior, or required permissions.
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 concise and includes a useful example, though it uses a docstring format with 'Args' and 'Returns' which adds some verbosity. Every part serves a purpose, making it efficient.
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 presence of an output schema (true in context), the description does not need to detail return values. However, it lacks information on error handling, rate limits, or prerequisites. For a simple tool, it is adequate but could be more complete given the large number of sibling tools.
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 description adds significant meaning beyond the input schema by specifying that the 'keywords' parameter should be a list of dicts with 'text' and 'match_type' keys, and provides an example. The schema only defines an array of objects with additional properties, lacking structure.
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 negative keywords') and the resource ('to an ad group'). It distinguishes itself from siblings like 'google_ads_add_keywords' (adds positive keywords) and 'google_ads_add_shared_negative_keywords' (adds to shared library).
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 adding negative keywords but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or contrast with sibling tools like 'google_ads_add_keywords' or 'google_ads_add_shared_negative_keywords'.
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. It lists allowed status values but omits critical details like authorization requirements, rate limits, partial failure handling (e.g., rollback behavior), and whether the operation is atomic.
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 concise with clear sections (Args, Returns, Example). Every sentence serves a purpose, though the structure could be slightly improved with bullet points for readability.
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 presence of an output schema and three parameters, the description is mostly complete for basic usage. However, it lacks details on error handling, validation, and post-conditions, making it less than fully comprehensive.
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?
Schema coverage is 0%, so the description adds significant value. It clarifies customer_id format (no hyphens), describes status_updates as a list of dicts with specific keys, and enumerates allowed status values. The example further clarifies usage.
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 'Update status for multiple ads at once,' specifying the verb 'update' and the resource 'status for multiple ads.' It distinguishes from siblings like 'google_ads_update_ad_status' (single ad) and 'google_ads_bulk_update_ad_group_status' (ad group status).
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 use for multiple ads but lacks explicit guidance on when to use this tool vs alternatives. No when-not-to-use or alternative tool names are mentioned, relying on the tool name alone for differentiation.
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?
The description discloses the write operation and return of a success message with conversion action ID and tag snippet, but does not mention permissions, rate limits, or idempotency. With no annotations, this is moderately transparent.
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 structured with Args, Returns, and Example sections, making it easy to parse. Though lengthy due to 9 parameters, it is appropriate and not unnecessarily verbose.
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?
Given the complexity and presence of an output schema, the description covers all inputs and return value adequately. It lacks error handling or prerequisite details but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates fully by explaining every parameter in detail, including constraints (e.g., 'without hyphens' for customer_id, lookback windows) and examples. This adds significant meaning 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 function 'Create a conversion action for tracking' and lists all parameters. It implicitly distinguishes from siblings like update and list by using 'create', but lacks explicit 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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when to use vs update or other creation tools, relying 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.
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 behavioral traits. It only states the tool returns 'complete strategy configuration and settings' but fails to mention that it is a read-only operation, any required permissions, or potential side effects. The description lacks sufficient 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 compact and well-structured with a clear header sentence, followed by Args, Returns, and Example. Every sentence serves a purpose, and the key information is 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?
With an output schema present, the description does not need to detail return values. However, given the tool's complexity (retrieving full configuration details), the description is minimal. It could mention the scope of configuration details (e.g., name, type, settings) to improve completeness. Nonetheless, it is adequate for a simple retrieval tool.
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 0%, meaning the description must compensate. It lists the two parameters in the Args section but adds no additional meaning beyond what the schema already provides (names and types). The description does not explain the format of customer_id (without hyphens is stated) or what a bidding_strategy_id looks like, but the example provides a hint.
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 'Get' and the resource 'portfolio bidding strategy', specifying 'full configuration details'. This distinguishes it from sibling tools like get_bidding_strategy_performance (performance data) and list_bidding_strategies (listing strategies).
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 provides clear context with Args, Returns, and an Example, specifying the required parameters (customer_id, bidding_strategy_id). However, it does not explicitly state when to use this tool versus alternatives, nor does it mention 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.
Behavior3/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 describes a read-like operation (listing) without side effects, but does not disclose potential pagination, rate limits, or performance implications. The example adds some clarity but transparency is moderate.
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 relatively concise with separate sections for description, args, and example. The example is helpful. However, it could be slightly more compact without losing clarity.
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?
Despite explaining parameters and providing an example, the description does not specify what 'details' are returned, nor does it mention default behavior when list_type is null. Output schema exists but is not shown. There is no guidance on usage limits or prerequisites.
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?
Schema description coverage is 0%, so the description must add value. It explains customer_id format ('without hyphens') and provides explicit filter values (CRMBASED, RULE_BASED, SIMILAR, LOGICAL) that are missing from the schema. This compensates well for low 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 clearly states the tool lists all user lists (audiences) in the account. It uses a specific verb and resource, distinguishing it from siblings like 'google_ads_create_user_list' or 'google_ads_get_user_list_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 on when to use this tool versus alternatives like 'google_ads_search_google_audiences'. It does not mention exclusions or prerequisites. The description only states what it does, not when 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?
No annotations are present, so the description must fully cover behavioral traits. It only states 'Set ad scheduling' without indicating whether existing schedules are overwritten or merged, what permissions are needed, or any side effects. The return value is mentioned but lacks depth.
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 well-structured with a clear one-liner, formal args documentation, return value, and example. Every sentence serves a purpose, and the length is appropriate for the complexity of the schedules parameter.
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 description covers purpose, parameters, example, and return. However, it lacks details on overwrite behavior, constraints (e.g., max schedules), and differentiation from a sibling tool. Given the output schema exists, the return description is sufficient, but behavioral gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description comprehensively documents all three parameters. It specifies customer_id format, campaign_id usage, and the detailed structure of schedules (day_of_week options, hour/minute ranges, optional bid modifier). This adds significant meaning 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 states 'Set ad scheduling (dayparting) for a campaign,' with a specific verb and resource. The title and description align, and the tool's role is well-defined among siblings (e.g., google_ads_set_ad_schedule_bid_adjustments is different).
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 guidelines are provided. The description does not specify when to use this tool versus alternatives like google_ads_set_ad_schedule_bid_adjustments, nor does it mention prerequisites, context, 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?
No annotations provided. Description only states it adds audience targeting and lists targeting_mode. Does not disclose behavior on existing audiences, error conditions, or consequences. Lack of detail 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?
Very concise with clear structure: purpose sentence, similarity note, bullet-point args, return statement, and example. No redundant information.
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?
With 4 parameters and output schema (not shown), description covers core operation and parameter meanings but lacks error handling, duplicate behavior, and detailed return value beyond 'Success message'. Adequate but incomplete.
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?
Schema coverage is 0%, description compensates with brief explanations for all 4 parameters, includes format note for customer_id, and enumerates targeting_mode values. Could clarify default behavior and mode semantics.
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?
Description explicitly states 'Add audience targeting to an ad group.' as a verb+resource pair and distinguishes from sibling 'google_ads_add_audience_to_campaign' by noting it is applied at ad group level for granular control.
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?
Mentions similarity to campaign-level tool, implying ad group scenario, but no explicit when-not or alternatives for audience targeting tools like set_audience_exclusions. Guidance is present but limited.
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 behaviors. It only states the action ('add') without mentioning idempotency, error conditions, permissions, or side effects (e.g., whether existing promotions are overridden).
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?
Well-structured with a one-line summary, purpose paragraph, parameter list, returns line, and an example. Every sentence is informative, no fluff. The example is particularly helpful.
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?
Covers purpose, parameters, and returns (via example). Lacks behavioral details but includes an output schema (signal true). For a tool with 8 parameters, it is fairly complete, though usage guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for each parameter (e.g., customer_id format, occasion enum values, discount_modifier options). This fully compensates for the schema gap, adding significant meaning.
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 adds a promotion extension to a campaign, specifying the action and resource. It distinguishes from siblings by naming the specific extension type 'promotion extension' and explains its purpose (highlighting special offers).
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 guidance on when to use this vs. other extension tools like add_call_extension or add_callout_extension. The description implies it's for promotions but does not specify conditions or alternatives, leaving the agent to infer.
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. It identifies the operation as a bulk set (mutation) and returns a success message with count, but lacks details on idempotency, partial failures, rate limits, error handling, or whether suffixes are overwritten or appended. For a mutation tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences for purpose, then structured Args and Returns. No extraneous words. It is front-loaded with the primary purpose, making efficient use of space.
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 no annotations and no output schema, the description covers the essential calling convention and return a message with count. However, it omits details on error handling, partial success, validation, and other important behavioral aspects for a bulk mutation tool. It is adequate but incomplete for production use.
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?
Schema description coverage is 0%, so the description compensates by explaining `customer_id` format ('without hyphens') and `ad_group_suffixes` as a JSON string with an array of objects, including a concrete example. This adds significant meaning beyond the schema, though additional constraints on URL suffix format are missing.
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: 'Bulk set Final URL suffixes for multiple ad groups in one API call.' It specifies the verb 'set', resource 'Final URL suffixes for ad groups', and the bulk nature. This distinguishes it from the sibling 'google_ads_set_ad_group_url_suffix' which handles single 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk updates by mentioning 'multiple ad groups in one API call' but does not explicitly state when to use this tool versus alternatives like the singular set tool. No when-not or exclusion criteria are provided.
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 mentions the return (success message with count) and allowed status values, but lacks details on atomicity, validation, error handling, rate limits, or authentication 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?
The description is concise, structured with Args, Returns, and Example sections, and contains no unnecessary information. Every sentence adds value.
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 presence of an output schema, the description covers the basic functionality, inputs, and outputs. However, it lacks details on error handling, partial success, and whether the operation is synchronous.
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?
Schema coverage is 0%, but the description compensates by explaining the format for customer_id, ad_group_ids as a list, and providing specific allowed values for status (ENABLED, PAUSED, REMOVED). The example further clarifies usage.
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 'Update status for multiple ad groups at once,' specifying the verb, resource, and bulk nature. This distinguishes it from sibling tools like google_ads_update_ad_group_status (singular) and google_ads_bulk_update_ad_status.
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 use for bulk updates via the word 'bulk' and 'multiple ad groups at once,' but it does not explicitly state when to use this tool vs alternatives (e.g., singular update tools) or provide prerequisites or exclusions.
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?
No annotations provided, so the description carries full burden. It adds a useful safety note about ad groups being created PAUSED by default, but does not disclose authentication needs, rate limits, or exact 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 concise and front-loaded with the purpose. The Args block is clear but slightly informal; no wasted words, though it could be more 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?
Covers key parameters and the safety default, but lacks mention of prerequisites (e.g., existing campaign) or how to interpret the return value beyond 'Success message with ad group details'. Given the tool's complexity and lack of annotations, some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context for all 6 parameters: explains customer_id format, cpc_bid units with example, status options and default, and ad_group_type examples. This compensates fully for the schema gaps.
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 'Create a new ad group within a campaign,' specifying the verb (Create) and resource (ad group) and distinguishing it from update or batch creation 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?
No guidance on when to use this tool versus alternatives like google_ads_batch_create_ad_groups or update_ad_group. The description does not mention any prerequisites or exclusions.
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 must fully disclose behavior. It mentions Google's recommendation engine and possible recommendation types, but omits details like permissions, rate limits, or side effects (though read-only is implicit). The transparency is adequate but not thorough.
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 concise and well-structured, with a brief intro, bullet points of recommendation types, and clear sections for args, returns, and an example. No redundant information, though the returns section is minimal.
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?
Given the tool has an output schema and only two parameters, the description covers the core functionality adequately. However, it lacks usage guidance and does not explain how it fits into workflows with sibling tools, which would enhance 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 0%, so the description must compensate. It explains customer_id format (no hyphens) and that campaign_id is optional, but does not elaborate on how campaign_id filters recommendations or provide examples of valid values beyond the basic example.
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 it retrieves AI-powered bid recommendations from Google Ads, listing specific types like keyword bid adjustments and campaign budget increases. This distinguishes it from sibling recommendation tools like get_recommendations, which are broader in scope.
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 getting bid recommendations but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_recommendations, apply_recommendation). No when-not or prerequisite conditions are provided.
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?
Given no annotations, the description carries the burden. It states the tool projects impressions, clicks, cost, and conversions using historical data, and notes the 7-day requirement. It does not disclose read-only nature, rate limits, or permissions.
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 well-structured with a purpose paragraph, Args/Returns/Example sections, and no extraneous text. Every sentence adds necessary information.
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?
Considering the output schema exists, the description adequately covers purpose, parameters, and usage context. It lacks some behavioral details but is sufficient for a complex tool.
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?
With 0% schema description coverage, the description adds significant value by explaining each parameter: customer_id (no hyphens), campaign_id (campaign-level), criterion_id (optional keyword-level). This clarifies usage beyond the schema's minimal titles.
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 bid simulation data showing potential performance at different bid levels. It distinguishes from siblings like google_ads_get_bid_recommendations by focusing on historical projections, but does not explicitly mention alternatives.
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 explains that bid simulators use historical data and require at least 7 days of data, implying when to use. However, it does not provide explicit when-not-to-use or compare with other tools like keyword forecast.
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?
No annotations are provided, so the description must cover behavioral traits. It states it uses historical data and returns confidence ranges, which is informative. However, it does not disclose data requirements, freshness, or whether the tool modifies data (likely read-only). It adds some context but lacks 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 well-structured with a clear opening, bullet points for forecast metrics, parameter descriptions, and an example. It is reasonably concise, though the list of forecast metrics could be integrated into the main sentence. Overall, it earns its length.
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?
Given the tool has 3 parameters, no annotations, and an output schema exists (assumed from context signals), the description covers purpose, parameters, and usage example. It could mention assumptions or data requirements, but it is sufficiently complete for a forecast tool.
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?
Schema description coverage is 0%, so the description must compensate. It does so effectively by specifying '10 digits, no hyphens' for customer_id, 'Campaign ID to forecast' for campaign_id, and '7-90' for forecast_days. This adds meaningful constraints and usage details beyond the schema's type/default.
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 it predicts future campaign performance based on historical trends, listing specific metrics (spend, conversions, ROAS, confidence intervals). This distinguishes it from siblings like google_ads_campaign_performance (current/historical) and google_ads_keyword_forecast (keyword-level). The verb 'predict' and resource 'campaign performance' are specific.
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 does not provide any guidance on when to use this tool versus alternatives. Siblings like google_ads_keyword_forecast and google_ads_campaign_performance exist, but no distinction is made. No prerequisites or context for use are mentioned.
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. It discloses the basic behavior (adds exclusions, returns success message) and mentions CIDR support for IP ranges. However, it does not address whether exclusions are additive or replacing, permission requirements, rate limits, or error handling.
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 well-structured with Args, Returns, Note sections. It is relatively concise, though the examples add length. Every sentence adds value; no redundancy.
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 complexity and lack of annotations, the description should cover more: whether exclusions are added incrementally or replace existing, duplicate handling, limits, and full return structure. Output schema exists but its content is unknown, so description must do more. It is adequate but not complete.
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?
Schema coverage is 0% (no descriptions in schema). The description adds significant meaning: it explains placement_exclusions as 'List of URLs/apps to exclude' with examples, and ip_exclusions similarly with CIDR note. Customer_id gets a 'without hyphens' hint, but campaign_id lacks detail. Overall, it compensates well for missing schema descriptions.
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 adds placement and IP exclusions to a campaign. It distinguishes from sibling tools like add_negative_keywords and set_audience_exclusions by focusing on placement and IP exclusions.
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 explains what exclusions do but does not explicitly state when to use this tool over alternatives (e.g., negative keywords, audience exclusions). Usage context is implied but no direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the action is an assignment that replaces the current strategy, but lacks details on side effects, permissions, reversibility, or error conditions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a clear first sentence, followed by an args list and example. Every sentence adds value without 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?
Given the simple 3-parameter signature and no annotations, the description covers purpose, inputs, and output (success message). It is largely complete for an agent to select and invoke correctly, though it could include prerequisites.
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 0% description coverage, but the tool description lists each parameter with a short explanation (e.g., 'customer_id: Customer ID (without hyphens)'). This adds basic meaning, but does not provide constraints or where to obtain IDs.
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 assigns a portfolio bidding strategy to a campaign. The verb 'assign' and the specific resource 'portfolio bidding strategy' make it distinct from siblings like 'create_bidding_strategy' or 'update_bidding_strategy'.
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 explains that it replaces the current bidding strategy and mentions Google AI optimization across campaigns. While it does not explicitly list alternatives or when not to use, the context is clear enough for an agent to understand its use case.
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 transparency burden. It discloses that it performs a batch operation and returns success/failure details, but does not mention permissions, mutability, partial failures, or side effects. It adequately describes the required input schema but lacks behavioral detail.
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 well-structured with sections for Args, Schema, Required Fields, Returns, and Example. It is concise but includes a necessary code block. Every sentence is informative, though the code block could be slightly trimmed. It is front-loaded with the main purpose.
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?
Given the 2 parameters and a custom JSON input, the description provides adequate completeness for input structure. It explains the return only generically, but an output schema exists (not detailed). It does not compare to sibling tools, but the name and description sufficiently differentiate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only names and types (0% coverage), so the description adds crucial semantic information: customer_id format (10 digits, no hyphens), budget_updates_json inner schema with required fields (campaign_id, budget_amount), and daily budget unit. An example is provided, making parameter usage clear.
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 (Update), resource (budgets for multiple campaigns), and scope (single batch operation). It distinguishes from siblings like update_campaign_budget_v2 by emphasizing the batch 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?
The description lacks explicit guidance on when to use this tool vs alternatives. It does not mention that for single campaign budget updates, one should use update_campaign_budget_v2, nor does it provide context on 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?
No annotations provided, so description carries full burden. Only states that dismissal removes from list; lacks disclosure of irreversibility, permissions, or effects beyond removal. For a write operation, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with no filler. Header, usage sentence, then Args/Returns/Example. Information is front-loaded and well-structured.
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?
Tool is simple; description covers purpose, usage, and return. Lacks mention of bulk alternative or whether dismissal is reversible, but given the tool's narrow scope, it is largely 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?
Schema has 0% description coverage; description adds 'without hyphens' for customer_id and clarifies recommendation_resource_name as resource name. Example provides format. Adds value but could detail naming conventions or constraints.
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?
Description clearly states the action (dismiss) and resource (recommendation), and distinguishes from applying recommendations, which is a sibling tool. The 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you don't want to apply a recommendation and want to remove it'. Provides clear context but does not mention bulk alternative (google_ads_bulk_dismiss_recommendations) present among 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 must fully convey behavioral traits. It fails to mention data freshness, pagination, rate limits, or any side effects. While 'Get' implies a read operation, the description lacks sufficient transparency for safe invocation.
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: two sentences for purpose/benefit, then structured Args, Returns, and Example sections. No redundancy, and the most critical information is front-loaded.
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?
Given that an output schema exists, the description is appropriately complete for a reporting tool. It covers all parameters adequately. However, it could mention the general structure of the returned report (e.g., columns like clicks, impressions) to enhance usability, though the output schema may provide this.
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?
Schema description coverage is 0%, but the description's Args section adds significant meaning: customer_id format (10 digits, no hyphens), campaign_id as optional filter, and date_range with explicit allowed values (LAST_7_DAYS, LAST_30_DAYS, LAST_90_DAYS). This compensates well for the schema's lack of descriptions.
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 'Get' and the resource 'performance metrics for ad extensions', distinguishing it from sibling performance reports like account or campaign performance. The additional line about showing which extensions are performing well clarifies the tool's value.
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 analyzing extension performance but does not explicitly state when to use it over alternatives, such as other performance reports or extension management tools. No exclusions or prerequisites are mentioned.
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. The description only says 'Get detailed information' without disclosing behavioral traits such as required permissions, rate limits, or whether the user list must exist. It adds minimal context beyond the obvious read 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 very concise: a clear single-line purpose, then structured args/returns/example. Every sentence adds value, and the key information is front-loaded.
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?
Given the tool's simplicity (2 params, no nested objects, output schema exists), the description adequately explains parameters and gives an example. It does not detail the return structure, but the output schema compensates. Slight improvement would be mentioning the return content briefly.
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 schema has 0% description coverage, but the description adds meaning by specifying 'Customer ID (without hyphens)' and 'User list ID', and provides an example. This clarifies the expected format beyond the schema's type-only definitions.
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 'Get detailed information about a specific user list.' It uses a specific verb ('Get') and resource ('user list details'), and distinguishes from siblings like google_ads_list_user_lists (list all) and google_ads_create_user_list (create).
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?
No explicit guidance on when to use this tool versus alternatives like google_ads_list_user_lists. The implied usage is for retrieving details of a single user list given an ID, but the description does not explicitly state when to prefer this over listing or other actions.
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?
No annotations are provided, so the description must carry the full behavioral burden. It explains inputs, expected return (success/failure details), and provides examples, but it does not disclose potential side effects like overwrites, duplicate handling, or authorization requirements.
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 well-structured with sections for args, CSV formats, return, and example. While it is somewhat lengthy, each section provides necessary information without redundancy. Slight improvement could be made by front-loading the purpose more.
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?
Given the tool's complexity and lack of annotations, the description is mostly complete. It covers parameter details, format specifications, and return value. However, missing behavioral context (e.g., idempotency, risk of overwriting) and no mention of output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description significantly compensates for the 0% schema description coverage by detailing each parameter: customer_id format (10 digits, no hyphens), entity_type values (campaigns, keywords), and csv_data as CSV formatted data with explicit examples for both campaigns and keywords.
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 'Import entities from CSV format' with a verb and resource. It specifies entity types (campaigns, keywords) but does not explicitly differentiate from related siblings like google_ads_add_keywords or google_ads_batch_add_keywords.
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 use for CSV imports but does not provide explicit guidance on when to use this tool versus alternatives such as batch or individual add tools. No exclusions or comparisons are 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?
No annotations are provided, so the description carries full burden. It only states it returns 'key metrics' without elaborating on behavior like pagination, rate limits, or data scope. Minimal behavioral context beyond the basic 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 extremely concise, with a single sentence for purpose and a structured Args/Returns section. No redundant text, front-loaded with the action.
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?
Given the simplicity of the tool and the existence of an output schema, the description is mostly complete. It covers purpose, filters, and return type. Minor gaps: does not explicitly state that customer_id is required (though implied) and omits pagination info.
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 description adds value beyond the input schema by specifying customer_id format ('without hyphens') and enumerating allowed status values ('ENABLED, PAUSED'). Schema coverage is 0% but the description itself provides meaningful parameter details.
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 'List ad groups with optional filters', specifying the verb (list) and resource (ad groups). It distinguishes from sibling tools like google_ads_list_ads and google_ads_list_keywords by focusing on 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists optional filters but does not explicitly guide when to use this tool versus alternatives like google_ads_get_ad_group_details for specific details or google_ads_list_ads for ads. Usage is implied but lacks exclusions or alternative suggestions.
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 full burden. It states the action and scope ('list all portfolio strategies') but does not disclose read-only nature, rate limits, pagination, or that it returns only basic info. This is minimal but adequate for a simple listing 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 concise with an Args/Returns/Example structure. It is front-loaded with the main action. Minor redundancy: the Returns line repeats info likely in the output schema.
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 an output schema, the description is largely sufficient. However, it lacks usage context (e.g., when to use vs get details) and does not mention any required prior setup or permissions.
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 description explains customer_id as 'Customer ID (without hyphens)', adding a formatting hint beyond the schema's title ('Customer Id'). Despite schema coverage of 0%, this single parameter is well-described.
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 lists all portfolio bidding strategies in the account, using a specific verb ('List') and resource ('portfolio bidding strategies'). It differentiates from sibling tools like create or get_bidding_strategy_details.
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 listing all strategies but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like get_bidding_strategy_details or prerequisites such as account initialization.
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?
No annotations are provided, so the description must cover behavioral traits. It mentions common language IDs but does not disclose whether setting languages replaces or merges with existing ones, or if any permissions are required. This is partial 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 extremely concise—8 lines total. The first sentence states the purpose, followed by parameter definitions, return info, and a helpful note. Every sentence contributes useful information without 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?
The output schema exists, so the vague return description is acceptable. The description covers the core use case and provides a handy reference for language IDs. However, it omits details about error conditions or whether the operation is additive or replacement.
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?
With 0% schema coverage, the description adds value by clarifying that customer_id should be 'without hyphens' and listing common language codes. However, campaign_id lacks explanation, and language_codes format is only implied by examples.
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 sets language targeting for a campaign. The verb 'set' combined with the resource 'language targeting' leaves no ambiguity about the function. It is distinct from sibling tools like set_campaign_locations or set_campaign_schedule.
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 (e.g., when to use set_campaign_languages vs. adding languages via other methods). There is no mention of prerequisites, conflicts, or best practices for language targeting.
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 indicates a write operation ('Set') but does not explain whether it overwrites or appends locations, if changes are reversible, or what the exact response contains beyond 'Success message'. This leaves ambiguity 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Note), concise sentences, and no redundant information. It is front-loaded with the purpose and efficiently conveys all necessary details.
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 moderate complexity, the description covers core functionality and parameter details but lacks behavioral context (e.g., idempotency, permission requirements) and detailed return value specification. The output schema is mentioned but not explained, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value over the input schema by explaining each parameter's purpose, including formatting hints ('without hyphens'), the optional nature of 'negative_location_ids', and providing a helpful note with common location IDs. Schema coverage is 0% in context signals, so the description fully compensates.
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 'Set location targeting for a campaign' with specific verb and resource. It distinguishes from sibling tools like 'google_ads_set_campaign_languages' and 'google_ads_set_campaign_schedule' by focusing on locations.
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 when setting campaign locations but does not explicitly state when to use this tool versus alternatives like 'google_ads_get_campaign_details' or other setup tools. No exclusions or alternative recommendations are provided.
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?
No annotations are present, so the description must carry the burden. It mentions it analyzes and provides daily data, but does not disclose whether it is read-only, affects any state, or has any side effects. Given the lack of annotations, the description provides some behavioral context but is incomplete.
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 well-structured with bullet points, an Args section, Returns, and an Example. It is concise and front-loads the main purpose. Every sentence adds value, though the Returns section could be slightly more detailed.
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 output schema exists, but the description only vaguely mentions 'Trend analysis with anomaly detection'. More detail on output structure would improve completeness. Additionally, with no annotations, the description should cover behavioral traits more thoroughly. Overall adequate but with gaps.
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?
Schema coverage is 0%, so the description compensates well by providing clear, meaningful descriptions for each parameter: customer_id format, campaign_id's default scope, and lookback_days range. This adds significant value beyond the schema's bare types and defaults.
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 analyzes performance trends and detects anomalies, listing specific outputs like cost trends, conversion trends, and anomalous days. This distinguishes it from other google_ads_* performance tools that focus on static summaries or comparisons.
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 trend analysis but does not explicitly state when to use this tool versus alternatives like google_ads_performance_insights or google_ads_wasted_spend_analysis. No exclusion criteria or context is provided.
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 should fully disclose behavior. It explains the operation and some parameter constraints (e.g., items count 3-8, qualifier values) but does not mention whether the operation is destructive, reversible, or what the return result contains beyond a vague statement. Key behavioral aspects 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 well-structured with sections for intro, args, schema, returns, and example. It is concise yet comprehensive, with no unnecessary words. Each section earns its place.
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?
Given the existence of an output schema, the description need not detail return values. It covers parameter constraints and provides an example. However, it could include more context about prerequisites (e.g., campaign must exist) and potential errors, though the output schema may cover some of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It provides detailed meaning for each parameter: customer_id format (10 digits, no hyphens), campaign_id, price_qualifier with enum values, and items_json with a JSON schema and count constraint (3-8 items). An example further clarifies usage.
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 adds a price extension to a campaign and explains what price extensions are, distinguishing it from sibling tools like add_call_extension or add_promotion_extension. The verb 'Add' and resource 'price extension' are specific.
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 does not explicitly state when to use this tool versus alternatives or when not to use it. The implied usage is clear (when adding a price extension), but no exclusions or comparisons are provided, leaving the agent to infer from sibling names.
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?
Annotations are absent, so the description must disclose behavior. It mentions potential increases in CTR and ad size but does not elaborate on the impact on existing sitelinks, whether the operation is destructive, or performance 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 well-structured with clear sections for args, schema, requirements, returns, and an example. It is informative but slightly long; could trim redundant phrasing while retaining clarity.
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?
Input parameter details are thorough, but the output is vaguely described as 'Sitelink extension creation result' despite the existence of an output schema. No annotations are provided to fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description significantly compensates by detailing parameter formats (e.g., customer_id: 10 digits, no hyphens), providing a JSON schema for sitelinks_json, and specifying character limits and an example.
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 'Add sitelink extensions to a campaign' and explains what sitelinks are, distinguishing it from other extension tools by naming 'sitelink' specifically.
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 requirements (link text length, minimum 2 sitelinks) but does not offer guidance on when to use this tool versus alternative extension tools like callout or price extensions.
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 adds context by explaining the JSON configuration structure and required/optional fields. However, it lacks details on idempotency, ordering, error handling, or batch limits that would help the agent anticipate behavior.
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?
Structured with clear sections (intro, args, schema, returns, example). Front-loaded with purpose. The code block is helpful but adds length; still efficient overall.
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?
Covers key aspects: how to call, parameter meanings, configuration structure, and example. Missing details like maximum batch size or error behavior, but adequate for a batch tool with output schema present.
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?
Schema coverage is 0%, but description compensates well: explains customer_id format, ad_groups_json as JSON array, and provides a detailed schema with required/optional fields and example. Could be more precise on data types (e.g., cpc_bid as number).
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?
Clearly states 'Create multiple ad groups in a single batch operation,' specifying the verb, resource, and batch nature. Distinguishes from sibling 'google_ads_create_ad_group' by emphasizing batch.
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?
Implies usage for creating multiple ad groups at once, but does not explicitly state when to use this vs. alternatives (e.g., 'google_ads_create_ad_group'). No when-not or exclusion guidance provided.
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 confirms the tool mutates statuses but does not mention permissions, immediacy of changes, rate limits, or potential side effects. The return value is only 'Batch operation result', lacking detail.
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 well-organized into sections (Args, Status Update Schema, Valid Statuses, Returns, Example) and is front-loaded with the purpose. Every sentence adds value, and the example is useful.
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?
Given the presence of an output schema (indicated in context signals), the description adequately covers input parameters, format, and valid values. It lacks error handling or edge case details, but is sufficient for a batch operation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing customer_id format, entity_type options, and the JSON structure for status_updates_json with two variants and valid statuses per entity. This adds significant meaning beyond the bare 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 states the tool's purpose: 'Change status for multiple entities (campaigns, ad groups, keywords, ads).' This is a specific verb+resource combination that distinguishes it from siblings like google_ads_batch_enable_campaigns or google_ads_batch_pause_campaigns by explicitly listing supported entity types.
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 valid statuses per entity type and shows JSON schemas for updates. However, it does not explicitly mention when to use this tool over more specialized siblings (e.g., google_ads_batch_enable_campaigns for campaign-only enablement), leaving the agent to infer.
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 behavioral burden. It uses 'Analyze' which suggests a read operation, but does not explicitly state that no changes are made or mention any side effects, rate limits, or permissions. Adequate but could be clearer.
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 well-structured with sections for summary, outputs, arguments, return, and example. It is concise but some bullet points could be integrated into prose for brevity.
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's complexity is moderate, and the description covers key outputs, parameter formats, and a usage example. The existence of an output schema helps, but the description still provides necessary context for initial understanding.
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?
Despite 0% schema description coverage, the description provides detailed parameter explanations (e.g., '10 digits, no hyphens' for customer_id) and an example call, adding significant value over 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 states 'Analyze budget pacing and spending velocity for a campaign' and lists specific outputs (current spend, pacing percentage, etc.), distinguishing it from siblings like budget_recommendations or performance_forecaster.
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 analyzing pacing but does not explicitly state when to use this tool vs alternatives like budget_recommendations or wasted_spend_analysis. No when-not-to-use or prerequisite info is provided.
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 states the tool 'generates' recommendations, implying a read-only analysis, but does not explicitly confirm that it does not modify any data. It also does not mention permissions, rate limits, 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 structured with bullet points and an Args/Returns/Example section, making it easy to scan. While it is slightly verbose, it efficiently conveys the tool's purpose, parameters, and return value. The main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 (2 parameters, one required) and the presence of an output schema (as indicated by context signals), the description is complete. It explains both parameters, describes the return value, and includes an example. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool's description provides detailed explanations for both parameters: customer_id format (10 digits, no hyphens) and allowed date_range values (LAST_7_DAYS, LAST_30_DAYS, LAST_90_DAYS). This fully compensates for the schema gap and adds value 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 states the tool's purpose: 'Generate AI-powered budget reallocation recommendations.' It then details the types of campaigns it identifies (budget-constrained, underperforming, high ROAS) and that it provides prioritized recommendations. This distinguishes it from sibling tools like google_ads_budget_pacing and google_ads_get_recommendations, which focus on different aspects of budget management.
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 analyzing campaigns to inform budget reallocation, but it does not explicitly state when to use it versus alternatives (e.g., google_ads_budget_pacing for pacing, google_ads_recommendations for broader recommendations). There is no guidance on 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?
No annotations provided, so the description carries full burden. It only says 'Update bids' and gives a success message, but does not disclose if the operation is atomic, error handling, permission requirements, or what happens if some updates fail.
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?
Three sentences plus structured Args/Returns/Example. The first sentence states the purpose. No unnecessary information. Efficient and well-organized.
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?
Covers purpose, parameters, return type, and provides an example. With 2 simple parameters and an output schema declared, the description is largely complete. Lacks error handling or usage context, but adequate for a straightforward update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains customer_id format (no hyphens) and bid_updates as a list of dicts with specific keys. The example further clarifies the parameter structure, fully compensating for the schema 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?
Description clearly states 'Update bids for multiple keywords at once', with a specific verb and resource. It distinguishes from the singular google_ads_update_keyword_bid tool via the word 'bulk' and multiple keywords.
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?
No explicit when-to-use or when-not-to-use guidance. The example and name imply a bulk operation, but alternatives like google_ads_batch_update_bids are not mentioned, leaving ambiguity for the agent.
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?
No annotations exist, so description carries full burden. It mentions parameter constraints and a return value but does not disclose permissions, side effects, or potential errors. The behavioral traits are partially covered.
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 well-structured with clear sections (Args:, Returns:, Example), uses code blocks, and is concise without redundant information.
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?
Given the parameter count (8) and required fields (5), the description covers most needs. It includes constraints and an example. However, it omits prerequisites (e.g., ad group must exist) and post-creation behavior beyond a success message.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides comprehensive semantics: character limits (headlines max 30, descriptions max 90, paths max 15), required counts (3-15 headlines, 2-4 descriptions), and default status. The example further clarifies usage.
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 explicitly states 'Create a Responsive Search Ad (RSA).' It uses a specific verb and resource, clearly distinguishing it from sibling tools that create other ad types or 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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. With many sibling tools, additional context on appropriate use cases would be helpful.
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?
No annotations are provided, so description carries full burden. It notes the new campaign is created in PAUSED status, which is helpful. However, it does not detail what 'all settings' includes or potential side effects like budget duplication.
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?
Description is concise with no fluff: short sentences, structured with Args, Returns, Note. Every sentence adds value.
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?
Given complexity of a duplication tool with 4 params and output schema present, the description covers key points: parameter details, return value, and safety note. Minor omission: no mention of prerequisites (e.g., campaign must exist) but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. Each parameter is explained: customer_id format, campaign_id purpose, new_name purpose, and include_ad_groups with default value. This adds significant meaning 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 states 'Duplicate an existing campaign with all settings', using a specific verb and resource. It distinguishes from sibling tools like create_campaign or update_campaign by implying copying an existing one.
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 guidance on when to use this tool vs alternatives like create_campaign or batch_create_campaigns. It lacks context for when-not to use or which scenarios are appropriate.
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?
No annotations are provided, so the description bears full responsibility. It discloses that the tool returns Global Site Tag and Event Snippet code that must be installed for tracking. However, it does not mention idempotency, side effects, authentication requirements, or rate limits. The behavior is implied to be a read-only retrieval of existing data, but not explicitly stated.
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 well-structured with Args and Returns sections, and an example. It is concise and front-loaded with the core purpose. However, the Returns section is vague ('Tracking tag code snippets') and could be more specific.
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?
Given the tool has only 2 required parameters, an output schema (though not provided in full), and no nested objects, the description sufficiently covers the tool's operation. It explains what the tags are used for and includes an example, making it complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining each parameter: customer_id format (without hyphens) and conversion_action_id. It also provides an example with valid values, clarifying expected inputs beyond the schema's property names.
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 retrieves the tracking tag/snippet for a website conversion action, which is distinct from sibling tools that manage conversions or retrieve performance data. The verb 'Get' combined with the specific resource 'conversion tag' makes 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 tool should be used when needing to install tracking code for a conversion action, but lacks explicit guidance on when not to use it or how it compares to alternatives like list_conversion_actions or get_conversion_performance. No when-to-use or exclusions are provided.
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 provided, and the description lacks details on read-only nature, permissions, pagination, or error handling. It only states the return format without deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with purpose, and structured into Args and Returns sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers core functionality well, but could mention pagination or scope (both campaign and ad group level). Missing some behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by explaining customer_id format (without hyphens) and campaign_id optional behavior (return all if omitted).
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 'Get' and the resources (Final URL suffixes and tracking URL templates) for campaigns and ad groups, distinguishing it from sibling 'set' tools.
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?
No explicit guidance on when to use this tool versus alternatives, such as when you might need to use google_ads_set_* tools. Only mentions optional filtering by campaign_id.
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?
No annotations provided, so the description carries full burden. It states the tool 'finds' and 'combines multiple analyses,' implying a read-only operation, but does not explicitly confirm read-only behavior, permissions, or side effects. It adds some context beyond no annotations but is not highly transparent.
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 well-structured with bullet points and an example. It is concise without unnecessary information, though the example could be integrated into the parameter descriptions. Overall efficient and clear.
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?
Given the tool's complexity and the many sibling tools, the description provides sufficient context: purpose, parameter details, and return type. The output schema exists but is not described here; the mention of 'prioritized recommendations' gives a high-level understanding. It is complete enough for an agent to use effectively.
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 input schema has no descriptions (0% coverage), so the description must explain parameters. It includes an Args section explaining customer_id (10 digits, no hyphens) and opportunity_type with allowed values (ALL, BUDGET, WASTE, PERFORMANCE), adding significant meaning beyond the schema. The default for opportunity_type is not mentioned, but the schema shows 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 tool finds optimization opportunities across the Google Ads account, listing specific categories (budget, waste, performance, quick wins). This distinguishes it from sibling tools like google_ads_wasted_spend_analysis or google_ads_get_optimization_score.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives like google_ads_budget_recommendations or google_ads_get_recommendations. Usage context is implied but not directly stated.
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?
No annotations are provided, so the description carries the full burden. It explains that it searches predefined audiences and lists common categories, but does not disclose whether it is read-only, pagination behavior, or required permissions. The output schema is present but its content is not visible here.
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 well-structured: a brief summary followed by formal Args, Returns, Example, and Common Categories sections. Every sentence is useful, and there is no redundant content.
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 search tool with two parameters and an output schema, the description covers the purpose, parameters, example, and helpful categories. It is slightly lacking in usage guidance versus sibling tools, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lacks descriptions (0% coverage), but the description's Args section adds clear meaning for both parameters: customer_id without hyphens and search_term with examples. This compensates fully for the schema 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 clearly states it searches for Google's predefined audiences such as In-Market and Affinity. Among siblings, no other tool has the same purpose (e.g., google_ads_get_audience_performance is different), so it is well-distinguished.
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 does not provide explicit guidance on when to use this tool versus alternatives like google_ads_get_audience_performance or google_ads_create_user_list. It only implies usage by stating 'Search to find relevant audiences for your business' without 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 provided; description only states 'Set bid adjustments' and mentions return as success message. Does not disclose if it overwrites existing schedules, requires permissions, or has side effects (e.g., destructive). Lacks behavioral details beyond basic 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?
Well-structured: concise intro, bulleted args, return description, and comprehensive example. Every sentence adds value; no 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?
Output schema exists, so return value minimal description is acceptable. Covers purpose, usage context, and all parameters clearly. Lacks explicit prerequisites (e.g., customer/campaign must exist) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. It details each parameter: customer_id format (no hyphens), schedules sub-fields with allowed values (day_of_week, hours/minutes ranges, bid modifier 0.1-10.0), and example values. Adds meaning beyond schema's generic types.
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 it sets bid adjustments for ad scheduling (dayparting), with verbs 'Set bid adjustments' and 'Control when your ads show'. It distinguishes from siblings like 'set_device_bid_adjustments' or 'list_bid_adjustments' by focusing on time/day adjustments.
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?
It provides context (useful for targeting business hours, weekends) but lacks explicit guidance on when to use versus alternatives like 'set_campaign_schedule' or 'set_device_bid_adjustments'. No when-not-to-use or exclusion criteria.
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?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only check ('verifies', 'checks') without explicitly stating it's non-destructive. Sufficient but could be more 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 concise with a clear Args/Returns/Example structure. No redundant text, and the key information is front-loaded.
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?
Given the tool has an output schema, the description doesn't need to detail return values. It covers purpose, parameters, and an example. Could mention error scenarios but is complete enough for a status check tool.
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 schema has no descriptions, but the description adds context for both parameters: customer_id format (10 digits, no hyphens) and merchant_center_id as 'Your Merchant Center account ID'. This adds value beyond bare 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 states the tool's purpose: 'Check the status of your Google Merchant Center feed connection' and elaborates on verifying the link and product flow. This distinguishes it from sibling tools like google_ads_shopping_performance.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or context for better decisions.
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 must fully convey behavioral traits. It warns that changes will be made, but does not disclose if changes are reversible, whether the operation is idempotent, or what permissions are required. It does describe the effect for various recommendation types, which adds value.
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 well-organized with clear sections (main purpose, args, returns, example, warning). It is slightly verbose but each part serves a purpose. The structure aids readability.
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?
Given the tool has 2 required parameters, no annotations, and an output schema exists (but not shown), the description is fairly complete. It explains how to get the resource name, what the tool does, and includes a warning. It could add details about return format or error cases, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully compensates. It explains customer_id format (no hyphens) and recommendation_resource_name as obtained from google_ads_get_recommendations. It provides a concrete example, making parameter usage clear.
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 applies a single optimization recommendation, with examples of recommendation types (keyword, budget, bidding). It distinguishes from sibling tools like google_ads_apply_recommendations_by_type, which applies multiple recommendations of the same type.
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 explains that the tool automatically implements recommendations and includes a warning to review carefully. However, it does not explicitly state when to use this tool versus alternatives like google_ads_bulk_apply_recommendations, nor does it mention any prerequisites (e.g., need to fetch recommendation details first).
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 provided, the description carries full burden. It clearly indicates a read-only operation ('Get metrics') but lacks details on authentication, rate limits, or what happens on error. As a read tool, it is adequate but not comprehensive.
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 fairly concise with a clear intro and structured Args section. It could be slightly tighter, but the format is helpful and not verbose.
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?
Given that an output schema exists, the description does not need to explain return values. All parameters are documented, and the tool's purpose is clear. However, it lacks context on error handling or edge cases, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an Args section that explains each parameter in detail, including format for customer_id, predefined date_range options, campaign_status as list, min_cost as number, limit range, and response_format choices. This adds significant meaning 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 states the tool's function: 'Get comprehensive performance metrics for campaigns.' The verb 'Get' and resource 'performance metrics for campaigns' are specific and distinct from sibling tools like google_ads_account_performance or google_ads_campaign_comparison.
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 retrieving campaign performance but does not explicitly state when to use it over alternatives or provide exclusions. The sibling list exists but no differentiation 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?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the query is read-only, potential side effects, error handling, or rate limits. The tool could be used for mutating data via GAQL, but the description is silent on this, posing a risk for agents.
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 concise: a one-sentence purpose, a contextual note with a link, and a brief parameter list. Every sentence adds value with no redundancy or fluff.
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?
Given the complexity of custom GAQL queries and the presence of an output schema, the description adequately introduces the tool's purpose and parameters. It could be enhanced with a note on typical use cases or safety (e.g., read-only constraint), but it is otherwise sufficient for selection.
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?
With 0% schema description coverage, the description adds meaning beyond the schema by explaining that customer_id should be without hyphens, query is a GAQL string, and response_format accepts 'json' or 'markdown'. This helps agents correctly populate 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 tool executes a custom GAQL query, distinguishing it from the many specific Google Ads tools in the sibling list. The verb 'Execute' and resource 'GAQL query' are specific and unambiguous.
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 explicitly targets 'advanced users who want to write their own GAQL queries,' providing a clear use case. It also includes a link to the query builder. However, it does not explicitly state when not to use this tool or mention alternatives, which would be helpful given the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses it is a read operation ('Get'), explains the score calculation basis (recommendations, priority, impact), and mentions the return value includes a breakdown. This provides good behavioral context beyond a simple 'get'.
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 structured with a clear first sentence, bullet points for explanation, and an example. It is front-loaded but includes some redundancy (e.g., repeating the score meaning). Generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter) and presence of an output schema (context signals), the description adequately covers the purpose, return value, and usage. The example further clarifies invocation.
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 only parameter, customer_id, is described as 'Customer ID (without hyphens)' in the Args section, which adds format guidance beyond the schema (which just says 'string'). Schema coverage is 0%, so the description compensates well.
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 retrieves the account's optimization score (0-100%), explaining what it represents. The name and description distinguish it from sibling tools like google_ads_get_recommendations or google_ads_apply_recommendation, as it focuses solely on the numeric 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 explicit guidance on when to use this tool versus alternatives (e.g., when to use get_recommendations instead). The description does not provide when-to-use or when-not-to-use context, leaving the agent to infer based on tool names alone.
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 must cover behavioral traits. It mentions the output includes who made changes, which is helpful, but does not disclose permissions required, data retention, or potential pagination. It is adequate but not comprehensive.
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 concise and well-structured: a clear purpose sentence, parameter details in docstring style, and an example. Every sentence is relevant and there is no wasted text.
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?
Given the presence of an output schema, the description adequately explains inputs and mentions the output includes who made changes. It does not cover limitations like time range or data freshness, but overall it is sufficiently complete for a simple retrieval tool.
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?
Schema coverage is 0%, so the description must compensate. It provides explicit format instructions (customer_id without hyphens, dates in YYYY-MM-DD) and an example, adding significant value beyond the schema titles.
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 retrieves the history of applied and dismissed recommendations. It specifies the resource (recommendation history) and the verb (get), distinguishing it from siblings like apply_recommendation or dismiss_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 for viewing history but does not explicitly state when to use this tool versus alternatives such as get_recommendations or apply_recommendation. No when-not or alternative guidance is provided.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states it returns details without side effects, but lacks information on permissions required, rate limits, or any limitations. The description is adequate for a simple listing tool but does not go beyond the obvious.
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 concise, using a clear opening line followed by a bullet list for details. Every sentence adds value, and it is front-loaded with the core purpose.
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?
Given the simplicity of the tool and the presence of an output schema, the description covers the essential aspects. It could mention prerequisites like authentication or account linking, but that is implied by the 'current credentials' phrasing. Overall, it is sufficiently complete.
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 single parameter response_format is explained in the description with explicit options ('markdown' or 'json'), adding meaning beyond the schema's title and type. This helps an agent decide how to format the output.
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 lists all Google Ads accounts accessible with current credentials, specifying the returned details (customer IDs, names, currency codes, manager status). This is specific and distinct from sibling tools that focus on performance or modifications.
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 initial account discovery but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Without any exclusions or comparisons, the guidance is only implied.
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 provided, the description carries the full burden. It states the tool generates insights and recommendations, suggesting a read-only operation. However, it does not explicitly confirm whether mutations occur, nor does it mention permissions or side effects. The behavioral profile is partially transparent.
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 well-structured: purpose summary, use-case list, parameter details, and example. It is slightly verbose but front-loaded and easy to scan. Every section serves a purpose.
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 description covers what the tool does, why to use it, and parameter details. An output schema exists, so return value explanation is unnecessary. It lacks edge-case handling or error conditions, but for a tool of this complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides detailed explanations for each parameter: customer_id format, entity_type values, optional entity_id, and date_range options. It includes an example call. This adds significant semantic value 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 states the tool generates AI-powered performance insights and actionable recommendations for specific entity types (campaigns, ad groups, keywords, ads). It lists concrete use cases like low CTR, low conversion rates, etc. This distinguishes it from sibling tools that provide raw performance data or generic recommendations.
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 analyzing performance metrics and getting recommendations, but it does not explicitly state when to use this tool versus alternatives like google_ads_get_recommendations or google_ads_opportunity_finder. It describes the context but lacks exclusion criteria.
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?
No annotations are provided, so the description must convey behavior. It states it retrieves impression share metrics but lacks details on side effects, permissions, or specific return format. The presence of output schema partially compensates.
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 concise with a clear structure: brief intro, Args, Returns, Example. Every section is necessary and well-organized.
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 read tool with an output schema (though not shown), the description covers the key aspects. It could specify the exact metrics, but the output schema likely handles that.
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?
Schema coverage is 0%, so the description compensates by explaining parameters: customer_id (without hyphens), campaign_id (optional filter), date_range (date range). This adds meaningful context beyond the schema titles.
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 'Get' and resource 'search impression share metrics' clearly stating the tool's function. It is distinct from siblings like google_ads_campaign_performance which focus on other metrics.
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 does not explicitly state when to use this tool versus alternatives. While the example implies usage, it lacks guidance on when not to use or mention of other tools for similar purposes.
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?
No annotations are provided, so the description carries the burden. It describes the tool as an 'analysis' but does not explicitly state that it is read-only or disclose any side effects, permissions, or rate limits. The behavioral transparency is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with lists for analyses, parameters, and an example. It is concise, using bullet points and clear sections, every sentence adds value.
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?
Given the tool's analysis purpose and presence of an output schema, the description is fairly complete. It covers what the tool analyzes and returns. However, it lacks mention of prerequisites or permissions, which would improve completeness.
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?
Input schema has no descriptions (0% coverage). The description adds meaning for all three parameters: customer_id format (10 digits, no hyphens), date_range options (LAST_7_DAYS, etc.), and min_cost (default $10). This compensates well for the schema 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 clearly states the tool's purpose: 'Identify sources of wasted ad spend and optimization opportunities.' It lists specific analyses (e.g., high-cost keywords, poor match types), which distinguishes it from sibling tools like google_ads_account_performance.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied but not compared to other tools. No 'when not to use' or alternative suggestions are provided.
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?
No annotations are provided, so the description must disclose behavioral traits. It indicates that the tool returns data and is a read operation (no destructive hints), but does not mention rate limits, authentication requirements, or error handling. It provides basic transparency but lacks depth.
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 well-structured with headers (Provides, Args, Returns, Example) and a bullet list. Every sentence serves a clear purpose, and it is front-loaded with the tool's purpose. No redundant or vague statements.
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?
Given the tool's moderate complexity and the existence of an output schema, the description covers the inputs, output nature, and example usage. It mentions returns 'Auction insights with competitive analysis' which, combined with the required parameters, is sufficient for an agent. However, it could briefly note that the output is a structured report or list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully explains parameters: customer_id format (10 digits, no hyphens), campaign_id, and date_range with enumerated options (LAST_7_DAYS, LAST_30_DAYS, LAST_90_DAYS). The example further clarifies usage. This adds significant value beyond the bare 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 states the tool's purpose: 'Get auction insights and competitive intelligence for a campaign.' It lists specific metrics (impression share, competitive position) and outcomes (recommendations). This verb+resource specification distinguishes it from sibling tools like google_ads_search_impression_share or google_ads_campaign_performance.
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 a usage example and lists parameters, but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or comparisons to similar analysis tools. The example implies typical usage but does not cover exclusions.
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?
No annotations provided, so description carries full burden. It mentions batch operation and returns 'success/failure details', but lacks details on atomicity, limits, idempotency, or error handling beyond vague result.
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?
Well-structured with Args, Schemas, Returns, Example sections. Every sentence is informative; no fluff. Purpose is front-loaded.
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?
Given output schema exists, description doesn't need full return details. Parameters are well-explained. Could be improved by adding batch size limits or atomicity behavior, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully compensates by explaining each parameter: customer_id format, entity_type values, bid_updates_json with complete JSON schemas for both entity types and an example.
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 updates CPC bids for multiple keywords or ad groups in a batch, with specific verb and resource. It differentiates from siblings like single-update tools by emphasizing 'batch 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?
The description implies use for batch updates but does not explicitly contrast with single-update tools or provide when-not-to-use guidance. No alternatives are mentioned.
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 full burden. It discloses creation behavior and parameter constraints but lacks information on idempotency, error handling, authentication, or quotas. The output is mentioned but not detailed.
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 well-structured with a clear intro, requirement note, parameter list with descriptions, return line, and example. It is concise and front-loaded with the main purpose.
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?
Given 8 parameters and presence of output schema, the description covers purpose, requirements, and parameter details thoroughly. It lacks behavioral context like error scenarios, but overall completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides thorough parameter explanations including constraints (e.g., headlines: 3-15, max 30 chars; customer_id: 10 digits, no hyphens). This compensates fully for the schema 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 explicitly states 'Create an asset group for a Performance Max campaign' and explains the role of asset groups in PMax. It distinguishes this tool from siblings like google_ads_create_campaign or google_ads_create_ad_group by focusing on asset group creation and its requirements.
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 mentions PMax requirements but does not explicitly state when to use this tool versus alternatives (e.g., after creating a PMax campaign). It provides context but no why or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the creation behavior, conditional parameter requirements per strategy type, and return value, but does not disclose rate limits, authentication details, or irreversibility. Still fairly transparent.
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 well-structured with a clear hierarchy: purpose definition, strategy types list, parameter descriptions, return value, and example. Each sentence adds value, and it's appropriately sized for the complexity.
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?
Given 9 parameters with conditional logic, the description is thorough. It covers all necessary aspects including output, but could mention uniqueness constraints or error handling to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters are described with examples, units, and conditional requirements (e.g., target_cpa for TARGET_CPA). The description compensates fully for the schema's 0% description coverage, adding meaning beyond titles.
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 it creates a portfolio bidding strategy for shared use, specifying 'create' as the verb and 'bidding strategy' as the resource. It also lists strategy types and distinguishes from other tools by emphasizing portfolio and shared use.
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 guidance on when to use this tool vs alternatives like assign_bidding_strategy or update_bidding_strategy. No prerequisites or exclusions mentioned, leaving the agent without context for proper selection.
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?
No annotations are provided, so the description must disclose behavioral traits. It describes the AI-optimization nature and parameter details but does not mention side effects (e.g., immediate spending, permissions needed, reversibility). This is adequate but lacks depth.
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 concise and well-structured: a clear purpose statement, a line explaining Performance Max, a list of arguments with descriptions, and an example. Every sentence adds value without fluff.
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?
Given the complexity (6 parameters, create operation), the description covers parameter semantics and provides an example. It lacks prerequisites (e.g., valid customer_id) and output description (but output schema exists). Slightly incomplete but mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: customer_id (10 digits, no hyphens), campaign_name, budget_amount (daily budget), conversion_goals_json (JSON array), target_roas (optional), target_cpa (optional). The example demonstrates usage, adding significant value.
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 creates a Performance Max campaign and explains that it optimizes across multiple Google channels (Search, Display, YouTube, Gmail, Discover, Maps), distinguishing it from other campaign creation tools like create_app_campaign or create_shopping_campaign.
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 Performance Max campaigns but does not explicitly state when to use it versus alternatives like google_ads_create_campaign or google_ads_create_app_campaign. No exclusions or when-not-to-use guidance is provided.
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?
Annotations are not provided, so the description carries the full burden. It describes the creation action and parameters, but does not disclose side effects, required permissions, or limits. The example shows usage but no behavioral details like what happens if a group already exists.
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 well-structured with a short summary, explanation, parameter list, return info, and example. Every sentence adds value, and it is front-loaded with the core purpose. No redundant or verbose text.
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?
Given the tool has 5 parameters and an output schema exists, the description covers the purpose, parameters, and example. It is complete for most use cases, though it does not describe the output format beyond 'product group creation result' (but output schema may fill that). Still, it could mention prerequisites or constraints like ad group type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for all parameters: customer_id format, ad_group_id, product_condition with examples (NEW, USED, REFURBISHED), product_type explanation, and is_subdivision with true/false behavior. The example further clarifies usage.
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 it creates a product group in a shopping ad group. It specifies the verb 'create', the resource 'product group', and provides context on what product groups do. Among sibling tools, none are specifically for product group creation, making it distinct.
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 explains what product groups are and how to partition them, but lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons with other creation tools, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides some behavioral context (e.g., priority affects bidding), but lacks information on creation behavior (e.g., whether the campaign is paused by default, or if it overwrites existing campaigns). No details on authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the core purpose, then a brief explanation, followed by a clear Args list, Returns, and an example. Every sentence adds value without 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?
Given 7 parameters and no annotations, the description covers the tool's purpose and parameter meanings adequately. It could add context about the campaign's initial status or prerequisites (e.g., Merchant Center account required), but the example and return type provided are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter, including formats (e.g., '10 digits, no hyphens'), defaults, and constraints (e.g., 'LOW, MEDIUM, HIGH' for priority). The example further clarifies usage.
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 'Create a Google Shopping campaign' and explains that Shopping campaigns promote products from Merchant Center, distinguishing it from other campaign types like App, Local, or Performance Max campaigns mentioned in sibling tool names.
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 promoting products via Google Shopping but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative tool references are provided.
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?
No annotations are provided, so the description carries the full burden. It states 'Get performance metrics' (a read operation) and describes the return type as a breakdown by audience. This is adequate but doesn't discuss rate limits, data freshness, or other behavioral traits.
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 structured with a brief intro, parameter descriptions, expected return, and a complete example. It is concise with no wasted words and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context signal: has output schema: true), the description appropriately omits return format details. It covers purpose, all three parameters, and provides an example. This is sufficient for an agent to understand and invoke the tool.
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?
Schema coverage is 0%, so the description adds value by specifying customer_id format ('without hyphens'), campaign_id as optional filter, and example date ranges (TODAY, LAST_7_DAYS, etc.). However, it doesn't list all possible date_range values or clarify campaign_id format further.
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 and resource: 'Get performance metrics by audience.' It specifies what it does (see which audiences drive best results in terms of clicks, conversions, ROI). This distinguishes it from sibling tools like account_performance or campaign_performance.
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 audience-level performance analysis but does not explicitly state when to use versus alternatives like google_ads_search_google_audiences (which lists audiences) or other performance tools. No exclusions or prerequisites are mentioned.
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?
No annotations are provided, so the description bears the full burden. It indicates a read operation (get performance) and notes the return format (markdown). However, it lacks details on data freshness, specific metrics returned beyond examples, or any authentication requirements, offering only adequate 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 concise and well-structured: a one-line summary, a brief elaboration, then a clear list of arguments, return type, and an example. Every sentence adds value without 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?
Given the existence of an output schema, the description adequately covers inputs, output format (markdown), and example metrics. It could mention that performance is aggregated across all campaigns (already implied) but is otherwise complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: it specifies customer_id format (without hyphens), identifies bidding_strategy_id as a strategy ID, and provides valid date_range values (TODAY, YESTERDAY, etc.) with an example. This compensates fully for the schema's lack of descriptions.
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 it retrieves performance metrics for a portfolio bidding strategy, specifying it shows aggregate performance across all campaigns using the strategy. This distinguishes it from sibling tools like google_ads_get_bidding_strategy_details (which would get strategy details) and google_ads_campaign_performance (which is per-campaign).
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 explains it shows aggregate performance across campaigns using the strategy, implying use when an overview is needed. However, it does not explicitly state when not to use it or mention alternative tools like google_ads_campaign_performance for per-campaign data, leaving guidance incomplete.
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 full burden. It discloses what the tool returns (upload status, match rate, list sizes) and includes an advisory on timing. However, it does not mention any side effects, permissions needed, or that it's read-only (which is implied by 'Get').
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 moderately concise with clear sections (intro, usage tip, args, returns, example). It is front-loaded with the core purpose. Could be slightly trimmed but overall well-structured.
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 output schema is present (has output schema: true), so the description's mention of return values (upload status, match rate, list sizes) is sufficient. The tool is simple and the description covers all key aspects for a status check.
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 input schema has 0% description coverage (only titles). The description adds meaning: customer_id format (no hyphens) and user_list_id as the list to check. The Args section explicitly explains parameters, surpassing schema-only information.
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: 'Get Customer Match upload status, match rate, and list size.' It uses specific verbs and resource, and distinguishes itself from sibling tools (like upload or list tools) by being a read-only status check.
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 provides timing guidance ('Check this 24-48 hours after uploading') and a minimum threshold ('minimum 1,000'), which helps the agent decide when to invoke. It lacks explicit when-not scenarios but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the basic mutation (prevent showing to specific audiences) but does not disclose whether exclusions overwrite or append, or required permissions.
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?
Description is structured with action, args, returns, example, and use case. It is slightly verbose but not overly so; each sentence adds value.
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?
Given output schema exists (as per context), description adequately covers purpose, parameters, and example. Missing error handling details, but complete for a simple exclusion tool.
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?
Schema coverage is 0%, so description compensates by explaining each parameter: customer_id without hyphens, campaign_id, user_list_ids as list. Example adds clarity, though could mention how to obtain user_list_ids.
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 'Exclude audiences from a campaign' with specific common use cases, making it distinct from sibling tools like adding audiences or setting signals.
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?
Provides context on when to use (exclude existing customers, converters, low-value segments) and implies exclusion vs targeting, but lacks explicit comparisons to alternatives like google_ads_add_audience_to_campaign.
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 behavioral traits. It states 'configure' but does not specify whether the tool overwrites existing signals, what permissions are required, or any side effects. The lack of detail on mutation behavior 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 well-structured with a summary, parameter explanations, and an example. It is not excessively long, though the 'Args:' section could be slightly more concise. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 2 required) and the presence of an output schema, the description is complete. It explains all parameters, provides usage context, and includes an example. No further information is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning. It explains search_themes as 'List of search theme strings (max 25 per asset group)' and customer_id format ('10 digits, no hyphens'). This goes well beyond the bare schema types.
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: 'Configure audience signals and search themes for a Performance Max asset group.' It distinguishes itself from sibling tools like google_ads_add_audience_to_ad_group and google_ads_add_audience_to_campaign by focusing specifically on PMax asset groups, which is a distinct 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it explains that both search themes and audience signals are optional, and gives examples. However, it does not explicitly state when not to use this tool or mention alternatives, which would make it more definitive.
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?
The description indicates that the tool performs a write operation (updates campaign) and mentions that passing an empty string clears the suffix. However, with no annotations provided, it does not disclose potential side effects, authorization requirements, rate limits, or idempotency. For a straightforward update, the disclosure is adequate but not comprehensive.
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 brief: one sentence stating purpose, followed by an Args block with clear parameter explanations, and a Returns line. Every element serves a purpose, no fluff. It is well-structured and easy to parse.
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?
Given the tool's simplicity (3 simple params, update operation) and the presence of an output schema (though not shown in input), the description covers the essential behavior and parameter details. It could be improved by noting that the tool modifies existing campaign settings without affecting other configurations, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden of explaining parameters. It clearly defines customer_id (without hyphens), campaign_id, and url_suffix with usage guidance (e.g., example URL parameters and how to clear). This adds significant meaning beyond the schema's type and title fields.
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 ('Set') and resource ('Final URL suffix for a campaign'). It clearly distinguishes from sibling tools like google_ads_set_ad_group_url_suffix, which targets ad groups instead of campaigns. The 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does (sets URL suffix for campaign) and provides an example, but does not explicitly state when to use this tool vs alternatives like the ad group suffix tool or the batch versions. No usage exclusions or context are given, leaving the decision to the agent based on implicit knowledge.
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?
No annotations exist, so the description must cover behavioral traits. It describes the tool as retrieving read-only metrics but lacks details on rate limits, authentication, or any side effects. It is a simple retrieval, but more transparency would be beneficial.
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?
Description is front-loaded with purpose, includes args and a clear example. While efficient, it could be slightly more concise without the example, but overall well-structured.
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?
Given the presence of an output schema, the description adequately explains the function. It covers all three parameters and gives a high-level return type. For a read tool with simple parameters, this is sufficient.
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?
Input schema has 0% description coverage, but the description adds valuable meaning: customer_id format (10 digits, no hyphens), campaign_id as optional, and date_range with example values. This compensates well for the schema 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?
Description explicitly states 'Get performance metrics for Shopping campaigns' and highlights ROAS, clearly differentiating from other performance tools like google_ads_campaign_performance and google_ads_account_performance.
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?
Description indicates critical use for Shopping campaign optimization, providing clear context. However, it does not explicitly mention when not to use or list alternative tools for other campaign types.
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?
No annotations are provided, so the description must disclose behavioral traits. It notes using the same upload mechanism as offline conversions and gives a detailed example, but lacks specifics on authentication, success/error handling, or rate limits. The returns field is minimal ('Upload success message'), adding limited behavioral insight.
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 concise with clear sections: purpose, args, returns, example, note. Every sentence adds value with no redundancy. It is well-structured and easily readable.
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 description covers purpose, parameters, and an example, but lacks details on error handling, validation rules, or prerequisites. Given the complexity of store sales uploads, more completeness (e.g., requirements for gclid format or timestamp format) would improve usability. Output schema is not provided but returns description is minimal.
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?
Input schema has 0% coverage with no descriptions. The description compensates with an Args section explaining each parameter: customer_id format, conversion_action_id type, and store_sales as a list with keys. The example further clarifies the structure. This adds substantial meaning 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 states 'Upload store sales data (in-store purchases from online clicks)' and 'specialized form of offline conversion upload for retail businesses tracking in-store purchases that originated from online ads', providing a specific verb and resource that distinguishes it from other upload tools like google_ads_upload_offline_conversions.
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 implies the tool is for store sales conversions but does not explicitly state when to use it versus alternatives like google_ads_upload_offline_conversions. The sibling list includes multiple upload tools, so clearer guidance would help. However, the specialized labeling provides enough context for informed selection.
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?
No annotations are provided, so the description must carry the burden. It explains the two modes and returns a success message, but does not disclose whether audience targeting is additive or replaces existing settings, nor does it mention permissions or error conditions.
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 well-structured with a clear purpose, separate sections for modes, args, examples, and a recommendation. Every sentence is informative and there is no redundant information.
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 an output schema available, the description need not detail return values. It covers essential aspects: operation, parameters, modes, and best practice recommendation. Missing prerequisites (e.g., user list must exist) and potential side effects, but is sufficiently complete for an additive operation.
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?
Despite 0% schema description coverage, the description thoroughly explains each parameter: customer_id format, campaign_id, user_list_id, and targeting_mode with two options and a default. Examples illustrate usage clearly, adding significant value 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 states it adds audience targeting to a campaign and explains two distinct modes (OBSERVATION and TARGETING). It distinguishes from sibling tools like google_ads_add_audience_to_ad_group by specifying the campaign scope.
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?
Provides explicit recommendations on when to use each mode (start with OBSERVATION) and explains the purpose of each mode. However, it does not compare with other audience-related tools (e.g., google_ads_set_audience_exclusions) or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is a mutation operation (adds keywords) with no annotations. It mentions the return format (success message with count) but lacks detail on error cases like non-existent shared list or duplicate keywords. The behavior is adequately described but not exhaustive.
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 well-structured with a summary, args, returns, and example. However, the first two sentences are slightly redundant ('Add negative keywords' and 'This adds keywords'). Still clear and front-loaded. Minor verbosity.
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?
Given the tool's simplicity and presence of an output schema, the description covers purpose, parameters, example, and return. It does not cover error conditions or prerequisites (e.g., shared list must exist), but overall it is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the schema for 'keywords' is vague (array of objects with string additional properties). The description adds crucial meaning by specifying each dict must have 'text' and 'match_type' and provides an example. This fully compensates for the schema gaps.
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 'Add negative keywords to a shared negative keyword list (account-level)' and explains that the list can be applied across multiple campaigns. This distinguishes it from sibling tools like google_ads_add_negative_keywords which likely operate at campaign or ad group level.
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 implies use for account-level negative keyword management across campaigns. It does not explicitly state when not to use or name alternatives, but the phrase 'account-level shared' differentiates it from campaign-specific tools. Some guidance is provided.
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?
No annotations are provided, so the description bears full behavioral transparency burden. It discloses that 'The campaign will switch from its individual budget to the shared budget,' which is a key behavioral change. However, it does not mention whether the operation is reversible, what permissions are required, or what happens if the campaign already uses a shared budget.
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 very concise: a single sentence for the main action, followed by an Args list and a Note. Every sentence is essential and there is no extraneous text. It is well-structured and front-loaded.
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?
Given the tool's simplicity and the presence of an output schema (though not detailed in the description), the description covers the main action, parameter sources, and a behavioral note. It lacks details on error handling or what happens if the budget resource is invalid, but overall it provides sufficient context for typical usage.
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?
Input schema has 0% description coverage, but the description adds value by explaining parameter sources and formatting: customer_id (without hyphens), campaign_id, and budget_resource_name (from sibling tool). This helps the agent understand where to get the values, going beyond the schema's type-only fields.
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 'Assign a shared budget to a campaign.' It uses a specific verb ('Assign'), identifies the resource ('shared budget'), and the target ('campaign'), which distinguishes it from siblings like 'google_ads_create_shared_budget' or 'google_ads_update_campaign_budget_v2'.
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 indicates that the budget_resource_name should come from 'google_ads_create_shared_budget', implying a prior step. The note about switching from individual to shared budget provides context on when to use this tool (when a campaign currently has an individual budget). It does not explicitly state when not to use it or list alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details required/optional fields, defaults, match types, and return format. It does not mention destructive nature or auth, but is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (Args, Schema, Returns, Example) and front-loaded purpose. Slightly long due to schema reproduction but appropriate for complexity.
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?
Complex batch operation with nested JSON; description covers input structure thoroughly. Output is described as 'result with success/failure details' which is sufficient given output schema availability (though not shown).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully compensates: explains customer_id format (10 digits, no hyphens) and keywords_json as a JSON array with complete sub-schema (ad_group_id, text, match_type, cpc_bid, defaults, and match type enum).
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 function: 'Add multiple keywords in a single batch operation.' The verb 'Add' and resource 'multiple keywords' are specific, and 'batch' distinguishes it from singular add_keywords or bulk_add_keywords siblings.
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 batching is for efficiency, but does not explicitly state when to use this tool versus alternatives like add_keywords or bulk_add_keywords. No when-not or exclusions are provided.
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?
No annotations are provided, so the description carries the full burden. It describes the output as a comparative analysis with rankings and insights and lists metrics. It does not mention side effects, authentication needs, or rate limits, but it is clear it is a read-only analysis 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 well-structured with sections (overview, args, returns, example, metrics, use cases) and is front-loaded with the main purpose. It is slightly repetitive (first line restates title) but overall efficient for the amount of detail.
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?
Given no annotations, 4 parameters (2 required), and an output schema, the description covers usage constraints (2-10 campaigns), metrics, and provides an example. It does not need to detail the output structure since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter in the Args section, including examples and defaults. It adds meaning beyond the schema's type and title, such as the format of campaign_ids and the default for date_range.
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 it compares performance across multiple campaigns side-by-side, lists specific metrics, and distinguishes from siblings like google_ads_campaign_performance (single campaign) and google_ads_compare_ad_performance (ads).
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 provides clear use cases such as identifying top performers, optimizing budget, and finding underperformers. It also notes the constraint of comparing 2-10 campaigns. However, it does not explicitly state when not to use the tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 key behavioral traits: campaigns start in PAUSED status, require a live app store listing, automatically create ads from app store assets, and allow additional asset uploads. It also describes the return dictionary. However, it does not mention rate limits, authentication requirements, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections: overview, Args, Returns, Example, and Notes. It is front-loaded with the core purpose. While it is somewhat lengthy, every sentence adds value given the tool's complexity. There is minimal 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?
The tool has 7 parameters (6 required) and an output schema. The description covers all required parameters, explains the output structure via the Returns section, and includes practical notes about paused status, app store requirements, and asset options. Minor gaps include lack of error handling details or validation rules, but overall it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the schema alone provides no parameter meanings. The description fully compensates by detailing each parameter: customer_id format, campaign_name, app_id explanation, app_store allowed values, budget_amount as daily budget, bidding_strategy_goal_type with all five options and explanations, and target_cpa as optional. This adds significant value beyond the bare 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 defines the tool's purpose: create a Universal App Campaign (UAC) to promote mobile app installs and engagement. It specifies the resource (UAC) and the action (create), distinguishing it from sibling tools like google_ads_create_campaign or google_ads_create_performance_max_campaign by focusing specifically on app promotion.
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 explains what the tool does and includes notes about campaigns starting paused and requiring a live app store listing, but it does not explicitly state when to use this tool versus alternatives like google_ads_create_campaign or google_ads_create_performance_max_campaign. The usage context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses behavioral traits: it requires GMB linking, starts campaigns in PAUSED status, notes 4-6 weeks for store visit data accumulation, and mentions automatic placement optimization across Google properties. This adds useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns, Example, Notes) and front-loads key information. While informative, it is slightly verbose; however, it efficiently conveys all necessary details without 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?
Given the tool's complexity (5 parameters, creation behavior, and dependencies), the description covers purpose, parameter details (enhanced with format/values), output structure via Returns, and behavioral notes. Omits error handling or permissions beyond GMB linking, but overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's Args section adds significant meaning beyond the schema's 0% coverage, detailing format for customer_id (10 digits, no hyphens), daily budget amount, location IDs, and allowed optimization_goal values ('STORE_VISITS' or 'STORE_SALES'). The example further clarifies usage.
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 'Create a Local campaign to drive store visits and foot traffic' and explains that it promotes physical business locations. This verb+resource combination distinguishes it from sibling campaign creation tools like create_campaign, create_app_campaign, etc., which target different campaign types.
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 context that local campaigns require Google My Business integration and are for physical stores, but it does not explicitly state when to use this tool versus alternatives or provide when-not guidance. It lacks comparative usage direction among 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It describes the data returned (metrics) and competition levels, but does not disclose potential API limits, data freshness, or authentication requirements. The description adds context but could be more comprehensive.
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 well-structured with sections for intro, args, returns, example, and common IDs. It is informative without being overly verbose. Minor improvement could be trimming redundant information, but it is well-organized.
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?
Given the existence of an output schema (not shown), the description adequately summarizes returns. It covers parameters, examples, and common values. It could mention the response_format more explicitly, but overall it is complete for a keyword research tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates fully by detailing each parameter in the 'Args' section, including defaults, examples, and explanations like location IDs and competition levels. It provides far more meaning than the bare 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 states the tool's purpose: 'Get keyword ideas from Google Ads Keyword Planner.' It specifies the output includes search volume, competition level, and bid estimates. This distinguishes it from sibling tools like google_ads_keyword_forecast (forecasting) and google_ads_get_keyword_performance (historical performance).
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 explains how to generate suggestions using seed keywords or a webpage URL. It provides an example and common location/language IDs. However, it does not explicitly state when to use this tool over alternatives or mention any prerequisites like customer setup.
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?
The description discloses the main action but lacks details on side effects (e.g., immediate application, overwriting behavior), permissions required, or idempotency. Since no annotations are provided, the description should cover these traits more thoroughly.
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 well-structured with Args, Returns, Example, and models sections. It is slightly verbose but front-loads the main purpose and uses bullet points for readability. Every sentence adds value.
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?
Given the output schema exists, the description adequately covers parameters and usage. It provides an example and model details. However, it could include error handling or prerequisite steps (e.g., conversion action must exist) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by explaining each parameter (customer_id, conversion_action_id, attribution_model) and listing possible values for attribution_model with descriptions. This compensates for the 0% schema description 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 clearly states it sets the attribution model for a conversion action with a specific verb and resource. It provides a concise purpose and explains what attribution models do, distinguishing it from sibling tools that perform other actions.
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 includes a recommendation to use DATA_DRIVEN with sufficient data and lists model options. However, it does not explicitly state when to use this tool versus alternatives, such as when to modify vs. create conversion actions. The example and model list provide good context but lack exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses hashing (SHA256), privacy, typical match rate (30-70%), and return type. However, it omits details on append vs overwrite behavior, rate limits, or error conditions.
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 well-structured with a summary, details, args list, returns, example, and notes. It is somewhat verbose but front-loads the key action. Minor redundancy, e.g., the privacy note could be integrated.
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?
Given 9 parameters and no annotations, the description covers purpose, parameters, behavior, and example. It mentions output schema briefly. Lacks error handling and limits, but is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully. It provides detailed parameter descriptions including phone format (E.164), index matching for names, country codes, and an example. This significantly aids correct invocation.
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 'Upload Customer Match data (emails, phones, addresses)' and explains the purpose of Customer Match for reaching users on Google properties. It distinguishes from sibling upload tools by focusing specifically on Customer Match.
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 explains when to use existing vs new lists but does not compare with alternatives like upload_offline_conversions or upload_store_sales. It lacks explicit 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool adds callouts (a mutation) and mentions requirements, but does not disclose error handling, side effects, or prerequisites like permissions. This is adequate but not comprehensive.
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 well-structured with clear sections, front-loaded purpose, and an example. Every sentence adds value, and there is no redundancy. It is concise yet informative.
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 mutation tool with 3 parameters and an output schema (present but not shown), the description covers input requirements adequately. It does not detail the output structure, but the existence of an output schema mitigates this. Slightly more detail on return format could raise to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds significant value: specifies format for customer_id (10 digits, no hyphens), provides an example JSON array for callouts_json, and gives a full schema. This fully compensates for the lack of schema descriptions.
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 'Add callout extensions to a campaign' and explains what callouts are. This distinguishes it from sibling tools like add_sitelink_extension or add_call_extension by specifying the type of extension.
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 provides requirements (character limit, min/max callouts) and an example, helping the agent understand proper usage. However, it does not explicitly contrast with alternatives or mention when not to use (e.g., when campaign already has max callouts).
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?
No annotations are provided, so the description bears full responsibility. It describes the effect (show address, phone, map marker) and mentions requirements and optional phone, but lacks details on idempotency, error handling, or permission needs.
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 well-structured with sections (Args, Example, Benefits, etc.) and front-loaded with purpose. However, it is somewhat lengthy with some repetition, such as benefits reiterating earlier points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9 parameters and no schema descriptions, the description thoroughly covers all inputs, includes an example, and provides usage context and requirements. The output schema exists but is not shown; the description explains the return value sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed parameter explanations (format, length, examples) for all 9 parameters, fully compensating for the missing schema descriptions.
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 'Add a location extension to display your business address in ads' and explains what location extensions do. It effectively distinguishes from sibling extension tools by focusing on address display, a unique purpose.
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 provides requirements (address verification, GMB linking, valid fields) and a note on advanced management, but does not explicitly compare with other extension tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. Describes the operation as retrieving metrics, implying a read-only, non-destructive action. Lists specific metrics returned, but does not mention rate limits, authentication needs, or data freshness. Overall satisfactory but lacks some depth.
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?
Well-structured with headers for description, args, returns, example, and metrics. Content is relevant and front-loaded. Slightly verbose due to example and metrics list, but still concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (true) and only three parameters, the description is complete. Covers all parameter details, return structure, and examples, providing sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates by explaining each parameter: customer_id format, campaign_id as optional filter, date_range with enum examples. Also describes return structure and lists metrics, adding significant meaning beyond the bare 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?
Explicitly states 'Get performance metrics for App campaigns', using a specific verb and resource. Distinguishes from sibling tools like google_ads_campaign_performance and google_ads_app_conversions by focusing on app campaign metrics.
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?
Provides example usage and explains optional parameters, but does not explicitly state when to use this tool versus alternatives such as google_ads_campaign_performance or google_ads_app_conversions. No exclusion criteria or context for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses that it creates ads and returns success/failure details, but does not mention authentication needs, rate limits, whether the batch is atomic, or any side effects. Moderate transparency but missing important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: summary, parameter explanations, schema example, required fields, return type, and example call. Every sentence adds value, and the length is appropriate for the complexity.
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 description covers most essentials: parameters, configuration schema, required fields, and a usage example. However, it lacks batch size limits or error handling details. Given the presence of an output schema (not detailed), it is nearly complete but could mention constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description adds substantial meaning: it explains customer_id format, ads_json structure with a full schema example, required fields, and constraints (headlines 3-15, descriptions 2-4). This goes far beyond the minimal schema titles.
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 'Create multiple responsive search ads in a single batch operation,' specifying the verb (create), resource (responsive search ads), and scope (batch, multiple). It distinguishes itself from the sibling tool 'google_ads_create_responsive_search_ad' which creates a single ad.
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 implies usage for bulk creation via 'batch operation' and the JSON array schema, but it does not explicitly state when to use this vs the single ad creation tool, nor does it provide when-not or alternatives. The context is clear enough but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 warns that applying changes is destructive ('This will make changes to your account') and advises reviewing recommendations. It also describes the return value. However, it does not disclose behavior on partial failures or idempotency, which would enhance 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 well-organized with sections for purpose, usage, arguments, returns, example, and warning. Each sentence adds value and there is no redundancy. It is concise yet comprehensive, earning its place.
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?
Given the tool's complexity and the presence of an output schema, the description covers the core functionality and return value. However, it omits details like maximum number of recommendations per batch and does not differentiate from sibling tools like google_ads_apply_recommendations_by_type, which could be improved for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains the customer_id format ('without hyphens') and that recommendation_resource_names are resource names, supplemented with a concrete example. This fully compensates for the lack of schema descriptions, making the parameters clear and usable.
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 'Apply multiple recommendations at once' and provides an example with multiple resource names, effectively distinguishing it from single-recommendation tools like google_ads_apply_recommendation. The verb+resource and efficiency mention make the purpose specific and 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 explains when to use (applying several recommendations efficiently) but lacks explicit guidance on when not to use it, such as for individual application or type-based filtering. It does not mention alternatives like google_ads_apply_recommendation or google_ads_apply_recommendations_by_type, which would help an agent choose correctly.
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 provided, the description carries the full burden. It describes the creation action and return type but does not disclose potential side effects, idempotency, permissions required, or rate limits. It is adequate but lacks depth.
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 concise, well-structured with Args, Returns, and Note sections. Every sentence is purposeful and no extraneous information is present.
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?
Given the medium complexity (4 parameters, output schema exists), the description is nearly complete. It covers all parameters, return type, and a follow-up step. Missing details like error handling or idempotency, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining each parameter: customer_id format (no hyphens), budget_name, daily_amount unit and example, and delivery_method options with default. This adds significant meaning 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 states the purpose: 'Create a shared budget that can be used across multiple campaigns.' It uses a specific verb ('create') and resource ('shared budget'), and explains the cross-campaign usage, distinguishing it from sibling tools like google_ads_assign_shared_budget.
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 explicitly mentions when to use a sibling tool: 'After creating a shared budget, use google_ads_assign_shared_budget to assign it to campaigns.' This provides clear context, but lacks explicit when-not-to-use guidance or alternatives beyond the one sibling.
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?
No annotations are provided; the description does not disclose side effects, permissions, or whether the operation is read-only. It explains parameters but lacks behavioral depth beyond the export action.
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 concise and well-structured with an Args section, Returns clarification, and an example. Every sentence adds value without 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?
Given the tool's simplicity (3 parameters, no nested objects, output schema exists), the description is complete. It specifies return type (CSV formatted data) and provides a usage example, though output structure details are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: customer_id format (10 digits, no hyphens), entity_type values (campaigns, keywords), and campaign_id as optional filter. This adds significant meaning 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 states the tool exports account structure to CSV, specifies entity types (campaigns, keywords) and optional campaign filter, distinguishing it from sibling tools like import_from_csv or get_campaign_details.
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 implies usage for exporting structured data to CSV, and the sibling set suggests alternatives for importing or viewing details, but it does not explicitly state when not to use or compare with other 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it describes the output (projected metrics) and parameter details, it does not explicitly state that the tool is read-only, non-destructive, or mention any authentication or rate limits. The forecast nature implies safety, but explicit confirmation is missing.
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 well-structured with a summary sentence, bullet-point Args, Returns, Example, and dedicated sections for Match Types and Date Intervals. It is somewhat verbose but all content is valuable. The purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, defaults, output schema exists), the description covers all aspects: parameter details, return value, example usage, and enumeration of valid values for match types and date intervals. It is complete and leaves no ambiguity for execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so thoroughly: each parameter is explained with format, defaults, and examples. Match types and date intervals are described in separate sections. This provides rich beyond-schema semantics.
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 starts with 'Forecast traffic metrics for specific keywords,' which clearly states the action (forecast) and the resource (traffic metrics for keywords). It further details what metrics are projected (impressions, clicks, costs) and provides a concrete example. This is specific and distinguishable from sibling tools like google_ads_keyword_ideas or google_ads_performance_forecaster, though it does not explicitly differentiate.
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 includes Args, Returns, Example, and separate sections for Match Types and Date Intervals. It provides clear guidance on how to use the tool and what parameters to provide. However, it lacks explicit instructions on when to use this tool versus alternatives, such as google_ads_keyword_ideas or google_ads_estimate_keyword_traffic.
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 transparency burden. It explains overriding behavior and clearing via empty string, but does not disclose side effects, permissions, or failure modes. Partial but not fully transparent.
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 concise and well-structured with separate sections for purpose, args, and returns. Every sentence adds value, with no redundancy or unnecessary details.
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 set operation, the description covers main purpose, parameter semantics, and basic behavior (override/inherit). It lacks error handling or permission details, but the task is straightforward. A minimal output schema is implied but not described, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful semantics beyond the input schema: customer_id format (no hyphens), url_suffix example and behavior for empty string. Schema has 0% description coverage, so the description fully compensates with clear parameter guidance.
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 sets the Final URL suffix for an ad group, overriding campaign-level suffixes. It uses specific verb-resource pairing and distinguishes from the campaign-level sibling tool.
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 explains when to use (setting/clearing ad group suffix) and the effect of an empty string to inherit campaign suffix. It lacks explicit mention of alternatives like batch operations but provides sufficient context for typical use.
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?
No annotations are provided, so the description carries full burden. It explains the effect (increase/decrease bids), the range (0.1 to 10.0), and default behavior (1.0 = no change). However, it does not disclose whether it overwrites existing adjustments, required permissions, or error handling for out-of-range values.
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 concise and well-structured: a brief intro, common adjustments list, parameter definitions, return statement, and a clear example. Every sentence adds value, and the layout aids readability.
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 description covers the tool's purpose, parameters, range, default behavior, and includes an example. It explains what the tool does and returns. It lacks only minor details like error cases or validation, but for a setter tool with a straightforward output, it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description lists each parameter with its purpose and valid range (e.g., mobile_modifier: 0.1 to 10.0). The 'Args' section and example add significant meaning beyond the schema, which only provides types and titles.
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 'Set bid adjustments for different device types', using a specific verb and resource. It distinguishes from siblings like 'google_ads_list_bid_adjustments' (list) and 'google_ads_set_ad_schedule_bid_adjustments' (schedule), as well as other set tools.
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 explains the purpose and range of bid modifiers, with common examples, but does not explicitly direct when to use this tool over alternatives (e.g., when to set device vs ad schedule adjustments). It implies usage but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: requires Google My Business integration, 4-6 week data accumulation, probabilistic modeling, and aggregation for privacy. This is sufficient context for an agent to understand the tool's constraints.
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 well-organized with clear sections (summary, args, returns, example, important notes). It is concise, front-loads the purpose, and each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (documenting return fields) and 3 parameters, the description covers all necessary context: parameter details, return structure, data latency, and prerequisites. No significant gaps are present.
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?
Input schema has zero description coverage, so the description adds essential meaning: customer_id format (10 digits, no hyphens), campaign_id optional with filtering behavior, and date_range with explicit examples (LAST_7_DAYS, LAST_30_DAYS). This is thorough for the three 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 tool retrieves store visit conversion data specifically for Local campaigns. The verb 'Get' and resource 'store visit conversion data' are precise, and the tool is well-distinguished from sibling reporting tools like google_ads_local_performance.
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 local campaigns and provides important context (GMB integration, data latency) but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusion criteria or sibling comparisons are offered.
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?
No annotations are provided, so the description carries full behavioral disclosure burden. It explains that this is a write operation requiring GCLID, details parameter format, and mentions a return message. However, it lacks information on limitations like maximum batch size, rate limits, error handling, or idempotency, which are gaps given no annotations.
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 well-structured with a clear header, bulleted Args, Returns, and an example. It is concise with no redundant sentences; every part adds value, including the tip about GCLID capture. The front-loaded purpose is immediately actionable.
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?
Given the tool's complexity (3 params, one nested object), the description covers parameter meanings, required fields, format, and return value. An output schema exists but is not shown; the description mentions return is a success message with count, which is sufficient. Sibling tools exist, but the description provides enough context for correct usage. Minor gaps in behavioral transparency prevent a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds significant meaning: customer_id format (no hyphens), conversion_action_id requirement (IMPORT origin), and conversions as a list of dicts with required fields (gclid, conversion_date_time) and optional fields (conversion_value, currency_code), plus date format details. This fully compensates for the schema's lack of descriptions.
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: uploading offline conversion data (CRM conversions, phone orders, store visits) that originated from Google Ads clicks. It distinguishes from siblings by specifying the use of GCLID and offline conversions, differentiating it from other upload tools like upload_call_conversions or upload_customer_match.
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 provides clear guidance on when to use the tool: 'Upload offline conversion data' and 'import conversions that happen offline but originated from Google Ads clicks.' It mentions the prerequisite of having GCLID. However, it does not explicitly state when not to use it or compare to alternative tools among siblings, though the context implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the read-only nature, describes possible recommendation types, and mentions output formatting options. However, it does not address pagination, rate limits, or default behavior when no recommendations exist.
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 well-structured with sections (overview, Args, Returns, Example, Common Types). Every sentence adds value, no fluff. Information is front-loaded with clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of output schema, the description provides sufficient context: purpose, parameter details, return value description, and example. The common types list further clarifies the scope of recommendations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully by explaining each parameter: customer_id format, recommendation_types as optional list with common values, campaign_id as optional filter, and response_format options. Provides example and common types list.
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 retrieves optimization recommendations from Google Ads. It explains that recommendations are specific optimizations like keywords, budgets, bid strategies, distinguishing it from sibling tools that apply or dismiss recommendations.
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 fetching current recommendations but does not explicitly state when to use this tool vs alternatives like google_ads_get_recommendation_history or google_ads_budget_recommendations. No exclusions or comparison with sibling tools provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly describes the output structure (campaign-level breakdown, aggregated by type, total campaigns) and prerequisites (SDK for in-app, automatic install tracking). Implies read-only nature, but does not explicitly state it as safe/read-only.
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?
Well-structured with sections (Args, Returns, Example, Notes, Conversion Categories) and front-loaded purpose. Some minor repetition (e.g., Notes restate SDK requirements from Conversion Categories), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context) and 3 parameters with no enums, the description is very complete. Covers all parameters, output structure, example usage, conversion categories, and prerequisites. No missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully. Explains each parameter: customer_id format (10 digits, no hyphens), campaign_id as optional filter, date_range with examples of valid values. Also includes an example call, making semantics clear.
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?
Clearly states 'Get detailed app conversion data by conversion type' and elaborates with specific breakdown by conversion action and category. Distinguishes from sibling read tools by focusing on app-specific conversions and listing conversion categories like App Installs, In-App Purchases, etc.
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?
Provides clear context on when to use: for understanding which conversion events drive campaign performance. Includes prerequisites in Notes (SDK integration needed for in-app conversions). However, does not explicitly compare or exclude alternatives like get_conversion_performance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It discloses that the operation is a batch creation that supports partial failure, and describes the input JSON structure and defaults. It does not mention any destructive behavior, auth needs, or rate limits, but for a creation tool this is sufficient.
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 well-structured with sections (Args, Campaign Configuration Schema, Required/Optional, Example). It is a bit longer but every sentence adds value given the complexity of the JSON parameter. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (so return details are not required), the description comprehensively covers input parameters, defaults, partial failure behavior, and provides a full example. It compensates for the missing schema descriptions and the complexity of batch creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema descriptions are missing (0% coverage), so the description must compensate. It provides detailed semantics: customer_id format (10 digits, no hyphens) and campaigns_json as a JSON array with a full schema including required/optional fields, defaults (type=SEARCH, status=PAUSED), and an example. This goes far beyond the bare 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 states 'Create multiple campaigns in a single batch operation', which is a specific verb-resource pair. It distinguishes itself from sibling tools like google_ads_create_campaign (single campaign creation) and other batch tools like google_ads_batch_create_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage and mentions partial failure, providing clear context. However, it does not explicitly state when not to use it or contrast with alternatives like sequential single creation. It also lacks prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description warns that the tool will make changes to the account and advises reviewing recommendations carefully. This is good disclosure of destructive behavior. It doesn't mention rate limits or side effects, but the warning suffices.
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 well-structured with a summary, parameter descriptions, returns, an example, common types, and a warning. Every sentence adds value, and it is concise with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and only a minimal input schema, the description provides complete context: purpose, usage, parameters, return value, example, and common types. It is sufficient for an AI agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates fully: it explains customer_id format, recommendation_type with examples and a common types list, and max_to_apply as optional. This adds significant meaning beyond the bare 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 states 'Apply all recommendations of a specific type' and distinguishes from sibling tools like 'google_ads_apply_recommendation' (single) and 'google_ads_bulk_apply_recommendations' (bulk without type filter). It includes examples of recommendation types and an example call.
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 explains when to use this tool ('bulk-applying all recommendations of a certain category') and provides common recommendation types. It also includes a warning about making changes. However, it does not explicitly contrast with similar tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that the tool applies recommendations automatically, excludes high-risk ones, and includes a warning about potential performance impact. It also describes the dry_run parameter's behavior. It could be more explicit about the mutation effect, but the description is transparent enough.
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 well-structured with a clear purpose statement, bullet-list of safe recommendations, parameter explanations with examples, and a warning. Every sentence is essential and contributes to understanding, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 parameters, output schema exists), the description covers all necessary aspects: what the tool does, what recommendations are included/excluded, how to use dry_run, and a cautionary note. The examples further clarify usage. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: customer_id format (without hyphens) and dry_run (preview vs. apply, default true). The example also demonstrates usage, adding significant value beyond the bare 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 states that the tool auto-applies low-risk, high-impact recommendations, and lists specific safe recommendations (keyword match type upgrades, responsive search ad suggestions, etc.) and explicitly excludes higher-risk ones (budget increases, bidding strategy changes). This differentiates it from other apply tools among siblings.
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 provides clear context on when to use the tool (for safe recommendations) and when not to (higher-risk recommendations should be reviewed manually). It also recommends using dry_run=True first. However, it does not explicitly name alternative sibling tools for manual review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It details the creation operation, URL pattern logic, membership duration range, and a prerequisite. It does not mention permissions or rate limits, but provides key constraints.
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 well-structured: purpose, types, args with details, return info, example, and note. Every sentence adds value without redundancy, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately includes return details ('Success message with user list ID'). All parameters are covered, and the note about remarketing tags addresses prerequisites. The example enhances completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool's description compensates fully. Every parameter is explained with examples, defaults, and format requirements (e.g., customer_id without hyphens, url_contains OR logic). An example call further clarifies usage.
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 ('Create a remarketing user list'), lists types like CRMBASED and RULE_BASED, and provides an example. It distinguishes from sibling tools focused on listing or uploading audiences.
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 explains when to use each list type and includes a note about RULE_BASED lists requiring remarketing tags. However, it does not explicitly compare with sibling tools like google_ads_upload_customer_match or google_ads_add_audience_to_ad_group.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses initialization with credentials and optional MCC ID. Could mention idempotency or error handling, but sufficient for a setup 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?
Concise, well-structured with purpose, prerequisite, args, and returns. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple initialization tool with output schema confirming status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to all 5 parameters beyond schema names, explaining each credential and the optional MCC ID.
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?
Clearly states the tool initializes the API connection and must be called before other tools. Distinguishes from siblings as a setup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it must be called before other tools and provides context for optional MCC login customer ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains that the tool retrieves data without side effects. It details the metrics returned, the optional filtering, and even mentions view-through conversions, providing comprehensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for description, args, returns, example, and metrics. Each sentence adds value; the information is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: purpose, parameters, return structure (including metrics list), and an example. Despite having an output schema, the description complements it with detailed metric explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains all three parameters: customer_id (required format), campaign_id (optional filtering), and date_range (enumerated options). Adds significant meaning beyond the bare 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 states the tool retrieves performance metrics for local campaigns, listing specific KPIs like impressions, clicks, and conversions. This distinguishes it from broader campaign performance tools among siblings.
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?
Provides an example with typical parameters and explains the purpose, but does not explicitly contrast with sibling tools like google_ads_campaign_performance. The context implies local campaign focus, which is sufficient guidance.
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 MCP server](https://glama.ai/mcp/servers/johnoconnor0/google-ads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/johnoconnor0/google-ads-mcp)

Score Badge

Copy to your README.md:

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

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/johnoconnor0/google-ads-mcp'

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