Skip to main content
Glama

Autario Data Analytics Platform

by com.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). 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). 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

TableJSON Schema
NameRequiredDescriptionDefault
daysNoAnalysis window in days over the stored runs (1-365, default 30).
brandNoBrand 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).
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 (token efficiency); call again for more.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description adds critical behavioral guarantees: 'NO LLM runs on this read and no run is started', 'never a zero' for unsupported metrics, 'never another property's numbers', and honest empty states. These details directly inform an agent's expectations.

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 front-loaded with purpose and usage triggers. Every sentence adds meaningful detail about sections, edge cases, or the recipe. While verbose, it contains no filler and is logically structured, making the density acceptable.

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?

The description covers auth requirements ('Requires the caller's own autario account'), edge cases (null/absent metrics, unlinked brand), scope restrictions, and a full breakdown of return sections. With no output schema, the description adequately carries the burden of explaining what the agent will receive.

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% with detailed descriptions for all four parameters. The description adds substantial value to the `sections` parameter by explaining what each section contains (overview, prompts, sources, actions, answers, impact), which is beyond the schema's simple 'Which report sections to return.' Other params need no additional context.

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 clearly states the tool reads the caller's own brand-visibility report across AI assistants from stored runs. It distinguishes from siblings by emphasizing 'OWN brand' and 'read deterministically from stored runs', and provides explicit user queries that trigger this tool.

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?

Explicit triggers are given ('Call it when a user asks...'), along with clear exclusions: 'Reads ONLY brands owned by the calling account; runs, prompt edits and settings are deliberately not exposed here.' It also gives a recipe for custom deliverables, pointing to create_dataset and create_chart_from_spec as alternatives.

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

All Autario Data Analytics Platform toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools are strongly domain-specific with clear boundaries, especially the 360 reports and dataset/chart CRUD tools. Some overlap exists around driver analysis (find_drivers, what_matters, decompose_drivers) and dataset discovery (search_datasets, discover_by_topic, list_indicators), but the descriptions make the intended use cases mostly distinguishable.

Naming Consistency4/5

The vast majority of tools follow a clear snake_case verb_noun or get_noun pattern, e.g. list_connectors, refresh_connector, query_dataset, delete_dataset. Minor deviations such as calculate, describe, bubble_or_not, what_matters, and the 360-style report names keep it from being perfectly uniform.

Tool Count2/5

48 tools is far beyond the 3-15 range and even beyond the 25-tool threshold for a heavy surface. The platform is broad and the tools are organized into domains, but the sheer number creates a high selection burden for an agent and suggests the server is trying to cover too many workflows in one toolset.

Completeness4/5

The toolset covers dataset lifecycle, chart lifecycle, data discovery, querying, statistics, app context, connectors, and admin reports remarkably well. Notable gaps are the lack of a delete_chart tool and no row-level update/delete for datasets, but agents can generally work around these or treat them as intentional platform constraints.

Resources