google-data-mcp

by ducnhd

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct Google service or distinct operation within a service. google_trends_compare and google_trends_interest are clearly differentiated by their normalization semantics, and the ad tools (advertisers vs creatives) have distinct purposes. No two tools could be easily confused.
Naming Consistency4/5
Tool names follow a consistent service-prefix pattern (google_trends_, google_ads_, youtube_, google_play_), but the second part mixes nouns, verbs, and gerunds (e.g., compare, trending, listing, advertisers, creatives, reviews). While not perfectly uniform, the pattern is predictable and readable.
Tool Count5/5
With 7 tools, the set is well-scoped. It covers multiple Google data services without bloating, and each tool addresses a common use case, making the count feel right for the stated purpose.
Completeness4/5
The tool surface covers core workflows for Trends (compare, trending, interest), Ads (advertiser search and creatives), YouTube (listing videos), and Play (reviews). Minor gaps exist (e.g., no YouTube channel details, no Play app metadata), but the essential read operations are present. The server explicitly notes limitations like no transcripts, which clarifies its boundaries.
Average 4.1/5 across 7 of 7 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds value by clarifying that searchVolume is a rounded bucket, not a precise count. However, it doesn't mention other behavioral aspects like update frequency, response structure, or any limitations of the trending data. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. The first states the core purpose, and the second adds a necessary clarification about the output field. There is no wordiness or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without an output schema the description should outline the response shape. It only mentions searchVolume, leaving the overall response structure (e.g., array of objects with title and searchVolume) implicit. This is minimally sufficient for a basic understanding but lacks full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for both parameters (geo as country code with examples, limit as count with min/max). The tool description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns what is trending on Google in a single country. The phrase 'right now' conveys real-time trending, and 'in one country' hints at a single-geo scope, distinguishing it from comparison tools. However, it doesn't explicitly name sibling tools or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like google_trends_compare or google_trends_interest. The 'in one country' wording implies a single-country use case, but there are no exclusions or alternative recommendations. This is insufficient for an agent to make a confident choice.
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 disclose behavior. It states return fields (id, country, ad count) and downstream usage, which is helpful. However, it omits details like rate limits, pagination, or explicit read-only nature, though 'Find' implies a safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and the second sentence adds critical workflow information. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains return fields and how to chain to google_ads_creatives. For a simple two-parameter search tool, this is adequately complete, though it doesn't cover edge cases like empty results or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both keyword and limit, so the schema already handles parameter meaning. The description adds context about using the returned id with google_ads_creatives, but doesn't introduce new parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Find advertisers in Google's Ads Transparency Center by name' with a specific verb and resource, and distinguishes from sibling google_ads_creatives by instructing to pass the id there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the search use case and directs the user to google_ads_creatives for creatives, providing context for when to use this tool. It lacks explicit 'do not use when' exclusions but offers sufficient guidance for the main workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that reviewer names and avatars are omitted by default because they are personal data, and explains the language/country variability. This adds meaningful behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every phrase adds value. It is tightly written without redundancy or irrelevant details.
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 mentions the return fields, the personal data omission, and the language/country coverage tip, which collectively give a good sense of what to expect. It does not discuss sort/limit behavior, but those are already documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, so the baseline is 3. The description adds value by explaining the interplay between hl/gl and review coverage, and by clarifying why include_author defaults to false (personal data concern). This exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching Android app reviews and enumerates the data fields (rating, text, date, app version, thumbs-up, developer reply). It lacks an explicit verb like 'get' or 'fetch', but the resource and scope are specific enough to distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: varying hl/gl to widen coverage and acknowledging that each language/country returns different reviews. It does not explicitly contrast with sibling tools or state when NOT to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source (Google's Ads Transparency Center), the fields returned, and a non-obvious edge case (zero ads is valid and why). It omits details like rate limits, pagination behavior, or error handling, but the included behavioral insight is valuable.
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 no filler. The first sentence front-loads the core purpose and output fields; the second sentence clarifies an important edge case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, no output schema, and no annotations, this description is quite complete. It covers the core function, output fields, data source, and a critical edge case. It does not explain pagination/limit behavior, but the schema covers the limit parameter, so this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (advertiser and limit). The description adds no extra parameter semantics, only referencing 'advertiser' generically. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns "every ad an advertiser is currently running" from Google's Ads Transparency Center, mentioning specific output fields (creative id, format, preview URL, dates). This distinguishes it from sibling tools like google_trends_* and youtube_listing, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the full set of currently running ads for a given advertiser. It also provides important interpretive guidance by noting that "an advertiser with zero ads is a real answer" and explaining why. It does not explicitly name alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behavioral traits: return fields and the transcript limitation caused by server token restrictions. It does not mention authentication, rate limits, or ordering, but for a read-only listing tool this is reasonably transparent.
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 no filler. The first sentence defines purpose and modes, the second covers return fields and a critical limitation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description is complete: it covers the three listing modes, what fields are returned, and the main constraint. The schema covers parameter details like limit and pagination behavior, so the description does not need to repeat those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are already described in the schema (100% coverage), so the description adds minimal new parameter semantics. It does clarify the target parameter's meaning per kind, but this is already present in the schema description, so no extra value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists videos from YouTube, enumerates the three specific modes (Shorts, videos, search), and lists return fields. It is immediately distinguishable from sibling tools which focus on Google Trends, Google Ads, and Play Reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (for listing YouTube videos from channels/search) and explicitly states a limitation (transcripts unavailable). However, it does not name alternative tools or provide when-not-to-use guidance beyond the transcript caveat, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden, and it excels by disclosing that values are normalized across keywords and that the tool refuses 6+ terms rather than silently dropping one. This adds valuable behavioral context beyond the input schema, though it does not cover error handling or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in the first sentence and a key behavioral caveat in the second. Every phrase earns its place, 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 tool with 3 parameters and no output schema, the description covers purpose, output semantics (0-100 normalized values), and an input constraint. It lacks guidance on how this tool relates to google_trends_interest or other siblings, but enough is provided for an agent to know when to invoke it for comparison tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameter descriptions (100% coverage), so the description does not need to explain basic meaning. However, it adds semantic value by explaining why the keyword limit is 2-5 (to ensure normalized comparison) and what happens if the limit is exceeded, which goes beyond the schema's '2 to 5 search terms' text.
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 action ('Compare up to 5 keywords in ONE Google Trends request') and highlights the distinguishing normalization feature, making it easy to differentiate from related tools like google_trends_interest. The purpose is specific and actionable.
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: when comparing/ranking multiple keywords in a single normalized request. It also implicitly states a limitation (6+ refused) but does not explicitly name alternative tools or when-not conditions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it discloses a key behavioral trait: values are '0-100 relative WITHIN this single request' and 'not comparable to another call's numbers'. This is valuable context beyond the schema. It doesn't mention return format or rate limits, but for a simple read-only tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by a critical caveat and a clear sibling reference. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and lack of output schema, the description covers the main usage caveat (non-comparability) and the alternative. It could explicitly state the response is a time series, but 'interest over time' implies it. Overall, it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter explanations for keyword, geo, and timeframe. The description adds little beyond saying 'ONE keyword', which mostly reinforces the schema's 'A single search term'. Baseline 3 applies as 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 clearly states 'interest over time for ONE keyword', a specific verb+resource with explicit scope. It also distinguishes itself from google_trends_compare by noting the alternative for ranking terms, which differentiates it from the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use google_trends_compare when you need to rank terms against each other', providing a direct alternative and the condition for choosing it. This also implicitly states the current tool is for single-keyword relative interest, making usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![google-data-mcp MCP server](https://glama.ai/mcp/servers/ducnhd/google-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ducnhd/google-data-mcp)

Score Badge

Copy to your README.md:

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

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