Provides complete control over Google AdMob REST API, enabling management of accounts, apps, ad units, mediation groups, A/B experiments, bidding mappings, and performance reporting.
Allows creation of bidding mappings to associate Meta Audience Network placement IDs with AdMob ad units.
Allows creation of bidding mappings to associate Unity Ads placement IDs with AdMob ad units.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@admob-manager-mcp list my AdMob apps"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An enterprise-grade Model Context Protocol (MCP) server providing complete control over Google AdMob REST API (v1beta). Designed for AI Agents (Claude Desktop, Cursor, Antigravity/AGY) to automate AdMob publisher account management, apps, ad units, mediation groups, A/B experiments, bidding ad unit mappings, and performance reporting.
19 Complete REST API Tools: Full matrix covering Accounts, Apps, Ad Units, Ad Unit Mappings, Mediation Groups, A/B Experiments, and Performance Reports.
Zero-Config Auto Browser OAuth 2.0: Embedded Google OAuth 2.0 Client credentials (w3wide-auth-services). Automatically opens your system browser for one-click Google AdMob login when unauthenticated.
Auto Silent Token Refresh: Tokens are cached at ~/.config/admob-manager-mcp/tokens.json and silently refreshed automatically.
Resilient 401/403 Auto-Retry: If tokens expire or permissions change, the server purges cached tokens and seamlessly re-prompts browser authorization.
Dual Transport Mode: Supports both standard Stdio transport (npm run mcp) and Streamable HTTP transport with MCP v2 Native Auth (npm run mcp:http).
Third-Party Bidding Mapping: Associate Meta Audience Network, Unity Ads, AppLovin, and ironSource Placement IDs with AdMob Ad Units.
Related MCP server: AdMob MCP Server
npx @w3wide/admob-manager-mcpnpm install -g @w3wide/admob-manager-mcp
admob-manager-mcpAdd the following to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"admob-manager": {
"command": "npx",
"args": ["-y", "@w3wide/admob-manager-mcp"]
}
}
}.cursor/mcp.json or Global Settings)Add to .cursor/mcp.json in your project or global Cursor MCP settings:
{
"mcpServers": {
"admob-manager": {
"command": "npx",
"args": ["-y", "@w3wide/admob-manager-mcp"]
}
}
}mcp.json)Create mcp.json in your workspace directory:
{
"mcpServers": {
"admob-manager-mcp": {
"command": "node",
"args": ["/absolute/path/to/admob-manager-mcp/dist/index.js"]
}
}
}Embedded OAuth Client: Out of the box, the server uses embedded Google OAuth 2.0 Client credentials linked to w3wide-auth-services GCP project.
First Run: When an AI agent executes an AdMob tool, if ~/.config/admob-manager-mcp/tokens.json does not exist:
The server spins up a local callback listener on http://localhost:3000/oauth2callback.
Your default browser automatically pops up Google's OAuth consent screen.
Select your Google Account and click Allow.
Tokens are saved locally, and all future tool calls execute seamlessly.
Tool Name | Description | Key Parameters |
| Get AdMob publisher account details |
|
| List all AdMob publisher accounts |
|
| List supported ad sources for mediation |
|
| List adapters for a specific ad source |
|
| List all apps linked to publisher account |
|
| Create a new AdMob app |
|
| List ad units for an account |
|
| Create a new Banner/Interstitial/Rewarded ad unit |
|
| List bidding mappings for an ad unit |
|
| Create bidding mapping for Meta/Unity/AppLovin |
|
| Batch create up to 100 ad unit mappings |
|
| List mediation groups |
|
| Create a mediation group |
|
| Update an existing mediation group |
|
| Start an A/B mediation experiment |
|
| Stop an active A/B experiment |
|
| Generate AdMob Network performance report |
|
| Generate Mediation revenue & match rate report |
|
| Generate Campaign performance report |
|
Inspect and test all tools interactively in your browser:
npm run inspectorOpens http://localhost:5173 (or active inspector port) with full tool execution UI and parameter schema validation.
This project is licensed under the MIT License.
Batch create ad unit mappings (Max 100 items per call).
| Name | Required | Description | Default |
|---|---|---|---|
| requests | Yes | Array of ad unit mapping creation requests (max 100). | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses the batch nature and item limit. It fails to mention whether the operation is idempotent, what happens on partial failure, or any authentication requirements, leaving significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that covers the core purpose and a key constraint, with no wasted words. It could be improved by adding a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch creation with nested objects and no output schema, the description is insufficient. It does not explain return values, error handling, or provide enough context for an agent to understand the full lifecycle of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no new parameter meaning beyond what the schema provides. The 'Max 100 items per call' is already reflected in the schema's maxItems constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'batch create' and the resource 'ad unit mappings', giving a specific verb and target. It implicitly distinguishes from the sibling single-create tool, though it could be more explicit about the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a max 100 items per call limit, but provides no guidance on when to use this batch tool vs the single creation sibling, nor any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new ad unit under an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | Target AdMob App ID (e.g. ca-app-pub-1234567890123456~1234567890). | |
| format | No | Alias for adFormat. | |
| adTypes | No | Supported ad types (e.g. ["RICH_MEDIA", "VIDEO"]). | |
| adFormat | No | Ad format type. | |
| displayName | Yes | Display name of the ad unit. | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description solely conveys 'Create', which implies mutation but lacks any behavioral details such as returned identifier, permissions, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, perfectly concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description lacks context about required inputs (appId, displayName), return value, or relationship to sibling tools, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing clear parameter descriptions. The tool description adds no extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new ad unit under an AdMob publisher account'), distinguishing it from sibling tools like createAdmobAdUnitMapping or createAdmobApp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites or when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an ad unit mapping for a specific ad unit.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State of the mapping. | |
| adapterId | Yes | Adapter ID for mediation. | |
| adUnitName | Yes | Ad unit resource name (e.g. accounts/pub-1234567890123456/adUnits/9876543210). | |
| adUnitConfigurations | No | Key-value configuration parameters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits. It states 'create' implying mutation, but doesn't address permissions, reversibility, side effects, or whether existing mappings are affected. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. However, it is overly terse and could benefit from more context without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 4 parameters, and no annotations, the description is incomplete. It doesn't explain return behavior, success/failure indicators, or any constraints (e.g., uniqueness of mappings). The tool is a creation operation but lacks sufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no additional meaning about parameters beyond what the schema already provides (e.g., adUnitName, adapterId). It doesn't clarify how parameter values interact or what constitutes valid configurations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'create' and resource 'ad unit mapping'. It specifies 'for a specific ad unit', which helps distinguish from the sibling batchCreateAdmobAdUnitMappings. However, it doesn't elaborate on what an ad unit mapping is or how it relates to other concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., batchCreateAdmobAdUnitMappings). No prerequisites, context, or conditions for use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new app under an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Platform of the app. | |
| appStoreId | No | App Store or Play Store ID if linked to store. | |
| displayName | No | Display name for manual app creation. | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'create' with no disclosure of side effects, idempotency, error behavior, or auth requirements. Agent cannot infer safety or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence, no wasted words. However, could be slightly expanded with behavioral context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema and no annotations, the description lacks behavioral completeness. Does not explain what is created, how to verify success, or implications of missing optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented in the schema. The description adds no extra meaning beyond what schema provides, earning baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'new app', and the context 'under an AdMob publisher account'. It distinguishes from sibling tools like listAdmobApps or getAdmobAccount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Lacks prerequisites (e.g., need a publisher account) or conditions where other tools (like listAdmobApps) should be considered first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an A/B experiment for a mediation group.
| Name | Required | Description | Default |
|---|---|---|---|
| displayName | Yes | Display name of the experiment. | |
| variantChoice | No | Variant choice if applicable. | |
| mediationGroupName | Yes | Mediation group resource name (e.g. accounts/pub-1234567890123456/mediationGroups/9876543210). | |
| treatmentTrafficPercentage | Yes | Percentage of traffic allocated to treatment (0 to 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'Create an A/B experiment' with no disclosure of side effects (e.g., does it overwrite existing experiments?), permissions required, or whether the operation is reversible. This is insufficient for a tool that modifies traffic allocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 9 words, no fluff. Front-loaded with the action. However, it could incorporate more information without becoming verbose. Still, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (3 required) and no output schema, the description is too sparse. It does not explain what the tool returns (e.g., the created experiment resource), prerequisites (existing mediation group), or constraints (e.g., only one experiment per group?). This leaves agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has clear descriptions. The tool description adds no additional meaning beyond what's in the schema (e.g., it does not explain differences between parameters like variantChoice vs treatmentTrafficPercentage). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'an A/B experiment for a mediation group.' It distinguishes from siblings like createAdmobMediationGroup (creates a group, not an experiment) and stopAdmobMediationAbExperiment (stops, not creates). However, it could specify that this is specifically for A/B experiments, which is already implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to stop an experiment or create a mediation group). The description does not mention prerequisites, such as requiring an existing mediation group, which is only implicit in the required parameter mediationGroupName.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new mediation group in an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State of the group. | |
| displayName | Yes | Display name of the mediation group. | |
| publisherId | No | AdMob Publisher ID or resource name. | |
| targetedAppIds | No | List of targeted app IDs. | |
| mediationGroupLines | No | Mediation group lines configuration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action (create) without disclosing behavioral traits such as whether it modifies data, required permissions, rate limits, or side effects. For a mutating operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action. Every word is necessary; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters (one required) and nested objects, the description is minimal. It does not explain how parameters relate, what the response contains, or any prerequisites. A lengthier description would be beneficial for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents each parameter's meaning. The description adds no additional semantic value beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies to 'create' a 'mediation group' in an 'AdMob publisher account'. This verb+resource+context combination distinguishes it from sibling tools like 'listAdmobMediationGroups' and 'patchAdmobMediationGroup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied (when you need to create a new mediation group), but there is no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. No prerequisites or contextual hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate AdMob Campaign performance report (Date range between startDate and endDate cannot exceed 30 days).
| Name | Required | Description | Default |
|---|---|---|---|
| reportSpec | Yes | ||
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the date range constraint, but does not state whether the operation is read-only, what happens if the limit is exceeded, whether it returns report data or a job ID, or any authentication requirements. For a report generation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that front-loads the verb and resource. While it could be slightly more structured, it contains no extraneous information and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, no output schema, no annotations), the description is too sparse. It fails to explain what the report contains, how to handle the date range limit, or what the response format is. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, meaning half of the parameters have descriptions. The description adds one key constraint (date range <=30 days) beyond the schema, which provides some guidance on valid input. However, it does not clarify the structure of the dateRange object or suggest typical values for metrics/dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates an AdMob campaign performance report, which distinguishes it from sibling tools like listAdmobAccounts or generateAdmobMediationReport. However, it does not explicitly differentiate from similar report-generation tools like generateAdmobNetworkReport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides a single usage constraint: the date range cannot exceed 30 days. It offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. This is minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate AdMob Mediation performance report. Revenue values are in micros ($1 USD = 1,000,000 micros).
| Name | Required | Description | Default |
|---|---|---|---|
| reportSpec | Yes | ||
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full weight. It reveals that revenue values are in micros, which is useful, but omits critical behavioral details such as whether the operation is read-only, required permissions, rate limits, or the report's output format. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences with no redundant information. The core purpose and the crucial micros detail are front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested input schema and no output schema, yet the description provides no context on what the report returns, how to interpret results, or the relationship to siblings. It is incomplete for an agent to reliably generate and consume the report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only metrics and dimensions having descriptions. The description adds the key semantic that revenue values are in micros, which is not in the schema. However, it does not explain other parameter semantics like default metrics or date range restrictions, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 performance report. It uses a specific verb 'generate' and resource, and the name differentiates it from sibling report tools like generateAdmobCampaignReport and generateAdmobNetworkReport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 generateAdmobCampaignReport or generateAdmobNetworkReport. The description does not mention prerequisites, exclusions, or typical use cases, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate AdMob Network performance report. Revenue values are in micros ($1 USD = 1,000,000 micros). AD_TYPE dimension cannot be combined with AD_REQUESTS, MATCH_RATE, or IMPRESSION_RPM.
| Name | Required | Description | Default |
|---|---|---|---|
| reportSpec | Yes | ||
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only mentions revenue units in micros and a dimension restriction. Missing: auth needs, rate limits, output format, side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. First sentence states purpose, second adds two critical notes. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of the report output format/structure, which is critical since there is no output schema. Also missing: permissions, rate limits, or any usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description adds value by explaining micros for revenue metrics and the AD_TYPE incompatibility. However, it does not clarify other parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates an 'AdMob Network performance report,' specifying the resource and action. Distinguishes from sibling report tools (mediation, campaign) by naming the network report type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives like generateAdmobMediationReport or generateAdmobCampaignReport. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch AdMob publisher account details (publisher ID, currency code, reporting time zone) from Google AdMob REST API v1beta accounts endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| publisherId | No | AdMob Publisher ID (e.g. pub-1234567890123456) or account resource name (e.g. accounts/pub-1234567890123456). If omitted, fetches default account or lists accessible publisher accounts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool queries the Google AdMob REST API v1beta accounts endpoint and returns specific fields. However, it does not mention permissions, rate limits, or that omitting publisherId may fetch default account or list accounts (though that is in schema description). It adds some context but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 20 words, front-loading the purpose and explicitly listing the data fields. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input and no output schema, the description provides the core purpose and data returned. However, it does not explain the behavior when publisherId is omitted (e.g., returns default account or lists), nor does it describe the return format. Some completeness is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the parameter's behavior (omitting fetches default or lists accounts). The tool description does not add additional meaning about the parameter beyond what's in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single AdMob account details (publisher ID, currency code, reporting time zone) from a specific API endpoint. The verb 'Fetch' and resource 'AdMob publisher account details' are specific, and the tool naturally distinguishes from sibling 'listAdmobAccounts' 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.
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. It does not mention when to use listAdmobAccounts instead, nor does it specify any prerequisites or limitations. The inferring from naming convention is insufficient for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List accessible AdMob publisher accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum number of accounts to return. | |
| pageToken | No | Pagination token from previous call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It only mentions 'accessible', implying permissions, but does not disclose pagination behavior, rate limits, or whether the response is complete or filtered. Insufficient for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is appropriately concise for a simple list operation, but could benefit from a bit more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional parameters and no output schema, the description does not explain the response format or typical use cases. It lacks completeness for a List operation that may return paginated results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter (pageSize, pageToken) already has descriptions. The tool's description adds no further insight beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'AdMob publisher accounts', distinguishing it from siblings like listAdmobAdUnits or getAdmobAccount. It is specific but could be more precise about the scope (e.g., 'all accessible').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like getAdmobAccount for a single account, or when not to use it. The description lacks any contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ad source adapters for a given ad source.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum number of items to return. | |
| pageToken | No | Pagination token. | |
| adSourceParent | Yes | Resource name of the ad source (e.g. accounts/pub-1234567890123456/adSources/54321). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states 'List', implying a read-only operation. No additional behavioral details such as authentication needs, rate limits, or data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, entirely front-loaded. Every word is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple list tool with no output schema. The description does not explain pagination, return fields, or any post-condition. It is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters. The description does not add any extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (ad source adapters) and specifies the scope (for a given ad source). It distinguishes this tool from sibling tools that list other AdMob resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites or exclusions mentioned. The agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ad sources in an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum number of items to return. | |
| pageToken | No | Pagination token. | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it lists ad sources; does not disclose pagination behavior, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded. Could be more informative but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, description fails to provide enough context for safe invocation. Missing details on required parameters (publisherId), pagination, and response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds no extra meaning beyond parameter descriptions in schema. No improvement or degradation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'List' and resource 'ad sources' with clear scope 'in an AdMob publisher account'. Clearly distinguishes from sibling tools like listAdmobAccounts or listAdmobAdUnits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, when not to use, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ad unit mappings for a specific ad unit.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | EBNF filter expression. | |
| pageSize | No | Maximum number of items to return. | |
| pageToken | No | Pagination token. | |
| adUnitName | Yes | Ad unit resource name (e.g. accounts/pub-1234567890123456/adUnits/9876543210). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose behavioral traits such as whether it is read-only, default pagination behavior, or rate limits. The description merely restates the function without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple parameters and no output schema, but the description provides no context about the return format, pagination, or what constitutes an ad unit mapping. For a domain with many sibling tools, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 any new meaning beyond the schema. The parameter descriptions in the schema are already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'for a specific ad unit'. This distinguishes it from sibling tools like listAdmobAdUnits and createAdmobAdUnitMapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like createAdmobAdUnitMapping or when not to use it. The description lacks explicit context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ad units under an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | EBNF filter expression. | |
| pageSize | No | Maximum number of items to return. | |
| pageToken | No | Pagination token. | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only list operation but does not disclose any behavioral traits such as authentication requirements, rate limits, or potential side effects. Since no annotations are provided, the description carries the full burden for transparency, but it is minimally adequate for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. It is concise and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list operation with 4 parameters) and the absence of an output schema, the description is somewhat complete but could be improved by mentioning the return format or pagination behavior. It meets the minimum threshold but has room for enhancement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented in the schema. The description does not add significant meaning beyond the schema; it only implies that publisherId is relevant. According to the guidelines, baseline is 3 when schema coverage is high, and the description does not warrant a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'ad units' under an AdMob publisher account, which is specific and distinguishes it from sibling tools that list other resources like ad sources or apps. However, it does not emphasize the differentiation from siblings explicitly, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like listAdmobAdSources or listAdmobApp. There is no mention of prerequisites, context, or exclusions. Usage is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List applications under an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum number of items to return. | |
| pageToken | No | Pagination token. | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description does not disclose behavioral traits like read-only nature, pagination, authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Could be slightly more detailed without harming conciseness, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and many sibling tools, the description is too brief. It lacks context on return values, required parameters, and pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'applications under an AdMob publisher account.' It distinguishes from siblings like listAdmobAccounts (accounts) and listAdmobAdUnits (ad units).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as listAdmobAccounts for account listing. No conditions or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List mediation groups in an AdMob publisher account.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | EBNF filter expression. | |
| pageSize | No | Maximum number of items to return. | |
| pageToken | No | Pagination token. | |
| publisherId | No | AdMob Publisher ID or resource name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Merely states 'list' without disclosing read-only nature, pagination behavior, or filtering specifics. Missing behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, and front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 parameters, the description is too minimal. It does not explain return structure, pagination details, or how to use filter/pageToken.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the schema. However, the description adds no extra meaning or usage hints beyond what the schema provides, achieving baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and resource 'mediation groups in an AdMob publisher account'. It distinctly identifies the tool's purpose and differentiates from sibling tools like listAdmobAdUnits or listAdmobApps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 generateAdmobMediationReport or listAdmobAdUnits. Lacks context for when-not-to-use or examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch an existing mediation group using updateMask.
| Name | Required | Description | Default |
|---|---|---|---|
| updateMask | No | Field mask specifying fields to update (e.g. "displayName,state"). | |
| mediationGroup | Yes | Mediation group object containing modified fields. | |
| mediationGroupName | Yes | Mediation group resource name (e.g. accounts/pub-1234567890123456/mediationGroups/9876543210). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only uses 'Patch' without detailing mutation behavior, permissions, or effects on omitted fields. Lacks transparency for a safe selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence front-loading the purpose with no extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, description should provide more behavioral context (e.g., partial vs full update, required fields). Currently incomplete for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%), so baseline is 3. Description adds value by mentioning updateMask usage, but does not explain parameter interactions or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (patch) and resource (mediation group), with mention of updateMask, distinguishing it from siblings like createAdmobMediationGroup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use patch vs create or other tools; usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop an active mediation A/B experiment.
| Name | Required | Description | Default |
|---|---|---|---|
| variantChoice | Yes | Winning variant choice to apply. | |
| experimentName | Yes | Experiment resource name (e.g. accounts/pub-XXX/mediationGroups/YYY/mediationAbExperiments/ZZZ). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only says 'Stop an active mediation A/B experiment.' It does not disclose whether the operation is destructive, reversible, requires permissions, or what side effects occur (e.g., applying variantChoice).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, achieving maximum conciseness while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits crucial context: it does not mention that the tool also applies the winning variant (as implied by the variantChoice parameter), nor does it explain the effect of stopping an experiment. This is a significant gap for a mutation tool with no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameter descriptions, including enum values for variantChoice and a format example for experimentName. The description adds no additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Stop' and identifies the resource as 'an active mediation A/B experiment', clearly stating the tool's action and object. This distinguishes it from sibling tools like createAdmobMediationAbExperiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives, such as when an experiment should be stopped vs. left running, or any prerequisites. It only states the basic action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.6.0batchCreateAdmobAdUnitMappingscreateAdmobAdUnitcreateAdmobAdUnitMappingcreateAdmobAppcreateAdmobMediationAbExperimentcreateAdmobMediationGroupgenerateAdmobCampaignReportgenerateAdmobMediationReportgenerateAdmobNetworkReportgetAdmobAccountlistAdmobAccountslistAdmobAdSourceAdapterslistAdmobAdSourceslistAdmobAdUnitMappingslistAdmobAdUnitslistAdmobAppslistAdmobMediationGroupspatchAdmobMediationGroupstopAdmobMediationAbExperimentScored across 19 tools
Each tool targets a distinct resource and action (list, create, get, generate, etc.) with clear naming. The three report tools are differentiated by type (mediation, campaign, network). No overlapping purposes.
All tools follow a consistent camelCase convention with verb + 'Admob' + noun pattern (e.g., listAdmobAccounts, createAdmobAdUnit). No mixing of styles or inconsistent verb choices.
19 tools is well-scoped for an AdMob management server, covering accounts, apps, ad units, mappings, ad sources, mediation groups, experiments, and reports without unnecessary duplication.
Covers core creation and listing operations for main resources, but lacks update/delete for ad units, mappings, and mediation groups, and no explicit list for experiments. Some operations are missing, potentially causing agent dead ends.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Run Google Ads and Meta Ads from ChatGPT or Claude: audit wasted spend, create and manage campaigns.
Build, edit and sync Google, Microsoft, Reddit and Meta ad campaigns from your assistant.
Google Ads analysis and operations — read performance, manage keywords, bids, and campaigns.
