admob-mcp-server

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct resource and action, with clear scope across accounts, apps, ad units, reports, and mediation. The three report generators are clearly differentiated by report type, and the mediation-related listing tools are distinguished by entity (ad sources vs adapters vs mediation groups vs mappings).
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (e.g., list_accounts, create_app, generate_network_report, update_mediation_group, stop_mediation_ab_experiment). No mixed conventions or vague verbs exist.
Tool Count4/5
At 18 tools, the set is slightly above the typical well-scoped range of 3-15 but remains coherent for a domain as broad as AdMob, covering account, app, ad unit, reporting, and mediation configuration. Each tool is relevant and none feels redundant.
Completeness3/5
The surface covers core account/app/ad unit listing and creation, three report types, and mediation configuration. However, there are no update or delete operations for apps, ad units, or ad unit mappings, and no delete for mediation groups, leaving notable lifecycle gaps.
Average 4.1/5 across 18 of 18 tools scored.
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 July 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, meaning it is a write operation. The description adds the auth scope requirement, which is useful context. However, it does not disclose other behavioral aspects such as return value, idempotency, or side effects, so it provides only marginal additional 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 extremely concise, with two sentences that each carry necessary information: the primary action and the required permission scope. There is no redundancy or fluff, making it easy for the agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderately complex schema with a nested object and enums, and there is no output schema. The description provides the essential purpose and auth requirement, but it does not mention what the tool returns (e.g., the created ad unit ID). Given the schema covers parameters and annotations cover the read-only hint, the description is largely sufficient but could add a note about the response.
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 itself introduces no parameter-specific details, but the input schema includes comprehensive descriptions for all 5 parameters (schema coverage 100%). Since the baseline for full schema coverage is 3, this is appropriate; the description does not add semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an ad unit under an app in the AdMob account using the specific verb 'Creates' and identifies the resource. It distinguishes itself from sibling tools like create_app or create_ad_unit_mapping by specifying exactly what entity is being created.
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 the tool should be used when creating an ad unit under an app, and it notes the required OAuth scope (admob.monetization). However, it does not explicitly mention when not to use this tool or provide comparisons with alternative tools, so the guidance remains implicit rather than 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?
The description explains that the treatment variant serves given mediation lines against the existing setup, and notes the required OAuth scope. With only readOnlyHint=false in annotations, it does not disclose side effects beyond creation, such as whether existing experiments are affected or if changes are reversible, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every phrase adds value—the purpose, the treatment/control semantics, and the required scope. 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 rich input schema, the description adequately supplements it with the experiment's purpose, the treatment variant behavior, and the required scope. While no output schema exists and return behavior isn't described, the description is sufficient for an AI agent to understand the tool's role and main side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds minimal parameter-level meaning beyond referring to 'given mediation lines' and 'existing setup', which aligns with treatmentMediationLines and the control setup but does not substantially expand on 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 a specific verb ('Creates') and identifies the exact resource ('A/B experiment on a mediation group'). It clearly differentiates the treatment variant from the existing setup, which distinguishes it from sibling tools like stop_mediation_ab_experiment or create_mediation_group.
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 clearly implies usage for creating an A/B experiment on a mediation group, and mentions the required admob.monetization scope. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria, so guidance is only implicit.
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 annotation readOnlyHint=true already indicates a safe read operation. The description adds that results include ad source IDs, which is useful return context. However, it does not disclose pagination behavior, ordering, or any other behavioral nuances, but the schema covers pagination parameters, and the tool is a simple listing 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, well-structured sentence that is front-loaded with the verb and resource, followed by the scope and return details. There is no redundant or filler content, making it highly efficient.
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 optional parameters, no output schema, and good annotations, the description is nearly complete. It states the purpose, the scope ('available to the AdMob account'), and the key return detail (ad source IDs). It lacks explicit mention of pagination, but the schema covers that, so the overall information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both pageSize and pageToken having clear structural descriptions. The tool description does not add any additional meaning to the parameters, but since the schema fully documents them, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists mediation ad sources (ad networks) available to the AdMob account, with their ad source IDs. It uses a specific verb ('Lists') and resource ('mediation ad sources'), and the mention of ad networks and ad source IDs distinguishes it from sibling list tools like list_accounts or list_ad_units.
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 this tool is for retrieving ad sources from the AdMob account, but it does not explicitly state when to use it over alternatives or mention any exclusions. While the context clearly differentiates it from other list tools, no direct 'when to use' guidance is provided.
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 readOnlyHint=true, so the safety profile is known. The description adds the scoping to 'attached to an AdMob ad unit' and clarifies that mappings are third-party network placements, but it does not disclose pagination behavior or return format. This is modest value beyond 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 a single, front-loaded sentence with a clear verb and resource. It avoids redundant detail and is appropriately concise for the tool's complexity.
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 annotations covering safety and schema covering all parameters, the description is sufficient. It states the primary function and scope. Lack of an output schema is mitigated by the clear statement that it lists mappings, though it could mention pagination explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides (e.g., adUnitId format, pageSize, pageToken). The schema does the heavy lifting here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ad unit mappings (third-party network placements) attached to a specific AdMob ad unit. This distinguishes it from siblings like list_ad_units (which lists ad units themselves) and create_ad_unit_mapping (which creates mappings).
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 you need mappings for a given ad unit, but it does not explicitly say when to use this tool instead of alternatives like list_ad_units. No exclusions or alternative names are mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so read-only status is known. The description adds the defaulting behavior and specifies the account fields returned, going beyond the annotation. However, it lacks details on possible errors or how auto-discovery works.
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, directly states purpose and default behavior. No 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?
Without an output schema, the description compensates by listing the three key return fields. It also explains account selection via the default. While it doesn't cover errors, it's adequate for this simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with a clear description including an example and default behavior. The tool description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single AdMob publisher account and specifies the exact return fields (publisher ID, currency, time zone), distinguishing it from list_accounts which enumerates accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to prefer this over list_accounts, but the default behavior (configured or auto-discovered account) provides implicit context. It doesn't mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context about returned content (adapter ID and config keys) but doesn't mention pagination or other behavioral details. This is acceptable for a simple read-only list operation, but not exceptionally rich.
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 sentence that is direct and front-loaded. It conveys the action, scope, and key output without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with readOnlyHint and full schema coverage, the description adequately explains the return value essentials. It misses explicit pagination behavior, but the schema already includes pageToken/pageSize. The connection to create_ad_unit_mapping adds practical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for adSourceId, pageSize, and pageToken. The tool description does not add parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists adapters of a mediation ad source, with specific output details (adapter ID and required configuration keys). It distinguishes from siblings like list_ad_sources and list_ad_unit_mappings by focusing on adapters and linking to create_ad_unit_mapping.
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 'needed for create_ad_unit_mapping' provides strong contextual guidance on when to use this tool. It doesn't explicitly name alternative tools, but the purpose is clear enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description supports. The description adds value by listing the returned fields (ad unit ID, format, app) but does not disclose pagination behavior; however, this is partially covered by schema parameter descriptions.
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, focused sentence with no fluff. Every word contributes to the purpose and output understanding.
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 read-only listing tool, the description covers purpose and return information, and pagination is implied via the pageToken parameter in the schema. It could explicitly mention pagination behavior, but overall it is sufficient given the schema's richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for pageSize and pageToken. The description does not add parameter-level detail, but the schema already handles it, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the verb 'Lists' and the resource 'ad units in the AdMob account', and includes return fields (ad unit ID, format, app). This clearly distinguishes from sibling list tools like list_apps and create_ad_unit.
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 clearly implies a listing use case and matches the readOnlyHint, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. It provides clear context without exclusions.
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 the description aligns by saying 'Lists'. It adds useful behavioral context by specifying what is included in the response (targeting format, platform, ad units, and mediation lines), which goes beyond the annotation.
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 states the purpose and key included details with no redundant wording. It earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and a read-only annotation, the description is adequate. It communicates the primary purpose and response content, though it doesn't discuss pagination or return format, which is acceptable given the schema covers those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond the schema's existing parameter descriptions for filter, pageSize, and pageToken.
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 ('Lists') and resource ('mediation groups'), and clearly defines scope (AdMob account) and content (targeting details and mediation lines). This distinguishes it from sibling tools like create_mediation_group or list_accounts.
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 the tool is for retrieving existing mediation groups but does not explicitly state when to prefer it over alternatives, nor does it mention exclusions or prerequisites. The read-only nature is implied by 'Lists' and the sibling create/update tools, but no direct guidance is 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 already declare readOnlyHint=true, so the read-only nature is known. The description adds a valuable behavioral detail: monetary metrics are converted from micros to whole currency units (see currencyCode). This goes beyond the schema and annotations, though it does not disclose pagination or return structure.
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 long, front-loaded with the core purpose, and contains no redundant or filler content. Every sentence provides useful 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 has 8 parameters and no output schema, yet the description does not explain the return format, pagination behavior, or defaults beyond what the schema provides. It covers core purpose and a key unit conversion, but leaves gaps in expected output and usage context for a complex reporting tool.
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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that currencyCode affects the conversion of monetary metrics from micros to units, which clarifies the parameter's behavioral impact. Other parameters are not individually elaborated, but the schema already covers them.
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 ('Generates') and clear resource ('AdMob Network earnings/performance report'), and lists concrete metrics (requests, impressions, clicks, estimated earnings, match rate, RPM). It also distinguishes itself from sibling tools like generate_mediation_report and generate_campaign_report by specifying 'Network'.
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 scope is implied by 'AdMob Network report', which suggests it is for network-level data rather than mediation or campaign reports. However, the description does not explicitly state when to use this tool versus alternatives, 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 readOnlyHint=true already provided, the description adds context about credential-dependent access ('accessible with the current credentials'), which is useful. However, it does not go further to describe pagination behavior, potential errors, or the structure of the returned account list. It adds some value but not extensive.
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 main action, and includes a practical tip. There is no redundancy or irrelevant information.
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 is a simple read-only list operation with schema documenting all parameters and an annotation confirming read-only behavior. The description covers the purpose and a common use case, making it complete enough for an agent to select and invoke the tool without further guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters (pageSize and pageToken), so the schema already explains their meaning. The description does not add any additional parameter-specific context, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and clearly identifies the resource ('AdMob publisher accounts') and scope ('accessible with the current credentials'). It also provides a concrete use case ('find your publisher ID'), which distinguishes it from siblings like list_apps or get_account.
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 stating the intended use ('Use this to find your publisher ID'), but it does not explicitly mention when not to use it or compare it to alternatives among the sibling tools. It lacks exclusions but provides enough situational clarity.
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 only provide readOnlyHint=false, so the description carries the burden for behavioral disclosure. It adds the required admob.monetization scope and clarifies the purpose. It doesn't describe failure modes or return value, but for a create tool with a write annotation, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence is action-oriented and information-rich; the second covers the auth requirement. Well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema, but the schema is rich and the description provides a high-level overview plus auth requirement. It lacks an explicit description of return value or typical use-case boundaries, but is complete enough for an agent to invoke correctly with schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no significant parameter meaning beyond mentioning 'optional mediation lines,' which maps to mediationGroupLines already described in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates'), the resource ('mediation group'), and key attributes (format/platform, ad units, optional mediation lines). It distinguishes from sibling tools like list_mediation_groups and update_mediation_group by explicitly indicating creation.
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 on what the tool does and the required scope, but it does not explicitly state when to use it over alternatives or mention exclusions. Since sibling tools include update_mediation_group, the create context is implied but not explicitly contrasted.
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 indicate readOnlyHint=true, but the description adds valuable context by disclosing that monetary metrics are converted from micros to whole currency units, which is a non-obvious behavior. It also scopes the report to ad sources and mediation groups, giving useful operational context beyond the annotation.
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 main purpose, and includes a useful note about currency conversion. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 8 parameters and no output schema, but the description covers the core purpose, scope, and key metrics. It does not describe the return format or pagination, but the schema provides parameter details, and the readOnly annotation covers safety. The description is reasonably complete for a report generator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 8 parameters with descriptions (100% coverage), so the description does not need to explain parameters. The description does reference currencyCode and key dimensions, but adds little beyond what the schema already provides. 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 generates an AdMob Mediation report, specifying the scope (across ad sources, waterfall/bidding) and key metrics (impressions, estimated earnings, observed eCPM). This distinguishes it from sibling tools like generate_network_report and generate_campaign_report by focusing on mediation-specific dimensions and metrics.
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: it is for AdMob mediation reporting, which implicitly signals when to use this tool over network or campaign reports. However, it does not explicitly mention alternatives or state when not to use it, so it falls short of a 5.
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 indicate a non-read-only operation. The description adds the 'admob.monetization' scope requirement, which is valuable behavioral context beyond the annotation. It does not detail side effects (e.g., irreversibility), but this is acceptable given the annotation coverage.
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 the scope requirement is stated succinctly. Every word earns its place without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with thorough schema and annotation coverage, the description covers the essential action, method, and authorization. It does not mention the return value, but since there is no output schema, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with 100% description coverage, so the baseline is 3. The description's mention of 'choosing the winning variant' aligns with variantChoice but does not add additional semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Stops' and clearly identifies the resource ('running A/B experiment on a mediation group') and the method ('by choosing the winning variant'). This distinctly separates it from sibling tools like create_mediation_ab_experiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context that this is for stopping an active experiment and states the required authorization scope. However, it does not explicitly describe when not to use it or mention alternative tools.
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 readOnlyHint annotation already signals a safe read operation. The description adds valuable context about the output shape (fields returned), which is not covered by annotations. It does not disclose pagination behavior or other side effects, but for a read-only list tool with annotated safety, this 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 a single, front-loaded sentence that states the verb, resource, and key return fields without waste. Every piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a read-only annotation, fully described parameters, and no output schema, the description is complete. It clearly states what the tool returns and the scope ('apps registered in the AdMob account'), covering the essential information an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (pageSize, pageToken) are fully described in the schema. The description does not add any additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Lists' and clearly identifies the resource: 'apps registered in the AdMob account'. It also enumerates the returned fields (app ID, platform, store link state, approval state), which distinguishes it from sibling tools like list_accounts and list_ad_units that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: when you need the list of apps in the AdMob account. It does not explicitly mention alternatives or exclusions, but the resource specificity and sibling list make the context clear. This aligns with 'clear context, no exclusions'.
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?
Beyond the readOnlyHint=false annotation, the description discloses a specific authorization requirement ('Requires the admob.monetization scope') and clarifies the adapter-based linkage behavior. It does not detail side effects, but for a create operation the core behavior is adequately covered.
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, purposeful sentences: the first states the action, the second gives a prerequisite, the third states the required scope. No fluff, front-loaded.
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?
With four parameters including a nested object, the description covers purpose, prerequisite, and auth. It does not mention return values, but since there is no output schema, that omission is a minor gap for a straightforward create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds valuable context by instructing that adapterId and adUnitConfigurations keys come from list_adapters, which helps the agent correctly populate these 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 states a specific verb (creates), a clear resource (ad unit mapping), and the exact linkage (AdMob ad unit to third-party network placement via adapter). This distinguishes it from siblings like list_ad_unit_mappings and create_app.
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 tells the agent to get the adapter ID and configuration keys from list_adapters, providing a clear prerequisite and pointing to a complementary tool. However, it does not explicitly state when not to use this tool or mention alternative mapping creation paths.
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 required OAuth scope (admob.monetization), which is useful beyond the annotation readOnlyHint=false. It also implies the write nature of the operation. It doesn't describe side effects like visibility of the created app, but the annotation plus scope note provide adequate 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?
Two clear sentences, front-loaded with the main action, then a concise explanation of the two usage modes. No redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers purpose, usage modes, and auth scope. It lacks an explicit mention of return value, but output schema is absent and for a create operation this is generally understood. The description is complete enough for the agent to select and 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?
Schema coverage is 100% with descriptions for all three parameters. The description adds semantic value by explaining the relationship between appStoreId and displayName (linking a published listing vs registering an unpublished app), which goes beyond the schema's individual parameter 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 'Creates an app in the AdMob account' with a specific verb and resource, and it distinguishes the tool from siblings like create_ad_unit or list_apps by focusing on app creation. The two modes (appStoreId vs displayName) further clarify the exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use appStoreId (published apps) versus displayName (unpublished apps). While it doesn't explicitly exclude alternatives, the tool's purpose is distinct and the parameter guidance effectively tells the agent which mode to choose based on the app's status.
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 adds meaningful behavioral context beyond the readOnlyHint annotation: the date range restriction and the conversion of monetary metrics from micros to whole currency units. This helps the agent understand data transformations and constraints not evident from the annotation or schema alone.
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 concise sentences. It front-loads the action and then provides two essential constraints. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and lack of an output schema, the description covers the core purpose, key constraints, and metric conversion behavior. It does not describe the exact response format (e.g., CSV, JSON), but the metrics and date range are sufficiently defined. The currencyCode reference and missing output details slightly lower the score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra semantic value by explaining that startDate/endDate must be within the last 30 days and that monetary metrics are micro-converted. However, the reference to 'currencyCode' is confusing because this property does not appear in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a report for AdMob cross-promotion campaigns, listing key metrics (impressions, clicks, installs, estimated cost). It distinguishes itself from sibling tools like generate_network_report and generate_mediation_report by specifying 'cross-promotion 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 gives clear context: use this for cross-promotion campaign reports. It also provides an important constraint (date range within last 30 days). It does not explicitly name alternatives or say when not to use it, but the 'cross-promotion' qualifier and sibling names implicitly differentiate usage.
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 adds the required admob.monetization scope, which is not present in annotations (only readOnlyHint: false). It also communicates partial-update semantics via 'Patches' and the updateMask example, providing useful behavioral context beyond the minimal annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. The example and scope requirement are included without 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?
The tool has 3 required parameters, a nested object, and a field mask pattern; the description adequately explains the usage pattern and required scope. It does not mention return values, but this is a patch operation where the response is likely the updated resource, and no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description enhances understanding by explicitly linking mediationGroup and updateMask, clarifying how they work together. The example 'display_name,targeting.ad_unit_ids' adds practical value beyond the schema 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 begins with 'Patches a mediation group', which is a specific verb and resource, clearly indicating an update operation. It distinguishes itself from sibling tools like create_mediation_group (create) and list_mediation_groups (read) by focusing on patching existing groups.
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 clearly implies usage for updating existing mediation groups and provides practical instructions (pass fields in mediationGroup, list paths in updateMask). It does not explicitly name alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![admob-mcp-server MCP server](https://glama.ai/mcp/servers/ParkSangGwon/admob-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ParkSangGwon/admob-mcp-server)

Score Badge

Copy to your README.md:

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

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