Skip to main content
Glama

Search traffic (Google Search Console)

get_traffic
Read-onlyIdempotent

Clicks, impressions, CTR and average position from Google Search Console for a date range, compared with the same-length prior period, plus the top pages and top queries. Defaults to the trailing 28 days. Requires the site to be connected to Search Console (if not, the error says so; the human connects it on the Reports page). Free. Set includeDaily=true for the day-by-day series. For branded vs non-branded use get_branded_split; for keyword positions use get_rankings.

Input Schema

NameRequiredDescriptionDefault
siteYesThe site to act on. One of: fencestainingdenver.com.
limitNoMax items to return (default 10, max 100).
endDateNoRange end (YYYY-MM-DD).
startDateNoRange start (YYYY-MM-DD).
includeDailyNoInclude one row per day for the current period.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description correctly focuses on extra context: the prerequisite that the site be connected to Search Console, that the failure mode surfaces in the error message and is resolved by a human on the Reports page, and that the tool is free. It stops short of describing how the limit parameter applies across the summary vs. the top-pages/top-queries lists, which is the remaining behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence carries information and the metrics/scoping come first, followed by defaults, prerequisites, and sibling routing. The opening sentence is long and packs four metrics plus comparison plus two aggregate lists, which slightly blunts front-loading.

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?

With no output schema, the description takes on the burden of explaining the return payload (metrics, prior-period comparison, top pages, top queries) and it does so. Combined with the connection prerequisite and the sibling routing, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning on top: the date defaults (trailing 28 days) and the effect of includeDaily=true (day-by-day rows). It does not add anything for site or limit beyond the schema, so it does not reach the top of the scale.

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 names the specific resource (Google Search Console clicks, impressions, CTR, average position plus top pages and top queries) over an explicit date range with prior-period comparison. It distinguishes itself from siblings by naming get_branded_split and get_rankings as the alternatives for those specific needs.

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?

It states the default window (trailing 28 days), the opt-in flag for a daily series, and explicitly routes two adjacent use cases to their dedicated siblings. When-to-use and when-to-use-something-else are both covered without inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.