admob-mcp

by jerry2247

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are generally distinct with clear actions targeting different entities, but the pair of create_ad_unit_mapping and batch_create_ad_unit_mappings overlap in purpose, causing minor ambiguity.
Naming Consistency5/5
All tools follow a consistent 'admob_verb_noun' pattern in snake_case, with verbs like list, create, update, run, stop, and get, making the set highly predictable.
Tool Count5/5
With 19 tools covering account, app, ad unit, mediation group, and reporting operations, the count is well-scoped for an AdMob management server, not too many or too few.
Completeness2/5
The set lacks delete operations for apps, ad units, and mediation groups, and missing updates for apps and ad units, leaving significant gaps that could hinder typical workflows.
Average 3.8/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, which convey safety and potential large results. The description does not add behavioral details like pagination behavior, authorization needs, or rate limits. Minimal 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without wasted words. However, it is too terse, lacking necessary detail for a tool with multiple parameters. Not excessively long, but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, list operation, pagination), the description is incomplete. It does not explain pagination, sorting, or filtering. The absence of an output schema increases the need for description content, which is missing.
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 40% (2 of 5 parameters have descriptions). The tool description does not elaborate on any parameters. It does not compensate for the low schema coverage, leaving parameters like 'all', 'pageSize', 'pageToken' unexplained.
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 verb 'List', the resource 'ad unit mappings', and the scope 'under one ad unit'. It distinguishes from create/batch siblings, though not explicitly. The purpose is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like admob_create_ad_unit_mapping. No mention of prerequisites, context, or when not to use. The description is purely declarative.
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 description's main behavioral addition is that only the most recently signed-in account is returned. This adds context beyond annotations but is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and front-loaded with the action. However, it sacrifices parameter explanation for brevity, which is a minor flaw.
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?
For a simple list tool with readOnly annotations, the description covers core behavior but lacks parameter details and output format clarity. The openWorldHint annotation is present but not explained, potentially causing confusion.
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 tool description does not mention the two parameters (pageSize, pageToken) at all, leaving the agent with no additional semantic guidance beyond the schema's basic constraints.
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 the AdMob publisher account, specifically the most recently signed-in one. This provides a precise verb-resource combination and distinguishes from sibling tools like 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like get_account. No context on scenario exclusions or prerequisites is given.
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 and openWorldHint=true. The description adds that the tool returns ad source id and title, but does not disclose pagination behavior or other traits. It adds some value but not rich behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 20 words, concise and front-loaded. It could be improved by adding pagination details, but it is not verbose.
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?
The description is incomplete given the tool has 3 parameters, low schema coverage, and no output schema. It does not explain the return structure beyond id and title, nor does it mention pagination behavior.
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 only 33% (only publisherId has a description). The tool description does not explain pageSize or pageToken parameters, nor does it mention pagination. With low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'mediation ad sources available to the AdMob account', and indicates what information is returned (id and title). It is distinct from sibling tools like admob_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention scenarios where this tool would be inappropriate. The sibling list includes many similar list tools, but no differentiation 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 and openWorldHint=true. The description adds that the tool lists ad units and includes specific fields, but does not disclose pagination behavior or any additional constraints beyond the 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 no wasted words. Every phrase adds value, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has pagination parameters and no output schema, the description is incomplete. It does not explain how pagination works, the use of 'all' flag, or the return format, leaving the agent with gaps.
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 50% (descriptions for 'all' and 'publisherId' but not for 'pageSize' and 'pageToken'). The tool description does not add any parameter semantics beyond the schema, missing the opportunity to explain pagination parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ad units under an AdMob account, specifies the verb 'List', the resource 'ad units', and details the fields included (id, parent app id, format, ad types). This distinguishes it from sibling tools like admob_list_ad_unit_mappings and admob_list_apps.
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 provide any guidance on when to use this tool versus alternatives, nor when not to use it. It lacks context for selection among siblings.
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 indicate destructive hint, and the description adds behavioral context about the dryRun parameter, including the confirmation flow. However, it does not disclose potential side effects or irreversible changes beyond what annotations imply.
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 at two sentences, front-loaded with the purpose, and every sentence adds value without redundancy.
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?
For a creation tool with 6 parameters and nested objects, the description covers key structural guidance but lacks explanation of return values, prerequisites (e.g., access requirements), or side effects for a destructive operation. Output schema is missing, and the description does not address this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for dryRun (validation mode), targeting and mediationGroupLines (supply as objects following schema), and publisherId (format/defaults). With 67% schema coverage, these additions compensate well, though some parameters like displayName lack extra context.
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 'Create a mediation group' with the API version and allowlist status, specifying the verb and resource. It differentiates from siblings like 'admob_update_mediation_group' but could be more explicit about the overall function.
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 by mentioning the MediationGroup schema and providing parameters, but does not explicitly state when to use this tool versus alternatives like 'admob_update_mediation_group' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds context about the report scope (earnings and performance across mediated sources). While it doesn't elaborate on potential rate limits or data freshness, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and required inputs. It is concise without waste. However, it could be more structured (e.g., separating purpose from usage hints), but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description is somewhat brief. It adequately identifies the report type but does not hint at output structure or additional considerations like date range limitations. While schema coverage compensates, more context on report behavior (e.g., pagination) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented including defaults, formats, and allowed values. The description adds minimal extra meaning beyond stating the need for date range, dimensions, and metrics, which is already clear from the schema. Thus 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 focusing on earnings and performance across mediated ad sources. It distinguishes from sibling tools like admob_run_campaign_report and admob_run_network_report by specifying 'mediation' report, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions providing a date range, dimensions, and metrics, which implies usage. However, it does not explicitly guide when to use this tool versus siblings like campaign or network reports, nor does it state prerequisites or exclusions. The readOnlyHint annotation is helpful but not utilized in the description.
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 mark the tool as read-only and open-world. The description adds behavioral context by detailing the EBNF filter expression and the fields supported (DISPLAY_NAME, STATE, PLATFORM, FORMAT), which helps the agent understand filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical, front-loaded with the main action. It is concise without wasting words, though it could be more structured to highlight the filter feature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five parameters and no output schema, the description explains the listing action and filter but omits pagination details and parameter use cases. It is minimally complete but leaves gaps.
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?
With only 40% schema description coverage, the description adds some meaning for the 'filter' parameter (EBNF expression and fields) but does not clarify 'all', 'pageSize', 'pageToken', or 'publisherId' beyond what minimal schema descriptions 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 action ('List') and the resource ('mediation groups under an AdMob account'). It differentiates from sibling tools like 'admob_create_mediation_group' by focusing on listing, and adds specificity with the optional EBNF filter expression and allowable fields.
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 listing mediation groups, not creating or updating, but lacks explicit guidance on when to use this versus other list tools (e.g., list_ad_units). There is no mention of alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds no further behavioral traits (e.g., potential large output, time limits), so it meets but does not exceed the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states purpose, second tells what to provide. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic input requirements but omits details about the output format or how the report is returned. With 10 parameters and no output schema, a brief note on the result structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description only adds a high-level summary (date range, dimensions, metrics), which is minimally helpful 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 it generates an AdMob Network report for first-party network earnings and performance, distinguishing it from sibling report tools like campaign or mediation reports.
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 when to use (for network reports) but does not explicitly compare to sibling tools like admob_run_campaign_report or admob_run_mediation_report, nor provides when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's 'Create' adds no new behavioral context. It mentions the limit of 100 but does not disclose other traits like failure behavior or idempotency beyond what annotations provide.
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 concise sentences with the key information front-loaded: action, resource, batch limit, and constraint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and constraints. With no output schema, it could be improved by mentioning the return value (e.g., list of created mappings) or error handling, but it is sufficient for a simple batch creation 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 coverage is 100%, so the schema already documents all parameters. The description adds the context that all mappings must target ad units under the same account, which provides some additional meaning but is not critical.
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 'Create', the resource 'ad unit mappings', and the batch scope with a limit of 100. It distinguishes from the sibling 'admob_create_ad_unit_mapping' by specifying batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for batch creation (when multiple mappings need to be created) and mentions 'v1beta, allowlisted' indicating restricted access. However, it does not explicitly state when not to use or provide alternatives like the single mapping tool.
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 openWorldHint=true, so safety is known. The description adds value by specifying the fields returned and describing pagination behavior ('Set all=true to page through every app (capped for output size)'). No contradictions.
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 well-structured sentences with front-loaded action. Every sentence adds value: first states purpose and included fields, second gives usage guidance on pagination. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 4 parameters and no output schema, the description is fairly complete. It covers the basic functionality, fields returned, and pagination behavior. It could mention default behavior when all=false or other edge cases, but overall it provides sufficient 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 coverage is 50% (two params have descriptions). The description explains the 'all' parameter's effect, which adds meaning beyond the schema's 'Follow pagination and return all apps (capped)'. However, it does not address 'pageSize' or 'pageToken', which are common but not described. The 'publisherId' parameter has a schema description but is not mentioned in the tool description.
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 it lists apps under an AdMob account and specifies the fields included (app id, platform, approval state). The verb 'list' and resource 'apps' are specific. It doesn't explicitly distinguish from sibling list tools, but the name and resource difference make it clear.
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 provides guidance on using 'all=true' for pagination with a cap, but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied by the tool's resource focus.
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 indicate readOnlyHint false, openWorldHint true, and destructiveHint true. The description states 'Create a new app', which aligns with a write operation but does not mention destructive behavior. The allowlisting and dryRun features add some behavioral context, but the destructiveHint contradiction reduces clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no unnecessary words. Every sentence provides critical information.
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?
No output schema; the description does not state what the tool returns (likely the created app). Given the destructiveHint annotation, more context about side effects or irreversibility would be beneficial. The description covers inputs well but lacks output and side-effect details.
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 parameters are well documented. The description adds value by explaining the dryRun parameter's purpose (preview request) and mentioning default publisherId from environment, going 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?
Title and description clearly state 'Create a new app under an AdMob account', specifying the verb 'create' and resource 'app'. This distinguishes it from sibling tools that create ad units, mediation groups, etc.
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 explicit guidance on when the tool can be used: it is allowlisted, so a 403 indicates lack of access. It also mentions using dryRun to preview requests. However, it does not explicitly state when not to use or list 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 indicate readOnlyHint=true, and the description confirms a read operation. It adds behavioral context by explaining the output's role in creating mappings, which is beyond the 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?
Two sentences with no wasted words, front-loading the core purpose and then adding necessary explanatory context.
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?
Lacks output schema but the description explains what the output contains. Annotations cover safety. Could be more explicit about the list format but sufficient for the task.
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 50% (2 of 4 parameters described). The description does not add extra parameter meaning beyond the schema; it focuses on output behavior. 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 'List the adapters for one ad source' with a specific verb and resource. It explains the purpose of adapters and distinguishes this tool from siblings by focusing on adapter listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to get adapterId and adapterConfigMetadata for creating mappings) and provides context but does not explicitly list when not to use it or 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?
Annotations already declare readOnlyHint and openWorldHint. Description adds: 'date range limited to 30 days' and 'response is a single set of rows (no streaming)', which are useful behavioral details beyond 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?
Two sentences, no extraneous information. First sentence states purpose, second adds key constraints. Efficient and 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?
Given 7 parameters, high schema coverage, and readOnlyHint/openWorldHint annotations, description covers version, data range, and response format adequately.
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 86%, so baseline is 3. Description does not add meaning beyond schema; date range limit is already in 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?
Clearly states 'Generate an AdMob campaign (App Campaigns) report' with specific verb and resource. Differentiates from sibling tools like run_mediation_report by specifying 'campaign'.
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 version constraint 'v1beta only' and behavioral constraints (date range limit, single row set) but does not explicitly state when to use this 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=false, destructiveHint=true, idempotentHint=true. The description adds useful context: it's a patch operation, updateMask is required, repeated fields are fully replaced, and it's 'allowlisted'. No contradiction with 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?
Two sentences without redundancy. The first sentence states the purpose immediately. Every part adds value: method, updateMask requirement, replacement behavior, and reference to docs for mask paths.
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 has 5 parameters, high schema coverage, and annotations covering safety, the description is adequately complete. It explains key behavioral aspects (updateMask, repeated fields) but omits return value info (no output schema) and prerequisites, though these are partially covered by schema and context.
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 80%, providing decent baseline. The description adds value by explaining updateMask behavior (required, selects fields, repeated fields replaced) beyond the schema's example. This helps the agent understand the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a mediation group, specifies it uses v1beta patch, and distinguishes from create_mediation_group sibling. The verb 'update' and resource 'mediation group' are explicit.
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 updating mediation groups but does not provide explicit guidance on when to use versus alternatives like create_mediation_group. No when-not-to-use or prerequisite information is given.
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 openWorldHint=true. The description adds value by specifying the exact details returned (publisher id, time zone, currency code). No contradictions; it could mention error handling but is sufficient given 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?
A single sentence, 16 words, that efficiently conveys purpose and output without waste.
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 the tool has one optional parameter, readOnly and openWorld annotations, and no output schema, the description is complete enough for an agent to understand its use and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats some fields returned but does not add meaning beyond the schema's parameter description for publisherId.
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 'Get details for one AdMob publisher account' and lists specific fields returned (publisher id, time zone, currency code). This distinguishes it from sibling tool admob_list_accounts which lists multiple accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single account, and the presence of admob_list_accounts as a sibling suggests when to use each. However, no explicit when-not-to-use or alternatives are given, though context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds context by explaining the effect of each variant choice (keeping original vs. adopting new lines), providing behavioral insight beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and each sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description is missing details about post-action effects (e.g., whether experiment is immediately stopped), prerequisites, and ignores mediationGroupId. This leaves gaps for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%; the description adds value by explaining the meaning of variantChoice values ('keeps original' vs. 'adopts newly added lines'), which goes beyond the schema's enum. However, mediationGroupId lacks description in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool stops a running A/B experiment and picks a winning variant, identifying the verb 'stop' and the resource 'mediation group A/B experiment'. It distinguishes from sibling tool admob_create_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?
Description explicitly says when to use: when you have a running experiment and want to conclude it by selecting a variant. It does not provide explicit when-not-to-use or alternatives, but the context is clear and the sibling list includes the creation counterpart.
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 indicate destructiveHint=true and readOnlyHint=false. The description aligns, noting creation is performed unless dryRun is true. It adds the allowlist requirement and preview capability, which are beyond annotation scope. No contradiction.
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 deliver purpose, allowlist note, and dryRun guidance. Every sentence adds unique information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers key aspects: creation, allowlist, dryRun. With 8 parameters fully described in schema and annotations, this is sufficient for a creation tool. Missing return value detail is a minor gap.
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%, but the description adds value by explaining dryRun's default behavior ('operation runs after MCP client asks you to confirm') and publisherId defaults. This augments 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 name and title clearly indicate creating an ad unit. The description specifies 'under an app (v1beta)' and mentions the dryRun option. Among sibling tools, this is the only ad unit creation tool, so it is well-distinguished.
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 states that the method is allowlisted and that a 403 means no access. It also advises using dryRun to preview requests. While it does not explicitly compare to siblings, the context implies it is for creation when access is granted.
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 mark this as non-readOnly and destructive. The description adds that a dryRun parameter can be used to validate without executing, and that the operation runs after confirmation from the client. This goes 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?
Two concise sentences: first states purpose and constraints, second explains key parameter relationships. No filler, 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?
Given the complexity (6 params, nested object, no output schema), the description covers the creation process, parameter dependencies, and the dryRun behavior. Missing output details but acceptable without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema coverage, the description adds significant meaning for adapterId and adUnitConfigurations by specifying their sources. DryRun and publisherId are already covered in schema. AdUnitId and displayName lack extra info, but overall adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an ad unit mapping connecting one ad unit to a mediation adapter, specifying the version and allowlist restriction. It distinguishes from sibling tools like the batch variant.
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 guidance on where to obtain adapterId (from admob_list_adapters) and that adUnitConfigurations keys come from adapterConfigMetadataId. Lacks explicit when-to-use vs. alternatives but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, matching the mutation nature. The description adds behavioral context: dryRun behaves as a validation mode, and the default execution requires confirmation. It also discloses the single-experiment-per-group limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The purpose is front-loaded, and additional details (inheritance, limit, monitoring) are efficiently packed into the second sentence.
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 6 parameters (4 required) and no output schema, the description covers the core purpose, constraints, and dryRun behavior. It references a sibling tool for monitoring. While return value is not described, the agent can infer it from the action. Minor gap in explaining what happens post-experiment.
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 67% schema coverage, the description adds meaning beyond the schema. It clarifies that control lines are inherited (eliminating that param guesswork) and mentions the key params (treatment lines, traffic percentage). The dryRun param gets extra context in the description about confirmation requirement.
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 ('Start an A/B experiment') and resource ('mediation group'), clearly distinguishing from siblings like admob_stop_ab_experiment. It adds scope details (v1beta, allowlisted) and automatic control line inheritance.
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 explains when to use the tool (to start an experiment) and provides a constraint ('Only one experiment can run per group at a time'). It also suggests monitoring via admob_list_mediation_groups. No explicit exclusion, but context is clear.
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 MCP server](https://glama.ai/mcp/servers/jerry2247/admob-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jerry2247/admob-mcp)

Score Badge

Copy to your README.md:

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

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