google-ads-mcp

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct aspect of Google Ads (account info, campaign performance, keyword performance, asset management, etc.). Even related tools like campaign_performance and ad_group_performance are clearly differentiated by level. No two tools appear to serve the same purpose.
Naming Consistency4/5
All tools share the 'gads_' prefix and use lowercase with underscores. The naming follows a descriptive phrase pattern (e.g., gads_campaign_performance, gads_rsa_asset_performance). While not strictly verb_noun, the convention is consistent and readable.
Tool Count5/5
22 tools is well-scoped for a comprehensive Google Ads server. It covers listing entities, performance reports across dimensions, conversion analysis, budget pacing, auction insights, and an escape hatch. Each tool earns its place without overwhelming the user.
Completeness4/5
The tool set covers most common reporting and listing needs (campaigns, ad groups, keywords, assets, audiences, conversions, etc.). Missing write operations (create/update/delete) but these are often out of scope for a reporting-focused MCP server. The GAQL escape hatch compensates for any missing report shapes.
Average 3.5/5 across 22 of 22 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose default filtering behavior (status=ENABLED while claiming 'all'), permissions needed, or pagination. Contradicts itself on scope.
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?
Single sentence, front-loaded with action. But 'all' is misleading given the default status filter, reducing accuracy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter explanations, the description is insufficient for correct usage. Additional context about parameter roles and default behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the two parameters (customer_id, status). The status enum is not mentioned; the output fields listed are not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all conversion actions and specifies the returned fields (name, category, type, etc.), distinguishing it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., conversion performance tools). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states a read operation with output fields, omitting details on permissions, data freshness, filtering, or side effects. This is minimally 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?
A single, well-structured sentence that front-loads the action and includes key specifics. Every word adds value, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description partially covers return fields but lacks pagination details (despite the limit parameter), sorting, or filtering. Without an output schema, more completeness would help, but it's adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; only customer_id has a description. The tool description adds no parameter semantics beyond the schema, failing to explain the limit parameter or how parameters affect behavior.
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 'List' and the resource 'user lists' with specific examples (remarketing audiences, customer match lists). It also mentions key output fields (size, eligibility, match rate), making the tool's purpose distinct from siblings like gads_list_accounts or gads_list_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as gads_campaign_audience_targeting. It does not mention prerequisites, exclusions, or recommended contexts, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only via 'list' but does not explicitly state safety, permissions, or scope (e.g., whether it returns all budgets for a customer or account).
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?
Single sentence conveys core information efficiently. Slightly dense but not overly long; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description lists return fields, which is helpful. However, it omits return type (array/object), pagination, and filtering options, leaving gaps for a list endpoint.
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% for the single parameter (customer_id), but description adds no semantics beyond the schema's 'Override GOOGLE_ADS_CUSTOMER_ID'. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists campaign budgets with specific fields (daily/total amount, delivery method, period, recommended budget). It distinguishes from sibling gads_budget_pacing by listing unique return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like gads_budget_pacing or gads_list_campaigns. Agent must infer use case from field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states it lists campaigns with certain fields. It does not disclose pagination behavior, authentication needs, rate limits, or what happens when limit is exceeded.
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?
Two sentences with no fluff, but could be more efficient by omitting the date range mention if it's not a parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, and low parameter coverage, the description lacks information on return format, error handling, or precondition (e.g., account selection via customer_id).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (status described). The description adds value for status (default ENABLED) but does not explain customer_id or limit, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List campaigns' with specific fields (name, status, channel type, bidding strategy, date range), effectively distinguishing it from sibling tools like gads_list_accounts or gads_list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like gads_campaign_performance. The description implies filtering by status but does not compare with other campaign-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description carries the burden but only mentions defaults and optional filters. It does not disclose read-only nature, pagination, or any side effects, though it provides some behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no redundancy. Every word adds value, stating the core purpose, optional filter, and defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It fails to explain return fields, metrics included, or how 'campaign context' is presented, which is essential for a performance report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 83% coverage for 6 parameters; description adds little beyond summarizing defaults and the campaign_id filter. Baseline is appropriate as the schema already explains most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Ad group performance with campaign context' and specifies optional filters and defaults. It distinguishes from siblings like 'gads_campaign_performance' by focusing on ad group level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool versus alternatives. No when-to-use or when-not-to-use scenarios are mentioned, and no sibling differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It does not mention data freshness, permissions, rate limits, or side effects. It only lists returned metrics, lacking needed transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence effectively communicates the tool's output. Could be slightly improved by front-loading key info, but current structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with schema covering all params. Missing details about return format (e.g., rows, columns) and potential grouping. Though no output schema exists, description should clarify what the report structure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage on parameter descriptions. Description adds 'Optional campaign filter' which is already documented in the schema. No additional semantic value 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?
Description explicitly states the tool returns Auction Insights report with specific metrics (impression share, overlap rate, outranking share, top-of-page %, absolute top %) and an optional campaign filter. This clearly distinguishes it from sibling tools like gads_impression_share or gads_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It simply states what it does, leaving the agent to infer usage context from the metrics listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses default time range and sorting order, but does not state that it is a read-only operation, auth requirements, or potential data latency. The behavior is implicitly safe but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence plus additional notes. It is front-loaded with the purpose. However, it could be slightly more structured by separating parameter info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters and no output schema, the description is incomplete. It lacks details on return format, parameter specifications, and usage context, which are needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only hints at start_date/end_date defaults via 'Default last 28 days', but does not describe customer_id, limit, or the meaning of the fields. This leaves significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves conversions and conversion value broken down by campaign and conversion action, with sorting by conversions descending. This distinguishes it from sibling tools like gads_campaign_performance or gads_keyword_performance, which do not include the conversion action breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies its use case by specifying the breakdown, but lacks guidance on when not to use it or how it differs from other performance reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as data freshness, pagination behavior, sorting, or how top/bottom segments are determined. Minimal beyond schema.
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, direct and clear. No unnecessary words. Front-loaded with essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is too brief. Lacks details on output structure, interpretation of segments, and how limit affects results. Incomplete for a performance report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters described). Description adds context that output includes top/bottom segments by cost and conversions, which is not in schema. Baseline 3 with minor added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides performance broken down by geographic location and mentions specific metrics (cost, conversions) and segments (top/bottom). This distinguishes it from sibling tools like device or campaign performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for geographic performance analysis, but no explicit guidance on when to use versus alternatives or when not to use. Does not mention limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says the tool lists assets and can filter by type, but omits details like pagination behavior, return format, data freshness, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence. It front-loads the verb and resource. Could be slightly longer to include usage guidance without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and sibling tools like gads_campaign_assets, the description provides the basic purpose but lacks supplementary info like default behavior when no filter is applied or expected output 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?
Schema coverage is 100% (all three parameters have descriptions), so the description adds little beyond the schema. It mentions filtering by asset type, but that is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists account-level assets, provides examples (sitelinks, callouts, etc.), and the 'account-level' distinction sets it apart from the sibling gads_campaign_assets, which presumably deals with campaign-level assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for account-level assets, which implicitly differentiates from campaign-level tools, but it does not explicitly state when to use this tool over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It describes the output fields but does not mention that the operation is read-only, nor does it cover authentication requirements, rate limits, or potential side effects. The description is insufficient to fully inform the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action ('List Responsive Search Ads') and conveys the key features concisely. It avoids unnecessary detail, making it efficient for an AI agent 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 description lists the fields returned (headlines, descriptions, Ad Strength, approval status) but does not explain pagination, ordering, or the absence of an output schema. For a tool with a `limit` parameter, pagination details would enhance completeness. The description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for 3 out of 4 parameters (customer_id, campaign_id, ad_group_id, limit) with coverage at 75%. The tool description only repeats the filtering concept from the schema, adding no new semantic meaning. Baseline score of 3 is appropriate given the 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 clearly states 'List Responsive Search Ads' with specific fields (headlines, descriptions, Ad Strength rating, approval status) and filtering options. It effectively distinguishes from sibling tools like gads_list_assets or gads_rsa_asset_performance by focusing on RSAs.
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 filtering by campaign or ad group, which gives some usage context, but it does not explicitly state when to use this tool versus alternatives like gads_campaign_assets or gads_rsa_asset_performance. The usage guidelines are implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description fully bears the transparency burden. It states the tool outputs performance labels but does not disclose behavioral traits such as data freshness, rate limits, authentication requirements, or whether the operation is read-only. The description is minimal beyond purpose.
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, efficiently conveying the core function and value. Every word contributes to understanding, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not detail the return format or structure of the asset labels. It provides a high-level interpretation guide ('keep, test, or replace') but lacks specifics on how the data is returned, which may limit agent understanding for programmatic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter descriptions are fully provided in the schema. The tool description does not add additional meaning or context to the parameters beyond their definitions, resulting in no incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides asset-level performance labels (BEST/GOOD/LOW/PENDING/LEARNING) for RSA headlines and descriptions, specifying the purpose of identifying which assets to keep, test, or replace. It distinguishes itself from siblings like gads_list_assets by focusing on performance labels rather than listing assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing RSA asset performance labels, but does not explicitly state when to use this tool versus alternatives like gads_keyword_performance or gads_ad_group_performance. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it gets info, lacking details on side effects, permissions, rate limits, or error conditions. While it is read-only by nature, more transparency (e.g., authentication requirements) would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. Every word adds value, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description helpfully lists the returned fields (name, currency, timezone, etc.). It lacks error handling or edge cases, but for a simple read-only tool, this is mostly adequate. Sibling context is provided but not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single optional parameter (customer_id) with a clear description. The tool description adds no further parameter meaning beyond listing returned fields. Schema coverage is 100%, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'basic info for the current Google Ads account', listing specific fields (name, currency, timezone, manager flag, status). This distinguishes it from sibling tools like gads_list_accounts which likely list multiple accounts rather than the current one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving basic account info but provides no explicit guidance on when to use this tool versus alternatives (e.g., gads_list_accounts for multiple accounts, or other performance tools). No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions flagging over- and under-pacing but does not clarify whether the tool is read-only, what thresholds are used, or any side effects. The safety profile is unclear.
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 with no redundant words, front-loaded with the key output. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return (cost vs budget, utilization, flags). It could mention whether results are per campaign or aggregated, but is mostly complete for a reporting 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?
Input schema covers all 3 parameters with descriptions. The description adds minor value by stating 'Default last 28 days', which is already implicit in the schema defaults. No additional meaning beyond 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 compares cost vs budget per campaign, calculates utilization percentage, and flags over- and under-pacing. This specific verb+resource combination distinguishes it from siblings like gads_campaign_performance or gads_list_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for budget pacing analysis with a default period, but does not explicitly state when to use this tool versus siblings or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation (shows lists) and details the returned fields (targeting setting, bid modifier, inclusion/exclusion). However, it does not mention what happens if parameters are omitted, error handling, or any side effects. This is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose and key output details. It is front-loaded and does not include redundant information, though it could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values adequately. It mentions audiences, targeting setting, bid modifier, and lists (inclusion/exclusion), which provides a good overview. However, it does not specify whether results are scoped to all campaigns or require a campaign_id, nor does it detail the format or additional fields like audience names or IDs. This leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (customer_id and campaign_id) are described in the schema with clear purposes. The description does not add new meaning beyond the schema, but since schema coverage is 100%, a baseline of 3 is appropriate. No additional constraints or formatting details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves audiences attached to campaigns, specifying the targeting setting (observation vs targeting) and bid modifier, and mentions both inclusion and exclusion lists. It distinguishes itself from sibling tools like gads_list_audiences which likely list all audiences, and gads_list_campaigns which list campaigns, by focusing on the campaign-audience association with additional details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It is adequate but lacks explicit when-to-use or when-not-to-use context, relying on the user to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only labels the tool as an 'escape hatch' and includes a link to documentation, but does not disclose behavioral traits like error handling, rate limits, or potential complexity. This is insufficient for a raw query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a link. Every part is essential. Front-loaded with 'Escape hatch' and purpose, immediately followed by usage guidance and a reference to external documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more behavioral and result context. It lacks details on query constraints, output format, or error handling. The brief description is insufficient for an unannotated tool of this nature.
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 covers both parameters (query and customer_id) with descriptions, achieving 100% schema coverage. The description adds no additional semantic information beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it runs any raw GAQL query against Google Ads, with clear verb and resource. Differentiates from sibling tools by calling it an 'escape hatch' for when preset tools don't cover the report shape, making its unique purpose clear.
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 context: 'Use when preset tools don't cover the report shape you need.' This tells when to use it, but does not specify when not to or list alternative tools by name. The sibling list implies alternatives, but the description could be more explicit.
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 provides defaults and filters but lacks disclosure of read-only nature, rate limits, or behavior when no filters are applied. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists metrics but does not explain return structure or pagination. Adequate for basic usage but leaves gaps for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to defaults (last 28 days, enabled keywords) and mentions filter parameters, but with 29% schema coverage, it does not fully compensate for undocumented params like limit or customer_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Keyword-level performance' and lists specific metrics (match type, quality score, clicks, cost, conversions), distinguishing it from sibling tools like gads_campaign_performance or gads_ad_group_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 mentions filtering by campaign_id or ad_group_id and defaults, but does not explicitly guide when to use this vs alternatives (e.g., gads_search_terms_report) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes the tool's output (assets with field type and status, extensions) but does not disclose any behavioral traits such as authentication requirements, rate limits, or potential side effects. For a read-only listing, the description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of only two sentences. The first sentence states the main purpose, and the second adds a clarifying detail about extensions. Every word contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (listing assets linked to campaigns) and the absence of an output schema, the description covers the key return aspects: field type, status, and extension associations. It is nearly complete for an agent to understand what to expect, though it could mention that it returns campaign IDs or asset details explicitly.
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 parameters are already documented in the input schema. The description does not add new meaning about the parameters (customer_id, campaign_id) beyond what the schema provides, meeting the baseline expectation. It focuses on output fields instead, which is helpful but not directly relevant to 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 clearly states the tool shows assets linked to campaigns with field type and status, and specifies it reveals which extensions are active. This provides a specific verb-resource mapping and distinguishes it from sibling tools like gads_list_assets (which lists assets without campaign context) and gads_campaign_performance (which focuses on performance metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases (e.g., viewing extensions on campaigns) but does not explicitly state when to use this tool versus alternatives like gads_list_assets or gads_campaign_performance. It lacks direct guidance on exclusions or when-not-to-use, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default filters and sorting but does not mention behavioral traits like pagination, rate limits, or error handling. No annotations are provided, so the description bears full burden but covers only 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 short and front-loaded with the purpose, then lists metrics and defaults. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers core functionality and defaults adequately. However, it lacks details on return format and potential limitations, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the description adds minimal value beyond schema. It repeats defaults already in schema but does not explain metric semantics in more depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Campaign-level performance' and lists specific metrics (impressions, clicks, CTR, avg CPC, cost, conversions, conv value, CPA, ROAS), differentiating it from sibling tools like ad_group_performance or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions default settings (last 28 days, enabled campaigns, sorted by cost desc) but does not explicitly guide when to use this tool vs alternatives like gads_conversions_by_campaign. Usage is implied but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states the basic function without disclosing behavioral details such as authentication requirements, rate limits, or what 'access' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the core action. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the tool's simplicity, but could mention output format (e.g., list of account names and IDs) since no output schema is provided.
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?
No parameters, so baseline score of 4 applies. Description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all Google Ads customer accounts accessible to the user and specifies it is useful for finding customer IDs, providing a specific verb+resource and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (list accounts) but does not explicitly state when not to use or mention alternatives like gads_account_info for a specific account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the tool calculates impression share metrics and identifies limiting factors, but lacks mention of necessary permissions, data freshness, or any side effects, which is acceptable for a read-only 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 two concise sentences with essential information front-loaded, containing no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the metrics returned but does not detail output format or granularity. Given no output schema and the tool's complexity (campaign-level data from Google Ads), more specifics would be beneficial but the core is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (customer_id, start_date, end_date). The description does not add meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns 'Search Impression Share, Lost IS (Budget), and Lost IS (Rank) per campaign' and identifies whether budget or Quality Score/bid is limiting reach, distinguishing it from sibling tools like gads_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 implies use for impression share diagnostics per campaign but does not explicitly contrast with alternatives or state when to avoid it, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions a default date range of last 28 days, which is a behavioral trait. However, it does not explicitly state that the tool is read-only or disclose any side effects, permissions, or rate limits. The report nature implies read-only, but the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, very concise, and front-loaded with key information. Every sentence serves a purpose: defining the tool, stating its utility, and noting the default time range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (with 33% description coverage), no output schema, and no annotations, the description provides the core purpose and a use case but leaves gaps. It does not describe the output format, pagination behavior, or how to handle large result sets (despite a limit parameter). The default date range is helpful, but overall completeness is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), so the description should compensate. It adds value by explaining the default date range (last 28 days), which maps to start_date and end_date defaults. However, it does not describe other parameters like customer_id, limit, campaign_id, or min_impressions 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 returns 'search terms that triggered ads (the actual user queries, not your keywords)', with a specific verb ('Search terms that triggered') and resource ('ads'). It distinguishes from keywords, differentiating it from sibling tools like gads_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 says it is 'essential for finding wasted spend and negative keyword candidates', providing clear use cases. It implicitly contrasts with keyword-focused tools, though it does not explicitly mention when to avoid using this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the default 28-day lookback, which is a behavioral trait. However, it does not mention read-only nature, data freshness, pagination, or other behaviors, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the key output dimensions. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the main aspects: metrics, breakdown, and default period. It lacks details on output format or usage notes, but these are somewhat implied. The absence of an output schema slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns specific metrics (clicks, cost, CTR, conversions, CPA) broken down by device type (MOBILE/DESKTOP/TABLET) per campaign, with a default time range. This distinguishes it from siblings like gads_campaign_performance or gads_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 implies usage for device-level campaign performance analysis, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The default period is mentioned, offering some context.
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-npm MCP server](https://glama.ai/mcp/servers/ZLeventer/google-ads-mcp-npm/badges/card.svg)](https://glama.ai/mcp/servers/ZLeventer/google-ads-mcp-npm)

Score Badge

Copy to your README.md:

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

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

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