Skip to main content
Glama

content_360

Read-onlyIdempotent

Content 360 | the caller's OWN page-family report, computed server-side from their connected Search Console, GA4 and Bing Webmaster tables (the exact numbers the user sees in the app, nothing estimated, no LLM). Every URL of the property is matched to a PAGE FAMILY (an ordered prefix rule, by default the first path segment such as /data, /connectors, /blog; editable per property) and every day to an ISO week. Call it for "which part of my site earns impressions", "which page family brings clicks or AI referrals", "how did /blog do against the previous four weeks", "which family do LLM crawlers visit". Sections: overview (the family table of the window: impressions, clicks, CTR, impression-weighted position, GA4 sessions from Google, Bing and AI assistants by name, Bing impressions and clicks, each with the change vs the previous window of the same length; plus the weekly series per family), families (the rule in force, whether it is saved or derived, how many URLs each family takes, the top URLs with their family), signals (the operator block: LLM crawler hits by crawler family and signups by first-touch family per week; present ONLY for the site this autario runs on, otherwise an honest one-line reason). AI Overviews and AI Mode impressions are not in the Search Console API; the report says so instead of guessing. Requires the caller's own autario account (API key or OAuth) with a Search Console connection | see get_app_context("content-360").

Input Schema

NameRequiredDescriptionDefault
daysNoAnalysis window in days (7, 28 or 90, default 28), anchored at the newest day of the caller's Search Console data and folded into ISO weeks. The change compares against the same-length window before it.
brandNoThe brand (connector grouping) id to report on, as a uuid. Omitted means the brand selected in the autario app (the account's stored brand choice), so you see what the user sees on screen; with no brand selected, all of the account's brands. A brand that is not yours answers an error, never another brand's numbers.
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 ["overview"]. Request only what the question needs; call again for more.
instancesNoOptional comma-separated connector instance ids, to narrow the report to some of the connections inside the selected brand (for example one of two Search Console properties). Omitted means all of them. An id that is not yours, or not in that brand, answers an error rather than a quietly shorter report. The ids are the instance ids get_app_context returns for this app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: numbers are computed server-side with no LLM estimation, AI Overviews/AI Mode impressions are unavailable and the report says so, cross-brand/instance ids error rather than leak data, and the signals section is gated to the running autario's own site with an honest fallback reason.

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 opening sentence front-loads purpose, data sources, and the page-family concept before enumerating sections. It is long and dense, with some redundancy between the section prose and the schema, but nearly every sentence earns its place for a report tool.

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?

Despite having no output schema, the description explains what each section returns (family table with metrics, weekly series, crawler/signup signals) and the window semantics. Combined with rich annotations and 100% schema coverage, an agent has everything needed to call and interpret it 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 description coverage is 100%, so the schema already documents days, brand, format, sections, and instances thoroughly (including defaults and error behavior). The description reinforces brand-default and section-selection semantics but adds little beyond the schema, so the baseline 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?

States a specific verb (report) and resource (the caller's own page-family report), plus the data sources (Search Console, GA4, Bing) and the page-family/weekly framing. This clearly distinguishes it from siblings like seo_360, audience_360, and ai_visibility_360, which cover different report scopes.

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?

Provides concrete example questions that route to the tool ('which part of my site earns impressions', 'how did /blog do against the previous four weeks') and advises requesting only the needed sections. It stops short of naming competing siblings or explicit when-not-to-use conditions, so not a 5.

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.

Resources