Skip to main content
Glama

Get AI search visibility numbers for a date range

visibility_get_summary
Read-onlyIdempotent

Returns the numbers behind the Visibility dashboard in Hi, Moose for one date range, with the same filters the dashboard offers: topics, engines, prompts, branded or non-branded prompts, pages cited, sentiment, narrative, feature parity, plus mentioned, cited and competitor. Pick sections to keep the result small: totals (always), engines, topics, prompts, trend (per day), competitors (share of voice, per engine and topic, pages competitors get cited from, prompts competitors win), citations (pages and domains the engines cite, own pages flagged), mentions (every brand named, with rank and sentiment). Pass compare true for the equal window before, or compareFrom and compareTo, to get the same totals for a second window. Use this for reports, dashboards and "how are we doing" questions; use visibility_list_results for the individual answers behind a number and visibility_check_topic for a one-topic question in plain words. Counts cover the tracked prompts on the tracked engines only, sampled on run days, never the whole of AI search: report the window and sample size and never claim causation. Reads stored results only. Takes a few seconds.

Input Schema

NameRequiredDescriptionDefault
toNoLast day of the window as YYYY-MM-DD. Default today.
fromNoFirst day of the window as YYYY-MM-DD. Default: lookbackDays before to.
citedNotrue: only answers that cite a page of the brand. false: only answers that do not.
pagesNoOnly prompts whose answers cited one of these page URLs, then every engine for those prompts, which is how the Page filter works in Hi, Moose.
topicsNoOnly these topics, by the exact names from visibility_list_tracked. "Uncategorized" selects prompts with no topic.
compareNotrue: also return totals for the window of the same length immediately before from.
enginesNoOnly these AI engines, by name from visibility_list_tracked, such as "ChatGPT" or "Perplexity". A plain name also matches its local-fetch variant.
projectYesThe Hi, Moose project, by its name as shown by list_projects. The projectId is also accepted.
promptsNoOnly these prompts, by exact text or promptId from visibility_list_tracked.
sectionsNoWhich sections to return. Default totals, engines and topics.
compareToNoLast day of a custom comparison window, YYYY-MM-DD. Needs compareFrom.
mentionedNotrue: only answers that mention the brand. false: only answers that do not.
narrativeNoOnly answers with this narrative verdict against the Brand Truth Profile: aligned, partial or drifted.
sentimentNoOnly answers where the brand was mentioned with this sentiment.
competitorNoOnly answers that mention this competitor, by name from visibility_list_tracked.
promptTypeNoOnly branded prompts (the prompt names the brand, an alias or an owned domain) or only non-branded prompts.
compareFromNoFirst day of a custom comparison window, YYYY-MM-DD. Needs compareTo.
lookbackDaysNoWindow length in days when from is not given. Default 30.
featureParityNoOnly answers with this feature parity verdict: accurate, needs-review, inaccurate or not-applicable.

Output Schema

NameRequiredDescriptionDefault
errorNo
jobIdNo
rangeNo
trendNo
statusNodone, failed, pending or running.
totalsNoCounts over the answers in scope. Rates are fractions of answers (0 to 1) and null when there are none. unavailable answers are excluded from the rates.
byTopicNo
filtersNoThe filters that were applied, after validation.
byEngineNo
byPromptNo
headlineNoOne sentence with the window, sample size and the main numbers.
mentionsNo
progressNo
runCountNo
sectionsNo
citationsNo
createdAtNo
comparisonNo
dataNoticeNo
competitorsNo
projectNameNo
promptCountNo
byTopicEngineNo
schemaVersionNoVersion of this result shape. Fields are only added within a version.
trendByEngineNo
byPromptTruncatedNotrue when more than 300 prompts matched; filter by topic to see the rest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds context beyond the annotations: 'Reads stored results only,' 'Takes a few seconds' for latency, and a substantive data-provenance caveat that counts cover only tracked prompts/engines sampled on run days and are never the whole of AI search. That sampling limitation plus the 'never claim causation' instruction is exactly the kind of behavioral disclosure annotations cannot carry.

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?

Front-loaded with purpose, then filters, then section choices, then comparison windows, then usage routing and caveats — a logical order with no filler sentences. It is dense and runs long for a single paragraph, but nearly every clause carries information an agent needs for a 19-parameter 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?

Given 19 parameters, a rich output schema, and full annotation coverage, the description supplies what structured fields cannot: section contents, comparison-window semantics, sampling limits, latency, and sibling routing. Nothing material for a correct call appears missing.

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 the baseline is 3; the description exceeds it by explaining what each section actually contains (competitors = share of voice per engine and topic plus pages and prompts won; citations = pages and domains cited with own pages flagged; mentions = every brand with rank and sentiment) and by clarifying the compare vs compareFrom/compareTo two-window behavior.

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?

Opens with a specific verb and resource: 'Returns the numbers behind the Visibility dashboard in Hi, Moose for one date range,' and immediately names the filters it accepts. It also distinguishes itself from the two closest siblings by name, so an agent can route correctly without opening any schema.

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?

Explicitly states the use case ('reports, dashboards and "how are we doing" questions') and routes alternatives: visibility_list_results for the individual answers behind a number, visibility_check_topic for a one-topic plain-language question. It also gives selection guidance for the sections parameter to keep results small.

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