Skip to main content
Glama

Autario

by com.autario
OverviewDiscussionsAdmin

seo_360

Read-onlyIdempotent

SEO 360 | the caller's OWN deterministic Google Search Console ACTION report, computed server-side from their connected GSC data (the exact numbers the user sees in the app | nothing re-derived, nothing estimated). The unit is the (query, page) pair and EVERY row ends in a concrete action, so this is the tool to call when a user asks "what should I write next", "which page should I fix first", "where am I losing clicks", "how are my rankings developing", "which pages are decaying", "how are my Core Web Vitals", "what technical SEO issues does my site have". Sections: page2_gaps (position 8-20 pairs ranked by potential click gain toward the top 3 | the core write-or-improve list), ctr_underperformers (ranks top-10 but the snippet loses the click | title/description work), orphan_demand (queries with demand whose best page is not about them | the page is missing, write it), cannibalization (one query split across pages | consolidate or differentiate), trends (click winners/losers AND position winners/losers vs the previous window, honestly flagged when the previous window is incomplete), rank_tracking (position series of the top + pinned queries with current vs 7d/28d deltas, ranking distribution Top3/4-10/11-20/21+, share-of-voice index, brand vs generic split), decay (the refresh queue: pages losing clicks across consecutive windows, ranked by lost clicks, with an optional EUR translation from the user's own click-value setting), vitals (Core Web Vitals p75 field data from the Chrome UX Report for the top pages, pass/fail per LCP/INP/CLS), audit (bounded own-site crawl snapshot: broken links, redirect chains, title/description issues, noindex/canonical conflicts, orphan pages, new-vs-fixed diff, internal-link opportunities), health (data coverage, staleness, which CTR-benchmark source applies). The CTR benchmark is the median of the caller's OWN data per position bucket, with a documented default curve as fallback per thin bucket. Deeper than audience_360 (which answers "who comes from where"): this one prescribes the next SEO action. Requires the caller's own autario account (API key or OAuth) with a Search Console connection | see get_app_context("seo-360").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoAnalysis window in days (7-90, default 28), anchored at the newest day of the caller's data. The trend comparison uses the same-length window before it.
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
sectionsNoWhich report sections to return. Default ["page2_gaps","health"]. Request only what the question needs (token efficiency); call again for more.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
-  "page2_gaps",
-  "ctr_underperformers",
-  "orphan_demand",
-  "cannibalization",
-  "trends",
-  "health"
-]New value: +[
+  "page2_gaps",
+  "ctr_underperformers",
+  "orphan_demand",
+  "cannibalization",
+  "trends",
+  "rank_tracking",
+  "decay",
+  "vitals",
+  "audit",
+  "health"
+]
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly=true and idempotent=true, and the description adds meaningful behavioral detail: the report is deterministic, server-side computed, uses the caller's own data as benchmark with a documented fallback, flags incomplete previous windows, and requires an authenticated autario account with GSC connection. The description doesn't contradict annotations, and the honesty-flag on trends is a genuine 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.

Conciseness4/5

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

The description is long, but dense with purpose and usage signal; every sentence earns its place, and the front section states the core value proposition before enumerating sections. It loses one point for length and the dense enumeration of section names that could be slightly tightened, but for a complex multi-section tool this length is justified.

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 read-only, idempotent report tool with zero required parameters and full schema coverage, the description fully covers what the tool does, when to use it, what data it consumes, its authentication requirement, its sections, and its edge-case behaviors (incomplete prior window, benchmark fallback). No output schema exists, but the description's section list effectively tells the agent what the report will contain.

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 parameters (days, format, sections) are fully documented in the schema. The description adds context for the 'sections' default and the token-efficiency guidance, but it doesn't significantly extend parameter meaning beyond the schema. Baseline 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 specifies an exact resource (the caller's own deterministic Google Search Console ACTION report), the computation method (server-side from connected GSC data), and a precise analytic unit ((query, page) pairs with concrete actions). It lists ten named sections mapping to specific user questions, which strongly distinguishes it from sibling tools like audience_360 and social_360.

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?

The description explicitly enumerates trigger questions ('what should I write next', 'which page should I fix first', etc.), distinguishes itself from audience_360 ('deeper than audience_360'), lists which sections map to which intents, and even instructs the agent to request only needed sections. Sibling differentiation is explicit and actionable.

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

All Autario 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