AdMob MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool maps to a distinct resource or action: accounts, apps, ad units, and two clearly differentiated report types (network vs. mediation). No meaningful overlap exists between tool purposes.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern: list_accounts, get_account, list_apps, list_ad_units, generate_network_report, generate_mediation_report. The pattern is predictable and uniform.
Tool Count5/5
Six tools is well-scoped for an AdMob read/reporting surface. Each tool earns its place without redundancy or bloat.
Completeness4/5
The surface covers account discovery, app/ad unit listing, and comprehensive network/mediation reporting. Minor gaps exist for detailed per-app or per-ad-unit lookups and mutation operations, but core reporting workflows are well covered.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a list operation (implying read-only) but does not explicitly mention that it is safe, nor does it disclose any side effects, permissions, or output details. The provided account_name format is helpful but pertains to parameter semantics rather than 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?
The description is a single sentence that is front-loaded with the core action and includes the critical parameter format. There is no wasted wording, and it is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description need not cover return values. However, it omits any mention of pagination, filtering, or read-only semantics. It is minimally adequate but could benefit from a note about the nature of the list (e.g., that it is read-only).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the single parameter, so the description must compensate. It provides the exact expected format of account_name ('accounts/pub-1234567890123456'), which is essential for correct invocation. This goes beyond the schema's bare type definition.
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 ad units under an account, with a specific verb and resource. It doesn't explicitly distinguish from sibling tools, but the resource (ad units) is distinct from accounts, apps, and reports, so it is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as needing an existing account, nor does it contrast with other list/generate tools. The usage context is left entirely to inference.
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 present, the description carries the full burden for behavioral transparency. It indicates that the tool generates a report and lists valid query values, but it never states whether the operation is read-only, whether it has side effects, or how results are returned and paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well structured: a one-line purpose followed by short parameter, default, and value lists. There are no redundant sentences or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of description and input schema provides enough to make a basic call: required parameters are formatted, defaults and valid values are listed, and an output schema exists. It falls short only on max_report_rows semantics and report-shaping details such as pagination or timezone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the format of account_name, start_date, and end_date, and enumerates valid and default values for dimensions and metrics, covering most parameters. max_report_rows is left without any explanation, and the meaning of individual dimension or metric values is not expanded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate an AdMob mediation performance report,' and the parenthetical clarifies it covers earnings across ad sources. This is enough to distinguish it at a high level from sibling reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes concrete usage guidance: account_name format, inclusive date format, and defaults for dimensions and metrics. It does not explicitly state when to choose this tool over generate_network_report, so some situational guidance is missing.
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 burden. It accurately describes a read-only 'Fetch' operation with no side effects, but it does not explicitly disclose permissions or confirm that no state changes occur. The description is not misleading, but it is minimal in its behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It conveys the essential purpose and parameter format efficiently, making it highly scannable for an agent.
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?
Since an output schema exists, not describing the return structure is acceptable. The description covers what the tool does and the parameter format. It omits potential error cases or prerequisites, but for such a simple get operation, that information is not critical.
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?
Although the schema provides no description, the tool description compensates by giving a concrete format example ('accounts/pub-1234567890123456'). This clarifies the expected pattern for the account_name parameter, exceeding the schema's bare type definition.
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 specific verb 'Fetch' and the resource 'account's details', distinguishing it from list_accounts by indicating it retrieves a single account. The example format for account_name further clarifies the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 the sibling tools (e.g., list_accounts). It implies usage when a specific account_name is known, but this is not stated directly, leaving the agent to infer the appropriate 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?
No annotations are provided, so the description carries the full burden. It states the operation is a list (read-only) and gives the account_name format, which is useful. However, it does not disclose pagination, ordering, or any other behavioral details. For a simple read operation, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The key scope ('under an account') is front-loaded, and the parameter format is provided succinctly. 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?
The tool has an output schema, so return values are covered. The description is sufficient for a simple list operation with one parameter, given the sibling context. It could mention pagination or sorting, but those are minor for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by specifying the expected format of account_name ('accounts/pub-1234567890123456'), which adds meaningful guidance beyond the bare string type in the schema. This fully clarifies the single 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 clearly states the tool lists apps under an account, with a specific resource and scope. It is distinct from siblings like list_accounts (accounts) and get_account (single account), so an agent can easily tell it apart.
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 explicit guidance on when to use this tool versus alternatives. The description implies it is for listing apps, but does not mention when not to use it or how it differs from list_accounts or list_ad_units. The agent must infer usage from the name and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful context: defaults for dimensions and metrics, and the full list of valid values for both. It also specifies the account_name format and inclusive date range. However, it does not explicitly state that this is a read-only operation, does not mention any side effects, rate limits, or authentication needs, and does not describe the output format beyond what the output schema would provide. This is a moderate disclosure given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a clear purpose sentence, followed by parameter format notes, then defaults and valid values. Every line contributes necessary information, and it is front-loaded with the main purpose. There is no redundant phrasing, and it uses line breaks to group related details, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. It covers all required parameters' formats and the optional parameters' defaults and allowed values. It does not mention any prerequisites like the need for a valid account from list_accounts, but that is implicitly available through sibling tools. The only gap is the lack of explanation for max_report_rows, but overall it is sufficient for an agent to call the tool 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 schema has 0% description coverage, so the description must compensate. It does explain the format for account_name ('accounts/pub-1234567890123456') and start_date/end_date ('YYYY-MM-DD', inclusive). It provides defaults and valid values for dimensions and metrics, which is beyond the schema. However, it does not explain the max_report_rows parameter at all, leaving it ambiguous. Overall, it adds significant meaning for most parameters but misses one.
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 'Generate an AdMob network (own ad serving) performance report.' The verb 'generate' plus the specific resource 'network performance report' is precise, and the parenthetical '(own ad serving)' distinguishes it from the sibling generate_mediation_report. An agent can immediately understand what this 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 explicitly scopes to 'network (own ad serving)', which implies it is for own ad serving reports as opposed to mediation. It provides the account_name format and date format, which are essential for usage. However, it does not explicitly name the alternative generate_mediation_report or state when not to use this tool, relying on the agent to infer the distinction from the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'accessible to this credential,' which implies read-only scoping, but does not explicitly state that the operation is non-mutating. Given the list nature, it is reasonable to assume read-only, but the absence of an explicit statement prevents a perfect score.
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 with no extraneous information. It is well-structured and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple list operation with no parameters. It does not specify the output format, but that is often unnecessary for basic tools and may be covered by an output schema (not shown). Overall, it provides sufficient context for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters, so the description adds meaning by defining the resource type and the scope ('accessible to this credential'). This is sufficient for a parameterless tool.
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 ('AdMob publisher accounts'), and it distinguishes itself from the sibling tool 'get_account' by implying a list-all operation rather than fetching a single account.
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 (to retrieve all accessible accounts) but does not explicitly state when to prefer this over get_account or other list tools. The context of sibling tools partially clarifies, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

AdMob MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![AdMob MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/jimsimoy/admob-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jimsimoy/admob-mcp)

Score Badge

Copy to your README.md:

[![AdMob MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/jimsimoy/admob-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jimsimoy/admob-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![AdMob MCP MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fjimsimoy%2Fadmob-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/jimsimoy/admob-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jimsimoy/admob-mcp'

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