AdSense MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool targets a distinct reporting dimension or resource—overall summary, pages, ad units, date comparisons, alerts, payments, and breakdowns by country, format, traffic source, and platform. The breakdown tools are clearly separated by their 'by' dimension, so an agent can easily select the right one. Only slight overlap exists between earnings summary and the breakdown tools, but they serve different query purposes.
Naming Consistency5/5
All tools follow a verb-noun pattern, predominantly `get_*` for data retrieval, with `list_alerts` and `compare_date_ranges` as minor but still verb-noun variations. The names are predictable and consistently describe the resource or breakdown dimension.
Tool Count5/5
Ten tools is a well-scoped catalogue for an AdSense analytics server. Each tool covers a distinct reporting need without redundancy, and the count aligns with typical server sizes for similar domains.
Completeness4/5
The server covers the core AdSense analytics surface: overall performance, breakthrough dimensions, time comparisons, alerts, and payments. It lacks a tool to list all ad units or sites, but performance metrics per ad unit can be retrieved, and the main read-only workflows are covered. Minor gaps are workable.
Average 3.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
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?
With no annotations, the description must disclose behavioral traits such as read-only nature, required inputs, or filtering behavior. It only lists output metrics and does not mention that a date range is required, how 'per ad unit' is aggregated, or any potential side effects. The safety profile is entirely unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and lists key metrics. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, so the description should clarify the return structure and key inputs. It lists the metrics but does not mention that date_range is required, how results are grouped, or whether ad_client_id filtering is available. The schema covers inputs, but the absence of usage and behavioral context makes it only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the list of metrics but does not add meaning to the parameters beyond what the schema already provides (e.g., date range, ad_client_id). The description is not needed for param understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get performance metrics per ad unit' with a specific list of metrics (CTR, RPM, impressions, clicks, earnings). This distinguishes it from sibling tools like get_earnings_summary or get_top_pages by focusing on ad-unit-level performance.
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 the sibling tools. It does not mention alternatives or exclusions, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention 'percentage deltas' which is a useful behavioral detail, but it does not explain whether this is a read-only operation, what metrics are included, how results are structured, or any other side effects. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and key behavioral detail ('percentage deltas'). Every word earns its place, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two parameters, no output schema), and the description conveys the essential comparison and delta behavior. However, because there is no output schema, the description could have provided more on what exact metrics are returned or the format of the comparison result. The current level is adequate but leaves room for clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (range_a and range_b) with enums and descriptions, achieving 100% coverage. The description adds no additional parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Side-by-side comparison of AdSense metrics across two date ranges with percentage deltas.' It uses a specific verb (comparison) and resource (AdSense metrics), and it distinguishes itself from sibling tools like get_earnings_summary and get_top_pages by focusing on comparing two date ranges rather than single-period retrieval.
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 explicitly mentioning two date ranges for comparison, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. Siblings are all 'get_' tools, so the comparative nature of this tool is clear, but the description stops short of saying 'use this when you need to compare periods.'
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?
There are no annotations, so the description carries the full burden. It discloses the output (revenue and RPM per source) but does not mention required date_range behavior, custom range requirements, data aggregation details, or any limitations. This is minimal beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded purpose and output details. Every word earns its place—no filler or repetition.
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 read-only listing tool, the description conveys the core purpose and output. However, it lacks explicit usage guidance, does not mention the custom date_range dependency on start/end dates, and would benefit from noting what is not included. It is adequate but not fully complete.
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% since all three parameters have descriptions. The tool description adds no additional parameter context beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Get earnings breakdown by traffic source' with examples of sources (Google, Bing, Facebook, direct). It also specifies the output ('Shows revenue and RPM per source'), making it distinct from sibling tools like get_earnings_by_ad_format or get_country_breakdown.
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 the tool (when you need earnings broken down by traffic source) but does not explicitly reference alternatives or exclusions. Siblings exist but are not mentioned, so the agent gets no guidance on choosing this over get_earnings_summary or other breakdown tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that results are sorted by date descending, which is a useful behavioral detail. However, it does not mention any other behaviors such as pagination, authorization requirements, or what fields are returned, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action, and contains no extraneous words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one optional parameter and no output schema. The description states the purpose and sort order, but lacks information about the return structure or any limitations. Given the absence of annotations and output schema, the description is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'limit' parameter with 100% coverage, so the description doesn't need to add much. It adds no additional meaning beyond the schema description, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('AdSense payment history') with a distinguishing attribute ('sorted by date descending'). It clearly differentiates from sibling tools that focus on earnings summaries or performance metrics.
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 explicit guidance on when to use this tool versus alternatives like get_earnings_summary or compare_date_ranges. It implies usage only through the resource name, with no mention of exclusions or alternative recommendations.
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?
No annotations are provided, so the description carries the full burden. It states what data is shown but does not disclose whether the operation is read-only, any authentication requirements, or potential side effects. The verb 'get' implies read-only but it is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose and key output metrics without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description lists the metrics returned (revenue, RPM, CTR, impressions), which provides sufficient output context. Behavior like sorting or limit application is not described, but the limit parameter is covered in the schema, so overall completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all four parameters. The description adds no additional parameter context, so a baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'earnings breakdown by country' and lists the metrics (revenue, RPM, CTR, impressions). This distinguishes it from siblings like get_platform_breakdown (platform) and get_earnings_summary (overall).
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 the tool (for country-level earnings) but does not explicitly mention alternatives or exclusion criteria. No guidance is given on choosing between this and get_platform_breakdown, so usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does add the qualifier 'estimated earnings' and lists output metrics, but it does not disclose potential data latency, account-level aggregation, permission requirements, or any side effects beyond a read operation. This is minimal behavioral disclosure, though the read-only nature is implicit in the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the primary action and scope, the second lists the returned metrics. It is front-loaded, has no filler, and every sentence contributes useful information.
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 three-parameter tool with a well-documented schema and no output schema, the description sufficiently communicates the core purpose and expected return fields. It lacks some nuances like what 'estimated' means in practice or whether results are aggregated across the whole account, but overall it is complete enough for an agent to understand the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions (date_range enum, start_date, end_date) and 100% coverage, so the baseline is 3. The description's mention of 'date range' aligns with the primary parameter, but it does not add additional meaning about date format dependencies or the custom range requirement that the schema already documents.
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 ('Get') and resource ('AdSense earnings summary') with an explicit scope ('for a date range'). It clearly enumerates the return metrics (estimated earnings, page views, impressions, clicks, CTR, RPM), which distinguishes it from sibling breakdown tools that focus on individual dimensions like pages or countries.
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 like get_top_pages, get_country_breakdown, or compare_date_ranges. It implies a general summary use case but does not state exclusions, alternatives, or conditions for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the output metrics (earnings share, traffic share, RPM, CTR) but does not explicitly state that it is read-only, mention authentication requirements, rate limits, or whether results are aggregated over time. The 'Get' verb implies read-only, but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and contains no filler. Every phrase adds value: the action, the platform categories, and the key metrics returned.
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 sufficiently explains what the tool returns for a reporting tool with a well-documented schema. It lacks usage alternatives and does not mention output format (no output schema exists), but it covers the essential purpose and metrics. The absence of an output schema makes the metric list valuable, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for date_range and start/end dates. The tool description adds no additional parameter context (e.g., the meaning of custom date ranges), but with full schema coverage the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Get earnings split by platform') and states the scope ('mobile vs desktop vs tablet'), distinguishing it from siblings like get_country_breakdown or get_earnings_by_ad_format. The resource and breakdown type 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 Guidelines2/5
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 such as get_earnings_summary or compare_date_ranges. It does not mention exclusions or prerequisites beyond the schema's required date_range, so the agent lacks 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds one useful behavioral detail ('Returns empty if no alerts'), but does not disclose response structure, error behavior, or any permissions needed. This is minimal transparency, though not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with clear, direct language. Every word earns its place, and the key information is front-loaded.
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 zero-parameter read-only list operation, the description is adequate but minimal. It lacks detail about the shape of the returned alerts or policy issues, which would be helpful given the absence of an output schema. It meets the viability threshold but has clear gaps.
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 tool has zero parameters, and the description appropriately does not need to explain any. The schema already confirms this, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'active AdSense account alerts and policy issues'. This distinguishes it from sibling tools that focus on earnings, page performance, and other metrics, 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 implies usage for checking account/policy alerts but does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no reference to sibling tools or conditions that would call for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It implicitly indicates a read-only operation via 'Get', but does not explicitly state read-only behavior, permissions, or any limitations. It adds the insight about 'most revenue' but lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose. No wasted words; the second sentence adds a useful usage angle without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 simple parameters and no output schema, the description adequately explains the tool's function. It could mention what the response contains, but the phrase 'Shows which ad formats generate the most revenue' implies the output structure. Overall sufficient for a simple listing 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 description coverage is 100%: all parameters are described in the schema, including the enum values and date format. The description adds no parameter-specific semantics beyond the schema, so a baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb 'Get earnings breakdown' with resource 'ad format' and examples (In-page, Anchor, Vignette), distinguishing it from sibling breakdown tools like get_country_breakdown and get_platform_breakdown.
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 analyzing revenue by ad format via 'Shows which ad formats generate the most revenue', but it does not explicitly name alternatives or state when not to use it. Since the tool is one of several breakdown tools, a more explicit distinction would help, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a safe read-only operation, but the description does not explicitly mention behavior such as default limit, pagination, or response format. It discloses ranking and date-range scoping but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Get') and includes all key elements: resource type, ranking metrics, and date range. Every word contributes value, with no redundant or filler content.
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 relatively simple list tool with 5 parameters and no output schema, the description is adequate but could be improved. It conveys the core purpose and ranking options, but it does not describe the response structure or pagination behavior. Given the schema's strong coverage and clear sibling context, the overall completeness is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by referencing the sort_by metrics and date-range concept, but it does not elaborate on parameter syntax or defaults beyond what the schema already provides. No new semantic detail is added for start_date/end_date requirements.
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 specifies the tool's function: retrieving top performing pages/URLs ranked by earnings, RPM, or impressions for a date range. It uses a specific verb ('Get') and resource ('pages/URLs'), and the ranking criteria distinguish it from sibling tools that focus on summaries, breakdowns, or comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (querying page-level performance metrics) without enumerating exclusions or alternatives. It does not explicitly name sibling alternatives, but the purpose itself implies its niche relative to other tools like get_earnings_summary or get_country_breakdown.
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:

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

Score Badge

Copy to your README.md:

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

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