Hi, Moose AEO

List the stored AI search answers one by one

visibility_list_results

Read-onlyIdempotent

Lists the stored AI search answers for a project one row per prompt, engine and run, newest first, with the same filters as visibility_get_summary. Each row carries the answer id, date, run id, engine, topic, prompt, branded or non-branded, whether the brand was mentioned and cited, its rank, the page cited, the sentiment, narrative and feature parity verdicts, and the competitors mentioned and cited. fields full adds the scorer reasons, the sources the engine listed, every brand named with its rank and sentiment, and a short excerpt of the answer. Paged: default 50 rows, at most 200; pass the nextCursor back to get the next page. Use it to build tables, spreadsheets and custom analyses, or to find the answers behind a number from visibility_get_summary; prefer narrow filters and several pages over one huge pull. Call visibility_get_answer with an answer id for the full text of one answer. Reads stored results only, never runs new checks. Takes a few seconds per page.

Input Schema

Name	Required	Description
`to`	No	Last day of the window as YYYY-MM-DD. Default today.
`from`	No	First day of the window as YYYY-MM-DD. Default: lookbackDays before to.
`sort`	No	Order by date. Default newest.
`cited`	No	true: only answers that cite a page of the brand. false: only answers that do not.
`pages`	No	Only 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.
`cursor`	No	The nextCursor from the previous page, with the same filters and sort.
`fields`	No	compact (default) or full. full adds reasons, sources, brands named and an excerpt, about three times the size.
`topics`	No	Only these topics, by the exact names from visibility_list_tracked. "Uncategorized" selects prompts with no topic.
`engines`	No	Only these AI engines, by name from visibility_list_tracked, such as "ChatGPT" or "Perplexity". A plain name also matches its local-fetch variant.
`project`	Yes	The Hi, Moose project, by its name as shown by list_projects. The projectId is also accepted.
`prompts`	No	Only these prompts, by exact text or promptId from visibility_list_tracked.
`pageSize`	No	Rows per page. Default 50.
`mentioned`	No	true: only answers that mention the brand. false: only answers that do not.
`narrative`	No	Only answers with this narrative verdict against the Brand Truth Profile: aligned, partial or drifted.
`sentiment`	No	Only answers where the brand was mentioned with this sentiment.
`competitor`	No	Only answers that mention this competitor, by name from visibility_list_tracked.
`promptType`	No	Only branded prompts (the prompt names the brand, an alias or an owned domain) or only non-branded prompts.
`lookbackDays`	No	Window length in days when from is not given. Default 30.
`featureParity`	No	Only answers with this feature parity verdict: accurate, needs-review, inaccurate or not-applicable.

Output Schema

Name	Required	Description
`rows`	No
`sort`	No
`error`	No
`jobId`	No
`range`	No
`total`	No	Rows matching the filters in the window, across all pages.
`fields`	No
`status`	No	done, failed, pending or running.
`filters`	No	The filters that were applied, after validation.
`headline`	No	One sentence with the window, sample size and the main numbers.
`pageSize`	No
`progress`	No
`returned`	No
`createdAt`	No
`dataNotice`	No
`nextCursor`	No	Pass back as cursor for the next page. null on the last page.
`projectName`	No
`schemaVersion`	No	Version of this result shape. Fields are only added within a version.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, yet the description adds real context: 'Reads stored results only, never runs new checks' and 'Takes a few seconds per page.' Pagination contract and the size cost of fields=full are spelled out. It doesn't need to explain return values because an output schema exists, so a 4 rather than 5.

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 what a row is, then paging, then usage and alternatives — a sensible order. The long enumeration of row fields is dense but arguably earns its place for table-building; overall it runs a bit long for one 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?

For a 19-parameter, paginated read tool with an output schema, the description covers purpose, row shape, paging, cost, read-only semantics, sibling routing and latency. Nothing an agent needs to call it correctly is 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, but the description adds a cross-reference that the schema cannot: the filters behave 'the same as visibility_get_summary.' It also restates the paging contract (default 50, max 200, pass nextCursor back) in workflow terms. The remaining filter parameters are left entirely to the schema.

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?

Specific verb and resource: lists stored AI search answers one row per prompt/engine/run. It explicitly distinguishes itself from visibility_get_summary (aggregate numbers) and visibility_get_answer (full text of one answer), so an agent can route correctly without opening a 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?

States concrete use cases (tables, spreadsheets, custom analyses, drilling into a summary number) and names the alternative for the other job ('Call visibility_get_answer with an answer id for the full text of one answer'). It also gives operational guidance: prefer narrow filters and several pages over one huge pull.

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

All Hi, Moose AEO 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?