Skip to main content
Glama

DevTune MCP

by ai.devtune
OverviewDiscussionsAdmin

devtune_get_search_rollups

Get materialized fixed-window Search Console, legacy GA4, or selected-provider analytics aggregate totals. Missing or stale freshness pointers serve the last published rollup with its own source dates. Retained evidence is partial with isCurrent false and status unmeasured; report asOfDate and say the numbers are not current. Never-published projects return unavailable coverage with null totals. GSC source dates end at Pacific today minus three days. Report that returned finality boundary. Read with per-contributor coverage metadata. Current totals require every eligible contributor to prove full-window coverage. Stale published totals remain visible without a verified current comparison. Use measurement.availability and explanation to distinguish partial evidence, unavailable verification, verified zero, and complete totals. GSC storedEvidence reports row-presence dates, including legacy and disconnected history; it does not verify continuous coverage. Always report the returned source window. The analytics source also returns paginated daily session aggregates; limit and offset apply only to those rows. Return pagination.generation on every continuation; data changes or UTC midnight require restarting at offset 0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
sourceYesAggregate source: Search Console, legacy GA4, or the selected analytics provider.
generationNo
windowDaysNoRolling window in days: 30 or 90. Defaults to 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / generation
      Added value: +{
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / source / description
      Previous value: -"Aggregate source: Search Console or GA4."New value: +"Aggregate source: Search Console, legacy GA4, or the selected analytics provider."
    • changedInput schema / properties / source / enum
      Previous value: -[
-  "gsc",
-  "ga4"
-]New value: +[
+  "gsc",
+  "ga4",
+  "analytics"
+]
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains fallback to last published rollup, stale data semantics, never-published null totals, GSC date boundary, coverage metadata, and pagination rules. It even details output nuances like measurement.availability and pagination.generation. This is far beyond average, though some phrasing (e.g., 'Retained evidence is partial with isCurrent false and status unmeasured') is cryptic and could be clearer, preventing a perfect score.

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

Conciseness2/5

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

The description is a single dense paragraph with no section breaks, bullets, or front-loading of the most critical information. It repeats concepts (e.g., 'Always report the returned source window' and 'Report that returned finality boundary' are nearly redundant). While every sentence carries information, the lack of structure makes it harder for an agent to parse quickly. It would benefit from segmentation by topic.

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 there is no output schema and no annotations, the description does an impressive job covering edge cases (stale, never-published, partial coverage), pagination continuation, date boundaries, and the meaning of availability indicators. It even warns about GSC storedEvidence not verifying continuous coverage. However, it leaves some concepts vague (e.g., 'per-contributor coverage metadata' and the generation parameter's purpose) and does not define what 'unavailable coverage' precisely implies beyond null totals. Still, for a complex tool it is remarkably 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 coverage is only 40%, so the description must compensate. It clarifies that limit and offset apply only to analytics paginated rows, which is a key semantic the schema does not convey. It also maps the source enum to human-readable names. However, it does not explain the generation parameter at all, and windowDays is left entirely to the schema (which already has a clear description). The description adds some value but leaves notable gaps, justifying a 3.

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 opens with a specific verb ('Get') and a precise resource ('materialized fixed-window Search Console, legacy GA4, or selected-provider analytics aggregate totals'). It clearly distinguishes this tool from the many sibling get_* tools by naming the exact data domain and its scoped window. Even without reading the schema, an agent knows what data this returns and for which sources.

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 gives substantial context about when the tool is applicable: it handles stale or missing freshness pointers, never-published projects, and covers all three sources. However, it never explicitly states 'use this when you need aggregate totals' versus alternatives, and it doesn't name any sibling to rule out. The guidance is implicit in the resource description and edge-case behavior, not an explicit when-to-use directive.

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

All DevTune MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources