Autario

ai_visibility_360

Read-onlyIdempotent

AI Visibility 360 | the caller's OWN brand-visibility report across the AI assistants (ChatGPT, Claude, Gemini, Perplexity, optionally Grok/DeepSeek/Mistral), read deterministically from stored runs server-side (the exact numbers the user sees in the app | nothing re-derived, NO LLM runs on this read and no run is started). In one sentence: which brands ChatGPT, Claude, Gemini and Perplexity recommend when someone asks about your category. Call it when a user asks "how visible is my brand in ChatGPT", "do assistants recommend us or a competitor", "which sources do the assistants cite", "what should we do to show up more", "did the AI visibility work turn into real traffic". Sections: overview (visibility score with delta and rank, the brand-vs-competitor leaderboard with visibility / share of voice / sentiment / average position, the per-provider score matrix and the concrete models that answered), prompts (per-prompt brand score vs the strongest competitor plus per-question-category rollups), sources (citation share of the brand's own domains, the cited-domain leaderboard, which providers expose citations at all), actions (the deterministic to-do queue: earned = pages to get featured on, owned = pages to build, each with impact and status), answers (the newest stored assistant answers with detected brand mentions and cited domains, text truncated honestly), impact (GA4 sessions referred by AI assistants for the property explicitly linked to this brand; an unlinked brand gets the honest empty state and the reason, never another property's numbers). EVERY number here counts only questions that do NOT name your own brand: a question naming the brand has already handed the assistant the answer. That holds for visibility, share of voice, rank and the per-assistant matrix AND for sources, gaps, pages, assistant searches, domain movers, perception and action effects. The questions that do name it are still measured, in rankings_branded, and the population block (present on every section set) carries both counts | never add the two together. The two evidence views keep every row instead: the prompt table (flag names_you) and answers (flag question_names_your_brand). A metric the window cannot support is null or absent (an honest dash), never a zero. Reads ONLY brands owned by the calling account; runs, prompt edits and settings are deliberately not exposed here. Recipe: pull the sections you need and interpret them yourself, citing the numbers. For a custom deliverable, write your derived table with create_dataset + write_rows and chart it with create_chart_from_spec. Requires the caller's own autario account (API key or OAuth) with an AI Visibility brand set up | see get_app_context("ai-visibility").

Input Schema

Name	Required	Description
`days`	No	Analysis window in days over the stored runs (1-365). Omit it for every run the brand has (the default).
`brand`	No	Brand name or brand id. Optional when the account has exactly one brand; with several brands the tool answers with the list so you can re-call with one (nothing is picked for you).
`format`	No	Output 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.
`sections`	No	Which report sections to return. Default ["overview"]. Request only what the question needs (token efficiency); call again for more. searches = the web searches the assistants ran behind their answers (grouped by topic, brands named in them); movers = cited domains that are new / trending / losing against the prior window; pages = the cited pages with what is ON them (title, page type, which tracked brands the page names); crawlability = what each domain's robots.txt says to each AI crawler (GPTBot, ClaudeBot, PerplexityBot...) plus llms.txt; perception = the descriptor words the answers use next to each brand, as a brand-by-word matrix; action_effects = the brand's visibility 14 days before and after every action marked done; gaps = the sources that cite a competitor and never this brand, with gap score, used-as-a-source share, prompt coverage and competitor rate (each defined on the page; there is deliberately no retrieval rate, because only citations are observable); model_rankings = the brands each assistant names most, as a rank order with the owned brand flagged.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / days / description

Previous value: -"Analysis window in days over the stored runs (1-365, default 30)."New value: +"Analysis window in days over the stored runs (1-365). Omit it for every run the brand has (the default)."

Changed2 schema fields changedSep 12, 2026

changedInput schema / properties / sections / description

Previous value: -"Which report sections to return. Default [\"overview\"]. Request only what the question needs (token efficiency); call again for more. searches = the web searches the assistants ran behind their answers (grouped by topic, brands named in them); movers = cited domains that are new / trending / losing against the prior window; pages = the cited pages with what is ON them (title, page type, which tracked brands the page names); crawlability = what each domain's robots.txt says to each AI crawler (GPTBot, ClaudeBot, PerplexityBot...) plus llms.txt; perception = the descriptor words the answers use next to each brand, as a brand-by-word matrix; action_effects = the brand's visibility 14 days before and after every action marked done."New value: +"Which report sections to return. Default [\"overview\"]. Request only what the question needs (token efficiency); call again for more. searches = the web searches the assistants ran behind their answers (grouped by topic, brands named in them); movers = cited domains that are new / trending / losing against the prior window; pages = the cited pages with what is ON them (title, page type, which tracked brands the page names); crawlability = what each domain's robots.txt says to each AI crawler (GPTBot, ClaudeBot, PerplexityBot...) plus llms.txt; perception = the descriptor words the answers use next to each brand, as a brand-by-word matrix; action_effects = the brand's visibility 14 days before and after every action marked done; gaps = the sources that cite a competitor and never this brand, with gap score, used-as-a-source share, prompt coverage and competitor rate (each defined on the page; there is deliberately no retrieval rate, because only citations are observable); model_rankings = the brands each assistant names most, as a rank order with the owned brand flagged."

changedInput schema / properties / sections / items / enum

Previous value: -[
-  "overview",
-  "prompts",
-  "sources",
-  "actions",
-  "answers",
-  "impact",
-  "searches",
-  "movers",
-  "pages",
-  "crawlability",
-  "perception",
-  "action_effects"
-]New value: +[
+  "overview",
+  "prompts",
+  "sources",
+  "actions",
+  "answers",
+  "impact",
+  "searches",
+  "movers",
+  "pages",
+  "crawlability",
+  "perception",
+  "action_effects",
+  "gaps",
+  "model_rankings"
+]

Changed2 schema fields changedSep 6, 2026

changedInput schema / properties / sections / description

Previous value: -"Which report sections to return. Default [\"overview\"]. Request only what the question needs (token efficiency); call again for more."New value: +"Which report sections to return. Default [\"overview\"]. Request only what the question needs (token efficiency); call again for more. searches = the web searches the assistants ran behind their answers (grouped by topic, brands named in them); movers = cited domains that are new / trending / losing against the prior window; pages = the cited pages with what is ON them (title, page type, which tracked brands the page names); crawlability = what each domain's robots.txt says to each AI crawler (GPTBot, ClaudeBot, PerplexityBot...) plus llms.txt; perception = the descriptor words the answers use next to each brand, as a brand-by-word matrix; action_effects = the brand's visibility 14 days before and after every action marked done."

changedInput schema / properties / sections / items / enum

Previous value: -[
-  "overview",
-  "prompts",
-  "sources",
-  "actions",
-  "answers",
-  "impact"
-]New value: +[
+  "overview",
+  "prompts",
+  "sources",
+  "actions",
+  "answers",
+  "impact",
+  "searches",
+  "movers",
+  "pages",
+  "crawlability",
+  "perception",
+  "action_effects"
+]

AddedAug 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world; the description adds substantial non-redundant context: numbers are read deterministically from stored runs, no LLM runs are started, results are scoped to the caller's owned brands only, unresolvable metrics are null/absent rather than zero, and the unbranded-only counting rule is disclosed. It stops short of describing pagination or output shape (no output schema exists).

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

Conciseness3/5

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

Front-loaded with the core purpose and triggers, but the body is long and dense, with several overlapping restatements of the unbranded-only rule and a heavily packed 'Sections' enumeration that duplicates schema enum text. Every sentence is relevant but the piece is larger than needed for select-and-invoke.

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 read-only reporting tool with no output schema and 100% schema coverage, the definition covers identity, scope restrictions, counting rules, null semantics, prerequisites and follow-on workflow. Missing only an explicit statement of return structure beyond section names, which is a modest gap given no output schema exists.

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 coverage is 100%, so baseline is 3; the description still adds meaning not in the schema: the section semantics for searches, movers, pages, crawlability, perception, action_effects, gaps and model_rankings, the default section set, the brand fallback behavior with multiple brands, and the branded/unbranded counting rule. It does not re-explain days/format, which the schema covers well.

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 (read) and resource (the caller's own brand-visibility report across named AI assistants), with a one-sentence plain-language restatement of what it answers. It distinguishes itself from siblings like seo_360/social_360/audience_360 by domain (AI assistants) and from rankings_branded by scope.

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?

Provides explicit trigger questions ('how visible is my brand in ChatGPT', 'do assistants recommend us or a competitor', 'what should we do to show up more'), states what is deliberately not exposed (runs, prompt edits, settings), names the prerequisite (autario account + AI Visibility brand set up) and points to get_app_context plus a follow-on recipe (create_dataset/write_rows + create_chart_from_spec).

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

All Autario tools Inspect

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

Need Help?