Google Ads MCP Admin

by jomiferse

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool serves a distinct purpose: customer discovery, metadata lookup, data search, and mutation plan lifecycle. The only mild ambiguity is between 'plan_mutations' and 'get_mutation_plan', as both return previews, but their roles (create vs retrieve) are clarified in descriptions.
Naming Consistency4/5
Tools follow a consistent [domain]_[action] pattern with snake_case, such as customers_list_accessible_customers and mutations_apply_mutation_plan. The name 'search_search' is slightly awkward (resource and verb identical), but overall the pattern is predictable and coherent.
Tool Count5/5
Eight tools is well-scoped for the Google Ads admin domain, covering customer access, metadata/field discovery, search, and a complete mutation planning workflow. No redundant or excessive tools.
Completeness4/5
The mutation plan lifecycle is well covered (plan, get, cancel, acknowledge, apply), and search is supported by metadata discovery. Minor gaps include no way to list all mutation plans and no single-customer detail endpoint, but these are edge cases rather than core dead ends.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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 Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false and destructiveHint=false, so the mutation nature is known. The description adds the nuanced context of 'first interactive approval,' implying a workflow step, but does not disclose side effects, idempotency, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action verb, zero filler. Appropriate length, and every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present but no param descriptions, no usage guidance, and only one contextual hint about high-risk plans, the description is insufficient for an agent to confidently integrate this tool into a mutation workflow.
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 elaborate on plan_id or plan_hash. There is no added meaning beyond parameter names; an agent must guess the hash's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Record' and identifies the resource as a 'high-risk plan' with the scope 'first interactive approval required.' This clearly distinguishes it from sibling mutation tools like apply, cancel, or plan mutations.
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 mutations_plan_mutations, mutations_cancel_mutation_plan, or mutations_apply_mutation_plan. It does not mention prerequisites, workflow position, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: it says 'Invalidate a pending local plan' (a mutation) while annotations declare readOnlyHint: true. This is a direct contradiction, and the description does not reconcile this by explaining that it only affects local state. Annotation contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core function. Every word adds value, and there is no unnecessary 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?
Despite having an output schema, the description is too minimal to fully support an agent. It omits any explanation of parameters, side effects, or how it relates to the mutation plan lifecycle. The contradiction with annotations further reduces its reliability, making it incomplete for a tool that invalidates a plan.
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 what 'plan_id' and 'plan_hash' are or how they relate to the invalidation. With two required parameters and no added context, the description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Invalidate' and the specific resource 'a pending local plan', and adds the scope 'without changing Google Ads', which distinguishes it from apply/acknowledge siblings. It is concise and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for invalidating a pending local plan, implying it should be used instead of applying or acknowledging it. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation. The description confirms the fetching behavior and adds the 'search method' detail, but does not disclose additional traits like pagination, rate limits, or error handling. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and method. Every word is meaningful, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity, but the schema fully covers parameters and an output schema exists. The description is adequate but minimal; it does not explain the GAQL/search method context or provide operational guidance beyond the basic purpose. Given the richness of structured data, this is a passable but not exceptional description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all six parameters. The tool description itself adds no parameter-level meaning, so per the rubric baseline of 3 for high schema coverage, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetches data'), the resource ('Google Ads API'), and the method ('search method'), making it distinct from sibling mutation and metadata tools. The verb is specific and the resource is clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it name sibling tools or list exclusions. The intended read-only use is only implied by the annotations and the word 'fetches', not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. The description adds context by mentioning 'immutable preview' and 'current local plan state', but does not disclose additional behavioral traits like error conditions or authorization needs. Credit for adding some context beyond annotations, but not 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, concise sentence that front-loads the key action and object. It wastes no words and is appropriately sized for a simple read-only getter.
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 one parameter and an existing output schema, the description is mostly complete. It clarifies the two components of the return value ('stored immutable preview' and 'current local plan state'). However, it could be slightly richer by explicitly mentioning plan_id as the input, but given the schema and output schema, the description is sufficient.
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%; the description does not mention the 'plan_id' parameter at all. The schema only provides the name and type, leaving the agent to guess what a valid plan_id is. With 0% coverage, the description fails to compensate, resulting in minimal semantic guidance for the parameter.
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 'Return the stored immutable preview and current local plan state' states a specific verb ('Return') and resource ('mutation plan'), and clearly distinguishes this getter from sibling tools like apply, cancel, and acknowledge which modify or act on plans. It precisely describes what the tool returns.
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 verb 'Return' implies usage for retrieving plan state, but there is no explicit when-to-use guidance or mention of alternatives. Context from sibling names suggests this is the read-only getter among mutation plan operations, but the description does not state when to prefer this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the description's job is to add context beyond that. It adds the requirement of interactive approval and exactly one plan, which are useful safety constraints, but does not disclose what happens to the plan after application (e.g., whether it is consumed) or any rollback possibilities.
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?
One sentence with no fluff, every word adds value: 'Apply exactly one' sets scope, 'previously previewed' sets precondition, 'after interactive approval' sets workflow. Description is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low parameter count, presence of an output schema, and clear annotations, the description covers the essential purpose and constraints. It could clarify the exact nature of 'interactive approval' (e.g., whether it blocks or expires), but this is minor because the workflow is implied by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes parameters as plan_id and plan_hash (both required strings) but has 0% description coverage. The description does not mention either parameter or explain the meaning or relationship (e.g., why hash is needed, how to obtain them). The tool name implies they identify a plan, but no additional semantics 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 the action ('Apply'), the resource ('mutation plan'), and specific constraints (exactly one, previously previewed, after interactive approval). This distinguishes it from sibling tools like mutations_get_mutation_plan (retrieving) and mutations_cancel_mutation_plan (canceling).
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 phrase 'after interactive approval' and 'previously previewed plan' clearly indicates when this tool should be used: only after preview and approval. It implies the workflow but does not explicitly name alternatives or exclusions, though sibling tools make it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by specifying 'return an immutable preview' and reinforcing 'makes no Ads write.' This goes slightly beyond the annotations by clarifying the nature of the returned data (immutable preview) rather than just the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and directly states the tool's purpose. 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?
Given the output schema and strong annotations, the description adequately conveys the tool's primary role as a non-writing validation/preview step. However, it misses details about partial_failure handling and could benefit from explicit differentiation from the many sibling mutation tools, leaving a slight gap.
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 only mentions 'operations' as the subject of validation, leaving customer_id and partial_failure completely unexplained. The description fails to provide essential parameter context.
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: 'Validate operations and return an immutable preview' and explicitly notes it 'makes no Ads write.' This distinguishes it from sibling tools like mutations_apply_mutation_plan, which applies plans, and mutations_get_mutation_plan, which retrieves plans.
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 previewing/validation ('return an immutable preview'; 'makes no Ads write') but does not explicitly state when to use it over alternatives like mutations_apply_mutation_plan or mutations_get_mutation_plan. No exclusions or explicit alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, so safety is covered. The description adds context about field naming conventions ('metrics.' and 'segments.' prefixes) and that responses should be cached as they don't change frequently. This adds behavioral context beyond the annotation without contradicting it.
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 four sentences, with the main purpose in the first sentence and supporting details following. There is no fluff—every sentence contributes either functional purpose, usage guidance, or caching advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, there's no need to explain return values. The description covers scope, usage, mandatory invocation, field naming, and caching. For a single-parameter tool with rich schema/annotations, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter, which already explains it as 'The name of the Google Ads resource (e.g., 'campaign', 'ad_group').' The description repeats this with examples but doesn't add substantially new semantic detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves selectable, filterable, and sortable fields for a specific Google Ads resource, including compatible metrics and segments. It uses a specific verb ('Retrieves') and resource, distinguishing it from siblings like search and mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: to discover fields before constructing a query for the `search` tool. It also provides a strong exclusion: 'Do not guess fields, you MUST use this tool to discover them.' This is clear guidance on when this tool is required vs 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?
Annotations already provide readOnlyHint=true, and the description adds context that IDs are 'directly accessible by the user authenticating the call' and that this is a discovery tool. This goes beyond the annotation by specifying scope and workflow, though it does not cover all potential behaviors (e.g., pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short lines with no filler. Each sentence adds value: it states what the tool does, when to use it, and what it returns. The structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool with an output schema, the description is complete. It covers the purpose, the return type, and the workflow context (other tools need a customer ID). The existing output schema handles the return specification, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully documents any inputs (none needed). The baseline for 0 params is 4, and the description correctly avoids adding parameter details that don't exist.
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 customer IDs accessible by the user, using a specific verb ('Returns') and resource (customer IDs). It distinguishes from sibling tools by focusing on 'directly accessible' customers and noting its role as a discovery step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this tool first to discover available customer IDs if the user hasn't provided one. Most other tools require a valid customer ID as input.' This clearly states when to use it and why it is the appropriate first step.
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-admin MCP server](https://glama.ai/mcp/servers/jomiferse/google-ads-mcp-admin/badges/card.svg)](https://glama.ai/mcp/servers/jomiferse/google-ads-mcp-admin)

Score Badge

Copy to your README.md:

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

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

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