google-ads-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct targets (e.g., get_campaign_performance vs get_keyword_performance vs get_ad_performance). Two potential confusions exist: list_accessible_customers vs list_accounts (similar but descriptions distinguish them), and execute_gaql/generic_mutate overlap with all specific tools as catch-alls, but they are clearly labeled as advanced/fallback.
Naming Consistency4/5
The naming pattern is predominantly verb_noun (list_, get_, update_, add_, create_). Minor inconsistencies: remove_negative_keyword is singular while add_negative_keywords is plural, and switch_bidding_strategy, generate_keyword_ideas, execute_gaql, generic_mutate don't follow the same verb family, but the overall style is readable and predictable.
Tool Count3/5
29 tools is on the heavy side, but the Google Ads domain is broad, covering account discovery, performance reporting, insights, and mutations. Some tools are arguably redundant (get_gaql_reference, get_workflow_guide are documentation helpers, and generic_mutate covers many cases), making the set slightly bloated but not extreme.
Completeness3/5
The surface covers many important operations: listing accounts, retrieving performance across dimensions, search terms, auction insights, change history, recommendations, keyword planning, and several mutation tools (create campaign/ad group, update budgets/status/bids, add/remove keywords). However, notable gaps exist: no direct tools for listing/creating ads (e.g., responsive search ads), no ad group retrieval, and no comprehensive campaign list tool (only via GAQL or performance queries). The generic tools mitigate these gaps but imply workarounds.
Average 3.9/5 across 29 of 29 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 12, 2026
- 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 provided, the description carries the full burden of behavioral disclosure. It implies read-only behavior via 'Return' but does not mention permission requirements, rate limits, data aggregation details, or any quirks. The output schema helps but the description itself adds minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is not bloated, though it sacrifices depth for brevity. For a tool with a well-documented schema, this level of conciseness 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 presence of an output schema and full parameter documentation makes the tool minimally complete. However, the description lacks behavioral and usage context, and does not differentiate from sibling performance reporting tools. Given the abundance of similar tools, more contextual information would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptive parameter comments, including the look-back window and geo_level options. The tool description adds no additional meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns performance segmented by geographic location, distinguishing it from sibling tools like get_device_performance. It uses a specific verb ('return') and resource ('performance') with a clear qualifier, though it does not enumerate the specific performance metrics included.
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 get_device_performance or get_campaign_performance. The description provides no exclusions, prerequisites, or explicit context for choosing this tool over its 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 carries the full burden of behavioral disclosure, but it only states a read operation. It does not mention output format, pagination, data volume, or any side effects, though the schema hints at filtering options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded and efficient, but it sacrifices substantive detail for brevity.
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 good schema coverage and an output schema, the description is too brief for a tool with many similar siblings. It lacks context on use cases, metric specifics, or how it differs from other performance tools, making it incomplete for an agent to confidently select it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already described in the input schema. The description adds no additional parameter context, matching the baseline of 3 as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return keyword performance metrics' clearly states a specific action (return) and resource (keyword performance metrics), distinguishing it from sibling performance tools for campaigns, ads, geo, etc. However, it lacks explicit differentiation like which specific metrics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as get_search_terms or get_campaign_performance. The usage is only implied by the tool name and description, with no exclusions or alternative recommendations.
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 only says 'return metrics'; it does not disclose that this likely returns data for all campaigns under the customer (no campaign ID parameter), any data aggregation behavior, authentication requirements, or pagination limits. Critical behavioral traits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. Every word carries meaning; it is appropriately concise for a simple read-only metrics tool.
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 is present, so return format need not be described. However, given the rich sibling context (many performance tools), the description lacks contextual completeness around scope (e.g., all campaigns vs single campaign) and how it relates to get_pmax_performance. Still, for a basic metrics tool with full schema and output schema, 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 description coverage is 100%: each parameter (customer_id, days, login_customer_id) has a clear description in the schema. The tool description adds no extra parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and resource ('campaign performance metrics'), and scopes it with 'for the last N days'. This distinguishes it from sibling tools like get_device_performance or get_geo_performance, but it doesn't specify what metrics are included (e.g., impressions, clicks) or clarify differentiation from get_pmax_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?
The description provides no guidance on when to use this tool versus alternatives like get_pmax_performance or get_keyword_performance. There is no mention of exclusions, prerequisites, or context such as 'use for all-campaign overview' vs 'use other tools for breakouts'. Usage is only implied by the name and generic phrasing.
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 does not disclose that the tool is read-only (SELECT only), potential permissions needed, rate limits, or error handling. The behavior is ambiguous despite the word 'query'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any wasted words. It is appropriately sized for a generic tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description lacks important context: it does not mention SELECT-only semantics (though implied by schema), differences from generic_mutate, or when to consult the sibling get_gaql_reference. The broad 'any query' claim is potentially misleading without guardrails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Execute") and resource (GAQL query), clearly distinguishing it from sibling tools like get_campaign_performance or update_campaign_budget. Expanding the acronym adds 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 explicit guidance on when to use this tool vs alternatives. It does not state it is for read-only queries or that specific getter tools should be preferred for common scenarios. Only an implied general-purpose 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 bears the full burden of behavioral disclosure. It only states the basic action without mentioning that it is read-only, any required permissions, or the structure of the response. This lack of detail is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and to the point, earning a perfect conciseness score.
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?
An output schema exists, so return values are already documented. The description is minimal but sufficient for a simple getter; it doesn't mention filtering, but the schema covers that. The main slight gap is not conveying the value or variety of recommendations, though this does not detract significantly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the input schema, including the filter values. The description adds no parameter-specific meaning, but the schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns optimization recommendations for the account, using a specific verb and resource. It doesn't explicitly reference sibling tools, but the resource is distinct enough that 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or contexts where other tools would be more appropriate. It is a statement of function without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says it uses the Keyword Planner, but does not mention that it generates new keyword suggestions (as opposed to returning existing data), nor does it mention any rate limits, authentication requirements, or that it is 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 a single, concise sentence that front-loads the primary action. There is no fluff or redundant information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity with 6 parameters and an output schema. The description is minimally viable but lacks usage context and behavioral details. However, the rich schema and output schema compensate somewhat, as they define valid inputs and return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for all parameters, so the baseline is 3. The description adds no parameter-specific meaning, but the schema already explains keywords, page_url, language_id, and geo_target_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 the verb 'Generate' and the resource 'keyword ideas,' and specifies the method 'Google Ads Keyword Planner.' This distinguishes it from sibling tools like get_keyword_performance or add_keywords, which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as having a seed keyword or page URL, nor does it clarify that it is for ideation rather than querying existing performance data.
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 for behavioral disclosure. It only says 'Return' and describes the output content, but it does not mention functional traits like required permissions, data freshness, rate limits, or any caveats. For a 'get' tool this is lower risk, but the lack of operational context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly states the core function, and then lists relevant use cases. Every word adds value, and there is no verbose or 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?
An output schema exists, so return values do not need to be explained. The description covers purpose and use cases, which is sufficient for a read-only tool with a simple parameter set. It could be more complete by noting prerequisites or data delivery specifics, but it is adequately contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (customer_id, days, login_customer_id) already have clear descriptions. The tool description adds no additional parameter-level meaning, so it lands at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return ad-level performance including RSA headlines and descriptions.' This specifies both the resource (ad-level performance) and the distinguishing detail (RSA headlines/descriptions), setting it apart from sibling tools like get_campaign_performance or get_keyword_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 gives explicit use cases: 'creative audits, A/B analysis, and identifying low-performing ad copy that should be refreshed.' This implies when to use it, though it does not explicitly name alternatives or exclusions. That is strong guidance for a performance-focused tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It implies a read-only report ('Return') but does not explicitly state safety, data freshness, pagination, or any side effects. The lack of such detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The main purpose is front-loaded, and the use cases follow concisely.
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 return values need not be described. The description provides valuable context for when to use the tool, and the schema handles parameter details. However, no mention of read-only behavior could be noted, but given the tool's simplicity and output schema, it is reasonably 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 covers all four parameters with descriptions (100% coverage). The description does not add parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'search term performance — actual queries that triggered your ads,' which is a specific verb and resource. It distinguishes from sibling tools like get_keyword_performance by emphasizing actual search queries versus keywords.
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 lists use cases: SQR, negative keyword opportunities, and new keyword candidates. While it does not mention alternatives or when not to use, the use cases provide clear context for when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing safety behavior. It does disclose that the tool defaults to a dry run and requires confirm=True to execute, which is critical for preventing unintended changes. However, it does not cover other behavioral aspects like permissions or reversibility, but the key safety behavior is well highlighted.
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 two sentences, front-loaded with the core action and immediately followed by the important dry-run behavior. No filler or redundancy, making it highly efficient for an agent 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 rich input schema with 100% coverage and the presence of an output schema, the description's brevity is acceptable. It provides the essential behavioral context (dry run) that is not in the schema. It could have summarized conditional parameter relationships, but the schema already handles that, so the description is sufficiently complete 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?
The input schema provides 100% coverage with detailed descriptions for all parameters, including conditional dependencies such as target_cpa for TARGET_CPA and max_cpc_limit for MAXIMIZE_CLICKS. The description adds no extra parameter semantics, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Change a campaign's bidding strategy.' It identifies a specific action and resource, distinguishing it from sibling tools like update_campaign_budget or update_campaign_status. The dry-run note adds clarity about execution behavior, reinforcing 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?
The description provides no explicit guidance on when to use this tool versus alternatives, such as update_campaign_budget or create_campaign. It does not mention any exclusions or prerequisites, leaving the agent to infer usage solely from the action verb.
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 explicitly discloses the dry-run behavior and preview, which is a critical safety trait. It also indicates that confirm=True executes. This is valuable, though it doesn't elaborate on the preview contents or other 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 exactly two sentences, with the purpose front-loaded and the safety behavior in the second sentence. No wasted words.
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 rich input schema and the presence of an output schema, the description is adequate. It explains the critical dry-run mechanism, and the schema covers parameters. It does not need to explain return values due to the output schema, but it could mention permissions or preview contents; still, it is sufficiently complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all five parameters, including the keywords dict structure. The description adds no additional parameter-level information beyond what the schema states, so it does not exceed the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Add keywords to an ad group.' This is specific about the resource (keywords) and target (ad group), and the tool name distinguishes it from siblings like add_negative_keywords, even though the description doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear execution guideline: 'Default is DRY RUN — shows preview. Pass confirm=True to execute.' However, it does not provide any guidance on when to use this tool versus alternatives such as add_negative_keywords or update_keyword_bid, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly reveals that the tool defaults to a dry-run preview and requires confirm=True to execute, which is a critical safety behavior not obvious from the name or schema. This adds significant transparency, though it does not mention potential side effects like irreversible changes or permission 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 extremely concise, containing only two sentences. It front-loads the primary purpose and then states the key execution nuance. Every word earns its place, and there is no redundancy or filler.
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 essential behavioral nuance (dry-run) while the schema and output schema handle parameter details and return values. The tool is relatively simple, and the description is sufficient for basic usage. However, it does not mention potential limitations like supported match types or how the preview appears, which could be inferred from schema and output schema but are not explicitly stated. Still, completeness is adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all six parameters, including the confirm flag, match_type, and keywords format. The tool description adds no additional parameter semantics beyond what the schema already documents. Therefore, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add negative keywords to a campaign.' This is a specific verb+resource combination that distinguishes it from sibling tools like add_keywords (positive keywords) and remove_negative_keyword. The scope is clear without ambiguity.
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 the dry-run default and confirm=True to execute, which is useful operational guidance. However, it does not explicitly state when to use this tool over alternatives (e.g., add_keywords or remove_negative_keyword), nor does it provide exclusions or contextual triggers. Usage is implied rather than explicitly differentiated.
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 discloses the core behavior (returning competitive metrics) and adds context about 'competing domains' and 'where your ads appear relative to competitors'. However, it does not mention read-only status, data aggregation, permissions, or limitations, leaving some behavioral traits implicit.
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 two sentences, front-loaded with the action and key metrics, with no redundant phrasing. Every word 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?
For a read-only analytics tool with an output schema, the description covers the core purpose, metrics, and competitive context. It does not elaborate on optional filters (days, campaign_id), but those are fully described in the schema. The description is complete for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no parameter-specific context beyond naming the high-level purpose, which is acceptable given the schema's completeness.
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: 'Return competitive auction insights' and lists specific metrics (impression share, overlap rate, position above rate, outranking share). It also positions itself as 'the primary competitive intelligence tool', distinguishing it from siblings like get_impression_share and get_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by labeling this as the primary competitive intelligence tool, implying it is the go-to for competitive insights. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Return' but does not mention permissions, data freshness, or any side effects. 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 two concise sentences that front-load the purpose and immediately provide a practical use case. Every word is useful, with no redundancy or filler.
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 a fully documented input schema (100% coverage) and an output schema, so the description does not need to explain return values. It adds context through the use-case statement, which helps the agent place the tool in a workflow. It is complete for this tool's complexity, though it could briefly mention any prerequisites 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 input schema already provides complete descriptions for all three parameters (customer_id, days, login_customer_id), so the description adds no additional parameter semantics. The description's focus on device segmentation is unrelated to parameter-level details, so it does not go 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 'Return campaign performance segmented by device' and explicitly names the device types (MOBILE, DESKTOP, TABLET). This distinguishes it from sibling tools like get_geo_performance and get_campaign_performance, which focus on different breakdowns.
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 an explicit use case: 'identify bid adjustment opportunities and diagnose mobile vs. desktop conversion rate gaps.' This gives clear context for when to use the tool, though it does not explicitly mention alternatives 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.
Behavior4/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 discloses the core behavior: it shows the percentage of eligible impressions won and distinguishes lost reasons (budget vs. ad rank). This goes beyond the tool name and provides meaningful context about the output's meaning, though it does not cover aspects like data aggregation 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 three sentences, each serving a purpose: the first states what it returns, the second explains the meaning of the metrics, and the third highlights its strategic importance. It is concise, front-loaded, and contains no filler or redundant phrasing.
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 (so return values are already documented), the description adequately covers the tool's purpose and behavioral nuance. It explains the strategic value and what the metrics indicate. It could be more complete by mentioning how the 'days' parameter affects results or any prerequisites, but for a read-only reporting tool, it is sufficiently 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?
Input schema coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details beyond what the schema already documents (e.g., days, customer_id, login_customer_id). It mentions 'by campaign' which hints at grouping but does not elaborate on parameter 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 uses a specific verb ('Return') and clearly identifies the resource ('search impression share and lost IS reasons by campaign'). It distinguishes itself from sibling performance tools by focusing on impression share and lost reasons, which is a unique angle compared to tools like get_auction_insights or get_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 a use case ('Critical for scaling decisions') but does not explicitly state when to use this tool versus alternatives like get_auction_insights or get_campaign_performance. There is no exclusion criteria or named alternative, so it only provides implied usage context.
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?
Without annotations, the description carries full burden. It discloses the critical dry-run default and the need for confirm=True to execute. This goes beyond the schema by clearly framing the safety behavior as the default, which is valuable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the purpose, the second explains the critical execution workflow. Every word 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 presence of an output schema and 100% parameter coverage, the description is sufficient. It highlights the dry-run/execute mode, which is the key workflow consideration. It doesn't need to explain return values or parameter details as those are already structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; even the confirm behavior is duplicated from the parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action: 'Update the CPC bid for a specific keyword.' This clearly distinguishes it from sibling update tools like update_campaign_budget or update_ad_group_status, which target different resources.
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: use this tool to update a keyword's CPC bid. However, it provides no explicit guidance on when to choose this over alternatives like switch_bidding_strategy or generic_mutate, nor any 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 carries the full burden. It accurately conveys the read-only nature ('Return') and the scope of data, but doesn't disclose potential limitations (e.g., whether changes are limited to certain resource types by default, whether there is any delay in data availability, or if special permissions are needed). This is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose and valuable context. No filler or repetition. Every sentence earns its place.
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 output schema exists, so return values are covered. The description explains the core behavior and gives practical use cases. For a read-only history tool with excellent schema coverage, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters with descriptions and defaults. The tool description adds no additional parameter-specific context beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('account change history') and clearly explains what information is provided ('who changed what, when, and what it changed from/to'). This distinguishes it from all sibling tools, none of which mention change history.
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: 'audits, debugging performance drops, and tracking unauthorized changes.' While it doesn't explicitly exclude alternatives or name conditional alternatives, it gives strong contextual guidance on when to invoke 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. It discloses the critical safety behavior: default is a dry-run preview, and confirm=True executes. This is essential for a mutation tool and goes beyond the schema by emphasizing the two-step execution model. It doesn't cover permissions or reversibility, but the main risk is adequately addressed.
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 two short sentences: first states the primary purpose, second explains the dry-run behavior. Every word earns its place, with no redundancy or filler.
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 is adequate for a 7-parameter tool with 100% schema coverage and an output schema. It covers the essential non-schema context: the dry-run default and confirmation requirement. It doesn't discuss prerequisites or operational effects, but these are either implied by 'create' or covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's mention of confirm=True matches the schema's confirm field but adds no additional meaning to other parameters (name, status, campaign_id, etc.). It doesn't explain parameter relationships or prerequisites beyond what the schema already provides.
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 'Create a new ad group within a campaign' — a specific verb (create) with a clear resource (ad group) and scope, distinguishing it from sibling tools like update_ad_group_status or add_keywords. The purpose is immediately obvious 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 gives clear context: it creates an ad group and the dry-run/confirm execution pattern. It doesn't explicitly state when to use it vs alternatives, but no competing creation tool exists among siblings, and the context is sufficient to infer proper use.
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 takes on the full burden of disclosure. It clearly states the dry-run behavior and the paused-by-default guarantee, which are critical safety traits. While the schema already conveys the confirm and status defaults, the description reinforces them as operational rules rather than mere defaults.
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, front-loaded with the core purpose, and then provides the two most important usage caveats in just two short paragraphs. Every sentence earns its place with no redundancy or filler.
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 13 parameters and an output schema, the description does not need to explain every detail. It covers the non-obvious behaviors (dry run, paused default) that could lead to mistakes. The platform context is provided in the schema's customer_id field, so overall this is sufficiently 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 100% for all 13 parameters, so the baseline is 3. The description mentions confirm and status, but these are already fully described in the schema; no additional parameter-level meaning is added.
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 opens with 'Create a new campaign', which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like update_campaign_status or create_ad_group by targeting the campaign entity itself.
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 explicit usage context: dry run by default, confirm=True to execute, and the requirement to set status='ENABLED' explicitly for an active campaign. It does not name alternative tools, but the creation intent is clear and distinct from the update-oriented 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?
No annotations are provided, so the description carries the full burden. It discloses the critical behavioral trait that the tool is dry-run by default and only executes with confirm=True, which is valuable and beyond the schema. Does not describe API response, but an output schema is present.
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?
Two sentences, front-loaded with purpose and then the key usage caveat. Every word earns its place 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?
The tool name and schema fully cover parameters, and an output schema exists. The description adds the essential dry-run default, making it complete for a status update tool. Could elaborate on preview content, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the confirm parameter behavior (dry-run vs execute), but this is already in the schema's description for confirm. It adds little beyond what the schema provides.
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 'Pause or enable an ad group' with a specific verb and resource, clearly distinguishing it from sibling tools like update_campaign_status and update_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: default is dry run, pass confirm=True to execute. It does not explicitly name alternatives, but the tool name and sibling list make the intended use obvious. Lacks explicit exclusions or alternatives but enough guidance for selection.
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 carries the full burden of behavioral disclosure. It does an excellent job by revealing the safety-critical behavior: 'Default is DRY RUN — shows preview. Pass confirm=True to execute.' This tells the agent that the tool is non-destructive by default and requires explicit confirmation to mutate. The description only lacks details on response outcomes or permissions, but the dry-run disclosure is the most important behavioral trait.
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 two sentences: the first states the core purpose, and the second provides essential execution behavior. It is front-loaded, direct, and contains zero filler. Every word 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 tool's moderate complexity (mutation with a dry-run safeguard) and the presence of an output schema (so return values need not be described), the description covers the essential behavior: what it does and how to execute it safely. It could mention prerequisites (e.g., accessible customer_id) or edge cases, but for a simple budget update, the description is sufficiently 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 100%, so every parameter is already documented in the input schema. The description's mention of the dry-run behavior and confirm=True is redundant with the confirm parameter's schema description ('Set True to execute. Default False (dry run).'). Thus, the description adds no meaningful information beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Update a campaign's daily budget') with a clear verb, resource, and field. It distinguishes this tool from siblings like update_campaign_status and update_keyword_bid by specifying 'budget' as the target.
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 for when to use this tool (updating a campaign budget) and the critical dry-run vs. execute behavior. It stops short of explicitly naming alternatives or exclusions, but the clarity of the purpose makes the usage obvious.
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 transparency burden. It clearly discloses the dry-run default and the need to pass confirm=True for execution, which is a key safety behavior. It does not detail side effects, but the 'execute' wording implies the actual 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, and no redundant information. Every word 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 a 100% schema coverage and an output schema, the description only needed to add the dry-run safety mechanism, which it does. It could mention permissions or irreversibility, but the dry-run disclosure sufficiently completes the picture for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% documentation coverage for all parameters. The description reiterates the dry-run/confirm behavior that is already in the schema, adding minimal new meaning beyond what the schema provides.
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: 'Pause or enable a campaign.' This is a specific verb+resource combination that distinguishes it from sibling tools like update_campaign_budget or update_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for usage by specifying the action (pause or enable) and the critical dry-run default with confirm=True execution. It does not explicitly contrast with alternatives, but the resource and action make the intended use obvious.
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 carries the transparency burden. It discloses the return contents ('daily budget amounts alongside 30-day cost') and the analytical purpose, establishing it as a read-only analysis tool. It does not mention permissions or rate limits, but these are less critical for a non-mutating summary 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 two sentences: the first states the core function, and the second elaborates on output and purpose. It is front-loaded with the verb and resource, containing no redundant or filler language.
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?
With an output schema present and 100% parameter coverage, the description sufficiently covers purpose, return contents, and when to use the tool. It fully supports a simple read operation with no apparent gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both customer_id and login_customer_id. The description adds no extra parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return campaign budgets and current spend' with a specific verb and resource, and adds the analytical purpose 'budget pacing analysis' and expected outcome 'identify budget-constrained campaigns or overspending.' This distinguishes it from sibling tools like update_campaign_budget, which handles mutations.
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 context through 'for budget pacing analysis' and 'to help identify budget-constrained campaigns or overspending,' giving clear direction on when to apply the tool. It does not explicitly mention alternatives or exclusions, but the read-only nature is obvious relative to mutation siblings like update_campaign_budget.
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 of behavioral disclosure. It discloses that the tool fetches both campaign and asset-group performance and explains the underlying query limitation, which is valuable context for users. However, it doesn't discuss other behaviors like pagination, delays, or authentication requirements, leaving some gaps.
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 two concise sentences that front-load the primary purpose and add a brief, relevant explanatory note. Every sentence earns its place, and there is no fluff or 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 the existence of an output schema and full parameter descriptions, the description adequately covers the tool's purpose and the unique separate-query behavior. It provides enough context for an agent to understand when to use this tool and what to expect, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters with clear descriptions (e.g., days, customer_id, login_customer_id). The description text adds no additional parameter-specific semantics, but the schema already handles this thoroughly, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Performance Max campaign and asset group performance,' using a specific verb and resource. It distinguishes itself from sibling tools like get_campaign_performance and get_keyword_performance by explicitly targeting PMax data at both campaign and asset-group levels.
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 PMax data requires separate queries for campaign-level and asset-group-level metrics, which provides context for when this tool is appropriate. It doesn't explicitly mention alternatives or when not to use it, but the rationale suggests it's the dedicated tool for PMax performance data.
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 of behavioral disclosure. It states the return format ('structured dict with account metadata'), explains MCC traversal depth, and clarifies that only 'accessible' accounts are listed. This adds meaningful insight beyond the tool's name.
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 overall, with the main purpose stated first and a clear recommendation. The inclusion of the source and implementation note ('Source: ...') adds minor noise but does not detract significantly from 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 core functionality, return format, traversal depth, and a clear use case. With an output schema present, this is largely sufficient. However, it does not differentiate the tool from the similar sibling list_accessible_customers, which is a small 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?
The tool has zero parameters, so the baseline of 4 applies per the rubric. The input schema is empty, and the description correctly focuses on behavior rather than parameter details, which are unnecessary here.
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 action ('List all accessible Google Ads accounts'), the resource ('Google Ads accounts including MCC sub-accounts'), and adds specific scope ('up to two levels deep'). This distinguishes it from reporting tools and provides a concrete verb+resource structure.
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 gives explicit usage context: 'Recommended first step: run this to discover available customer IDs before calling any reporting tools.' However, it does not mention when to avoid this tool or compare it to the sibling list_accessible_customers, which might serve a similar purpose.
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 carries the full burden of behavioral disclosure. It discloses the critical dry-run default and the need for confirm=True to execute, which is essential safety information. However, it doesn't mention permissions, reversibility, or error handling, so it's not fully 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 three sentences, each serving a distinct purpose: statement of purpose, usage condition, and execution behavior. It is front-loaded and contains no filler or repetition.
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 generic advanced tool with many parameters and nested objects, the description covers purpose, usage, and key behavior (dry-run). The output schema covers return values. The proto-structure requirement sets appropriate expectations. It could add a brief example, but the schema mitigates that need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with descriptions for all 7 parameters. The description adds no parameter-specific meaning beyond the general reference to 'API proto structure,' so it doesn't enhance the schema's semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a generic mutate operation for resource types lacking dedicated tools ('...not covered by specific tools'). It uses a specific verb ('modify') and resource ('resource type') and distinguishes it from sibling-specific write tools by stating its intended niche.
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 when to use: 'Use this when you need to modify a resource type that doesn't have a dedicated write tool' and implies when not to (if a dedicated tool exists). Also notes a prerequisite: 'Requires understanding the Google Ads API proto structure.'
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 indicates this is a reference lookup (read-only in nature) and adds useful context about avoiding common errors. It doesn't explicitly state it is read-only, but the phrase 'reference guide' strongly implies no side effects, and the source note adds credibility.
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-loaded with the main purpose, and uses three clear sentences. The source attribution line is slightly extraneous but acceptable; the overall structure is efficient and scannable.
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?
For a simple reference tool with zero parameters and an output schema available, the description is complete. It explains what, when, and why, and the output schema covers return details. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description doesn't need to explain parameters; the baseline for 0 parameters is 4, and the description adds no unnecessary parameter-related noise.
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 returns a GAQL reference guide, with a specific verb and resource. It distinguishes itself from sibling tools like execute_gaql by describing its role as a pre-query reference, and it explicitly mentions preventing common GAQL errors.
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?
It explicitly instructs to call before writing complex queries and explains the benefits (correct field names, operators, resource relationships). It does not explicitly mention exclusions or alternative tools, but the context makes the appropriate usage clear.
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 carries the burden of behavioral disclosure. It clearly highlights the dry-run default (shows preview) and that confirm=True is required to actually execute, which is a critical safety behavior. It doesn't discuss irreversibility or permissions, but the dry-run mitigation adds substantial 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?
Three short sentences, each carrying essential information. The action is front-loaded, and there is zero filler or repetition. It is a model of concise, structured tool documentation.
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 core action, how to obtain the identifier, the dry-run safeguard, and the execution path. An output schema exists, so return values don't need description. It could mention permission requirements, but for a single-purpose removal tool, 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?
Schema coverage is 100% with parameter descriptions already present. The description adds value by explaining that resource_name should come from get_search_terms or execute_gaql, and by clarifying the confirm parameter's dry-run vs. execute behavior. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and clearly identifies the resource ('negative keyword') and the method ('by resource name'). It distinguishes from the sibling tool 'add_negative_keywords' and gives context on obtaining the resource_name.
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 guidance on how to get the required resource_name (via get_search_terms or execute_gaql) and explains the dry-run default with confirm=True to execute. It doesn't explicitly state when not to use this tool or mention alternatives, but the context is clear and actionable.
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 of behavioral disclosure. It explains that the tool returns a step-by-step guide and lists the sequence of steps. It does not mention side effects, but for an informational guide with zero parameters, the behavior is fully transparent. It could add a note that it performs no data modifications, but the nature of the tool makes this implicit.
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, using only two sentences. It front-loads the purpose ('Return the recommended workflow') and then provides the key steps and usage context. Every sentence earns its place with no fluff or 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 the tool has zero parameters and an output schema exists, the description is complete. It explains what the tool does, the workflow steps, and when to use it. The output schema likely details the structure of the guide, so no further return-value description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Therefore, the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description adds no param-specific details, which is acceptable.
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 returns a recommended workflow for using Google Ads MCP tools, with a specific verb ('Return') and resource ('recommended workflow'). It distinguishes itself from sibling tools by being a meta-guide rather than a data operation, and explicitly outlines the workflow steps.
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 a clear usage context: 'Good first call when starting a new analysis session.' This tells the agent when to invoke it. It does not explicitly mention alternatives or when-not-to-use, but the guidance is specific enough for a meta-tool that is clearly distinct from the operational 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?
With no annotations provided, the description carries the full burden. It discloses that the operation returns directly accessible IDs (read-only), implies authentication requirements ('authenticated user'), and clarifies scope limitations. It also adds implementation context about using the Python client library. However, it does not mention potential errors or pagination, though these are partly covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is generally concise. However, the final sentence about the source and Python client library is arguably extraneous for tool selection/invocation, making it slightly less tight than a perfect 5.
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 of the tool (no params, output schema present), the description is complete: it states purpose, usage, alternatives, and how the output connects to other tools. The output schema handles return format details, so no further structural explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per rubric. The description adds semantic value by explaining that the output can be used as a `customer_id` elsewhere, which is helpful for the agent. This goes beyond the empty schema and justifies a score at the baseline.
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 opens with a specific verb and resource: 'Return customer IDs directly accessible by the authenticated user.' It clearly distinguishes itself from the sibling tool list_accounts by noting that MCC managers should use list_accounts for child accounts, making the tool's scope unambiguous.
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?
It explicitly states that the returned IDs can be used as the `customer_id` parameter across all other tools, and provides a direct alternative: 'For MCC (manager) accounts, use list_accounts() to also see child accounts.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/itallstartedwithaidea/google-ads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/itallstartedwithaidea/google-ads-mcp)

Score Badge

Copy to your README.md:

[![google-ads-mcp MCP server](https://glama.ai/mcp/servers/itallstartedwithaidea/google-ads-mcp/badges/score.svg)](https://glama.ai/mcp/servers/itallstartedwithaidea/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/itallstartedwithaidea/google-ads-mcp'

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