google-ads-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity and action (list, create, update) for customers, campaigns, ad groups, ads, budgets, and keywords. The general-purpose search tool is clearly separate from the type-specific listers, and even the two account-related tools (ads_whoami, list_accessible_customers) serve different purposes.
Naming Consistency4/5
Most tools follow a predictable verb_noun pattern (list_*, create_*, update_*), but there are minor deviations like ads_whoami, search, campaign_performance, and 'add_keyword' instead of 'create_keyword'. These are readable and not chaotic, but break the otherwise consistent convention.
Tool Count4/5
With 18 tools, the server is slightly on the heavier side but justified by the breadth of Google Ads entities and operations. Each tool covers a distinct area, and no tool feels redundant, so the count is well-scoped for the complexity of the domain.
Completeness3/5
The set covers account access, reporting, and CRUD for campaigns, ad groups, budgets, and keywords, but notably lacks any tool to create or update ads. This is a significant gap for an advertising management server, as ads are central to the workflow, though the presence of list_ads and search partially mitigates the issue.
Average 4/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 13, 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 alone must convey behavioral traits. It only lists output fields and does not explain the effect of include_removed or any default behavior (e.g., whether removed campaigns are excluded by default). It provides minimal insight beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and key output attributes. Every word carries information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not clarify the role of customer_id, the meaning of include_removed, or any constraints on the listing (e.g., pagination, ordering). The tool is simple, but the description still leaves important context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning for the two parameters (customer_id, include_removed). Since schema description coverage is 0%, the description was expected to compensate but instead focuses on output fields, leaving parameter meaning entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource 'campaigns' along with the expected fields (id, name, status, channel type, budget id). This clearly distinguishes it from sibling tools like list_ad_groups and list_campaign_budgets.
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, nor any mention of prerequisites or context. It simply states what it does, leaving the agent to infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It states the returned fields but does not mention whether the operation is read-only, any permission requirements, or pagination behavior. The word 'list' implies a read operation, but more disclosure would be helpful.
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 action and resource. Every word adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description lists the output fields, which is useful, but it does not address potential concerns like whether all budgets are returned or if the customer_id format matters. Given the lack of annotations and output schema, the description leaves some gaps but is mostly adequate for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter, customer_id, with no description. The tool description does not mention or explain this parameter, so it adds no semantic value beyond the schema field's name. Given 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('campaign budgets'), and enumerates the returned fields (id, name, amount, delivery method). This distinguishes it from sibling tools like list_campaigns or create_campaign_budget.
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 is given on when to use this tool versus alternatives such as list_campaigns. However, the name and description make its purpose clear, so usage is implied but not 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, the description carries the full burden of explaining behavior. It discloses the read-only reporting nature, the included metrics, date range, and ordering. However, it does not describe the return format, pagination, or what happens when no data matches, which would be useful for a reporting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that includes the core action, metrics, date format, and sort order. Every phrase earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary reporting purpose, metrics, date range, and ordering. However, with no output schema and no annotations, it leaves gaps around limit behavior, customer_id scope, and result shape. More detail would make the tool self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for start_date and end_date by specifying YYYY-MM-DD, and implies the report content, but it does not explain customer_id or limit semantics. This is only partial compensation for an undocumented 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 begins with the verb 'Report' and a specific resource, 'per-campaign performance', and enumerates concrete metrics (impressions, clicks, cost, conversions). This clearly distinguishes it from siblings like list_campaigns, which simply list campaigns without performance data.
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 usage context by specifying the date range format and the sort order ('highest spend first'). It does not explicitly mention alternatives or exclusions, but the purpose and constraints are clear enough for an agent to select this tool when campaign performance metrics are needed.
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 burden of behavioral disclosure. It reveals the return fields and the optional filter, which is useful, but it does not mention potential pagination, default sort order, or whether inactive ad groups are included, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the primary verb and resource, followed by essential scope and return-value details. Every word adds value, 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?
For a simple list tool with two parameters and no output schema, the description provides the essential context: what it lists, the optional filter, and the returned fields. It could add pagination or filtering details, but the current description is largely complete for typical agent 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 description coverage is 0%, so the description must compensate. It clarifies that campaign_id is an optional filter ('optionally filtered to one campaign'), but it does not explain customer_id beyond what the schema's title implies. This partial clarification aligns with a mid-range score.
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 ad groups') with a specific resource and optional scope ('optionally filtered to one campaign'). It also lists the returned fields, which distinguishes it from sibling tools like list_ads and list_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when ad groups are needed and explains the optional campaign filter, but it does not explicitly state when to use this tool over alternatives like list_campaigns or list_ads, nor does it provide exclusions or prerequisites.
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 reveals that each ad has an id, type, and status, and that an optional ad group filter is supported. However, it does not disclose whether results include deleted/inactive ads, pagination, ordering, or required permissions. More context would help, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that leads with the verb 'List', specifies the resource, the optional modifier, and the returned fields. Every word adds value; 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?
For a simple list operation with two parameters and no output schema, the description covers the primary behavior and return fields. It implies that omitting ad_group_id returns all ads, which is clear enough. Missing details like pagination and default sorting, but these are not critical for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property descriptions (0% coverage), so the description must clarify parameters. It does explain ad_group_id as an optional filter. However, customer_id is not described, though its purpose as a customer identifier is self-evident from the name and required nature. The description partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description unambiguously states the tool's function: listing ads, with an optional ad group filter, and names the return fields (id, type, status). This clearly distinguishes it from sibling tools like list_ad_groups and list_campaigns due to the specific resource (ads) and the output payload.
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 usage scenario (listing ads, filtering by ad group) but does not explicitly explain when to choose this over alternatives such as list_ad_groups or search. No exclusions or conditional guidance are provided, so it is adequate but not 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 and does well by revealing the crucial dry-run behavior: 'Dry run unless confirm=True'. This prevents accidental mutations and is important context. It also clarifies match_type allowed values, though it doesn't mention other potential side effects like duplicate handling.
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. Every sentence adds value: match_type enumeration and dry-run behavior. 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?
For a simple tool without output schema or annotations, the description covers the essential behavioral context (dry run, match_type) and is sufficiently complete for an agent to invoke correctly. Minor gaps like return format or post-condition are not critical for the core operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains match_type (allowed values) and confirm (default dry-run), but leaves text, ad_group_id, and customer_id to inference from names. These are fairly self-explanatory, but for full compensation, more explicit parameter details would be better.
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 exact action (add a keyword) and the target resource (an ad group), which clearly distinguishes it from sibling tools like update_keyword_status or list_keywords. The verb+resource structure is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies 'use this when you need to add a keyword to an ad group' but does not explicitly compare with alternatives like update_keyword_status or provide exclusions. It lacks when/when-not guidance, though the tool's purpose is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It communicates a read-only listing operation and the output fields, but it does not discuss pagination, ordering, or the full scope when ad_group_id is omitted; the behavior beyond the schema is only lightly disclosed.
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, front-loaded sentence that uses verbs and nouns efficiently, with 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 simple 2-parameter list tool, the description covers purpose, the optional filter, and return fields, which is strong given no output schema or annotations. However, it omits edge-case behavior such as pagination and the full default scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies ad_group_id's role as an optional filter, but it does not explain customer_id beyond the schema's title, leaving that parameter under-explained.
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 'List keyword criteria', a specific verb + resource, and specifies the optional ad group filter and the exact fields returned (text, match type, status, criterion id). This clearly distinguishes it from sibling list tools like list_ads or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states that the tool lists keyword criteria and can be filtered to one ad group, giving concrete invocation context. It does not explicitly name alternatives or exclusions, but the context is unambiguous.
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?
The description discloses the dry-run behavior with 'Dry run unless confirm=True.' This is a critical behavioral detail, especially since no annotations exist. It also implies a mutation via 'change'. However, it doesn't mention authentication requirements, rate limits, or what happens after confirmation.
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 does not waste words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter update tool with no annotations or output schema, the description covers the core action and the dry-run safety mechanism. It doesn't specify return values or side effects, but it's adequate for a straightforward budget update.
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 amount_micros by specifying 'in micros' and 'daily amount', and clarifies confirm with 'Dry run unless confirm=True.' However, schema coverage is 0% and it doesn't explain customer_id or budget_id, which may be ambiguous to some agents.
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: 'Change a campaign budget's daily amount (in micros).' It specifies the verb 'change', the resource 'campaign budget', and the specific field 'daily amount' (in micros), distinguishing it from sibling tools like create_campaign_budget (creation) and list_campaign_budgets (listing).
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 the primary use case but does not mention when to use this versus creating a budget or updating status. It lacks explicit alternatives or exclusions, so it's clear but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: dry-run by default unless confirm=True, and the meaning of amount_micros and delivery_method. It does not mention side effects or return values, but the dry-run disclosure adds significant safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and each sentence adds value: purpose, unit explanation, delivery method, and dry-run flag. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers essential usage details for a create operation with dry-run, but omits what the response will be and any prerequisites or error conditions. Given no output schema, that information could have been included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains the non-obvious parameters: amount_micros (with example), delivery_method (allowed values), and confirm (dry-run behavior). It does not elaborate on name or customer_id, but those are straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Create a campaign budget.' It distinguishes from sibling tools like update_campaign_budget and list_campaign_budgets by the action of creation.
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 context (creating a new budget) but does not explicitly state when to use this tool vs alternatives like update_campaign_budget. No exclusions or alternative mention, though the action of creation is 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?
The description proactively discloses that the tool performs a dry run by default, requiring confirm=True to execute the change. This is critical behavioral context beyond the tool name, especially given no annotations are present. It does not cover return behavior or permissions, but the dry run disclosure is substantial.
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, information-dense sentence front-loaded with the action verb and object. It contains no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the crucial dry-run default, but lacks details about expected return values, side effects of confirmation, and parameter semantics for the IDs. Given no output schema and no annotations, it leaves moderate gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic meaning to cpc_bid_micros ('in micros') and confirm ('Dry run unless confirm=True'), but leaves customer_id and ad_group_id unexplained. With 0% schema description coverage, it only partially compensates for the missing parameter documentation.
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 changes an ad group's default max CPC bid, with the unit (micros) specified. It uniquely identifies this operation among sibling tools, none of which handle bid updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is an update operation for bids. The 'Dry run unless confirm=True' guidance tells when actual changes happen. However, it does not explicitly compare to alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds value by detailing the exact output format ('customers/1234567890') and clarifies that the digits represent the customer ID, which is not specified in the schema. It does not discuss pagination, ordering, or side effects, but for a simple read-only listing operation this level of transparency is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb, and every word earns its place. It defines the output format in the second sentence without redundancy, making it highly efficient 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?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description adequately covers the key context: what is listed, the format, and the scope of the login's accessibility. It stops short of specifying the overall return container (e.g., JSON array) but that is easily inferred from 'List the resource names'. For a tool of this complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information, and the empty schema already communicates that no arguments are required. The description's focus on output semantics 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 states the verb 'List' and the specific resource 'Google Ads customers this login can access', with an explicit example of the output format. This distinguishes it from sibling tools like list_campaigns or list_ad_groups which operate on different entities. The purpose is unambiguous and immediately actionable.
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: obtaining customer resource names for a login to use with other tools that require a customer ID. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions. The guideline is present only implicitly through the phrase 'this login can access', so it's adequate but not 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?
No annotations are provided, so the description carries the burden. It indicates this is a 'read tool' (implying no mutation), but does not disclose potential side effects, error handling, rate limits, or the format of returned rows beyond 'rows'. More behavioral detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, a scope statement, and a representative example. The example is necessary to demonstrate GAQL syntax and does not add unnecessary 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 absence of an output schema, the description provides a solid overview but lacks details on pagination, result ordering, or potential errors. For a general-purpose query tool, the example helps but could be supplemented with notes on large result sets or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by providing a full example query that illustrates the 'query' parameter's expected syntax and structure. However, it does not clarify the 'customer_id' parameter format (e.g., dashes or not), leaving some ambiguity.
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 runs GAQL queries and returns rows, with a specific verb ('Run') and resource ('GAQL query'). It also distinguishes itself as the 'general-purpose read tool' for Google Ads, differentiating it from sibling tools like list_campaigns or campaign_performance, which are specialized.
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 frames the tool as the general-purpose read tool, implying it is the fallback for anything not covered by specialized list tools. However, it does not explicitly mention when to avoid it or name alternatives, leaving some ambiguity for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It does disclose the masked developer-token presence and access listing, but it does not explicitly state whether the operation is read-only or has any side effects. It also does not mention any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with a parenthetical clarification, followed by a single instructional sentence. It is concise and front-loaded with the action.
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 tool has no parameters and no output schema; the description fully explains the tool's purpose and use case, including what it reveals (configuration, masked token, accessible accounts) and when to invoke it. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric baseline is 4. The description adds no parameter-level detail, 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?
The description uses specific verbs 'Show' and 'list' to indicate the tool displays server configuration and accessible Google Ads accounts. It clearly distinguishes from siblings like list_campaigns or search by focusing on server identity and access.
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 instructs 'Use this first to verify credentials and access,' providing clear when-to-use guidance. However, it does not mention any alternatives or when not to use it, so it falls short of fully explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the disclosure burden. It reveals a critical behavior: 'Dry run unless confirm=True,' which is essential for a mutation tool. However, it does not mention other behaviors like return values or error conditions, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by key parameter semantics and a safety-critical note. Every word earns its place with no 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?
For a create operation with no output schema or annotations, the description covers the essential context: what is created, where it is placed, and the dry-run execution model. It does not elaborate on return formats or permissions, but the core usage is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to cpc_bid_micros ('optional default max CPC bid in micros') and clarifies confirm's functional role via the dry-run statement. Other parameters like name, campaign_id, and customer_id are self-explanatory from their names, so the description compensates reasonably given the 0% 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, specific verb ('Create') and resource ('a standard Search ad group under a campaign'), which distinguishes it from sibling update/create tools. It leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is the tool for creating an ad group under a campaign. It does not explicitly list alternatives or when-not-to-use, but the action and target resource are unambiguous, and sibling tools are clearly for other operations.
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 critically discloses the dry-run default behavior ('Dry run unless confirm=True'), which is a major safety-related trait. It also restricts acceptable inputs to three status values. It does not cover permissions or reversibility, but the dry-run disclosure is significant and goes beyond a generic update statement.
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, front-loaded with the core purpose and followed by the critical behavioral note. Every word adds value with no redundancy or unrelated 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?
For a simple status-update tool with 4 parameters and no output schema, the description covers the essential aspects: what the tool does, which parameters matter most, and the default dry-run behavior. It does not mention return values or error conditions, but these are not essential given the tool's simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by enumerating the possible values for 'status' and explaining the effect of 'confirm' (dry run unless true). It does not elaborate on 'customer_id' and 'ad_group_id', but those are self-explanatory from their names. This adds meaningful semantics to the most complex 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's purpose: 'Set an ad group's status' and enumerates the specific allowed values ('ENABLED', 'PAUSED', 'REMOVED'). This distinguishes it from sibling tools like update_campaign_status or update_keyword_status, which act on different entities.
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 by specifying the target resource (ad group) and the action (set status). It also provides an explicit usage instruction: 'Dry run unless confirm=True', which tells the agent that a confirm flag is required to execute changes. However, it does not explicitly mention when not to use the tool or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the dry-run behavior ('Dry run unless confirm=True') and clarifies that 'REMOVED' means delete, which are critical for safe use. It does not detail return values or irreversible consequences beyond 'delete', but the main safety mechanism is disclosed.
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 primary action and statuses. It includes only essential details (status meanings, dry-run/confirm) and no redundant 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 complexity (4 parameters, no output schema, no annotations), the description covers the core behaviors: what statuses are allowed, that it defaults to a dry run, and that confirmation is required to execute. It lacks some edge-case details (e.g., error handling, prerequisites, whether REMOVED is reversible), but the essential usage context is complete for typical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'status' parameter's allowed values and the 'confirm' parameter's role in enabling the actual update. It leaves 'customer_id' and 'campaign_id' implicit, but these are clear from the parameter names and the tool's purpose. This is meaningful added value beyond the minimal 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 action ('Set a campaign's status') and specifies the exact statuses ('ENABLED', 'PAUSED', 'REMOVED') with their meanings. This distinguishes it from sibling tools like update_ad_group_status, which targets ad groups rather than campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for changing campaign status and includes semantics for each status, providing clear context. It does not explicitly mention alternatives or exclusions (e.g., 'for ad groups use update_ad_group_status'), so it falls short of an explicit when/when-not, but the context is unambiguous.
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 explicitly mentions the dry-run behavior ('Dry run unless confirm=True'), which is a critical safety feature, and indicates the source of criterion_id. It does not detail reversibility of 'REMOVED' or permission requirements, but the dry-run note adds significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly concise, and front-loaded with the core purpose. Every phrase adds value: the status values, the source of criterion_id, and the dry-run behavior. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status-update tool with 5 parameters and no output schema, the description covers the essential context: what the tool does, how to identify the keyword, and the safety mechanism. It could elaborate on the implications of 'REMOVED' but is otherwise sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description compensates by explaining the meaning of key parameters: criterion_id is 'the keyword's criterion id (from list_keywords)', status values are enumerated, and confirm controls dry-run vs actual execution. Customer_id and ad_group_id are not explained, but the description adds substantial value for the most critical 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's function: 'Set a keyword's status' with specific allowed values ('ENABLED', 'PAUSED', or 'REMOVED'). This distinguishes it from sibling tools like update_campaign_status or update_ad_group_status, as it targets keywords specifically.
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 context on when to use the tool: it is for updating keyword status, and it specifies how to obtain the required criterion_id ('from list_keywords'). While it does not explicitly exclude alternatives, the scope is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical side effects: the campaign is created PAUSED by default, configured as a Search campaign with Manual CPC and Google Search + search partners, and the operation is a dry run unless confirm=True. This is substantial behavioral context, especially with no annotations provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense: action, defaults, safety rationale, and dry-run behavior are all covered in four sentences. Every sentence provides distinct value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential behavioral context is covered: defaults, dry-run behavior, and next steps. However, since there is no output schema, it does not describe what the tool returns (e.g., a preview or campaign ID), nor does it mention error conditions or permission requirements. These are moderate gaps for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining default values for status (PAUSED), advertising_channel_type (SEARCH), and confirm (dry run). It also clarifies that budget_id references an existing budget, adding meaning beyond the raw 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 states the tool creates a campaign attached to an existing budget, using a specific verb and resource. It distinguishes from siblings like create_campaign_budget (which creates a budget) and update_campaign_status (which modifies 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 establishes a prerequisite (existing budget) and mentions a follow-up action via update_campaign_status. However, it doesn't explicitly enumerate when not to use this tool or alternatives for creation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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