Keytomic

Get AI visibility report

get_visibility_report

Read-only

Returns the AI Search Visibility report of a site for a date range, the same data and filters as the AI Visibility page: the metrics, the visibility trend, the AI platform scorecards, the competitor share, the sources and every AI answer of the range. With promptId, it returns one prompt with its brand counts and its runs (the AI answers) for the date range instead; the other report filters then give invalid_arguments. It reads saved check results only and starts nothing. The result has no paging and can be large. Get promptIds from the prompts section of get_visibility. When AI Visibility is off in this deployment, the call gives feature_disabled.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "get_visibility_report"
  }
}

Input Schema

Name	Required	Description
`topics`	No	Only prompts of these topics.
`endDate`	No	Last UTC day of the range, included, YYYY-MM-DD. Default: today.
`intents`	No	Only prompts of these intents.
`locales`	No	Only these markets, as "US:en", or "global:en" for no country.
`outcomes`	No	Only AI answers with these outcomes.
`promptId`	No	One prompt to return with its runs, from get_visibility.
`platforms`	No	Only these AI platforms.
`projectId`	Yes	Site to act on, from list_sites.
`startDate`	No	First UTC day of the range, YYYY-MM-DD. Default: 27 days before endDate.
`promptType`	No	organic, branded or all (the default).
`approvedCompetitorIds`	No	Only prompts about these competitors, by the entityId of the report.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare a read-only, non-destructive, closed-world read; the description goes further by stating it reads saved check results only and starts nothing (useful against start_visibility_check), that there is no paging and results can be large, and how it fails when the feature is disabled.

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?

Content is front-loaded (what it returns first, then the promptId variant, then behavioral caveats), with no filler. The long enumeration sentence is dense but each element conveys a distinct returned section, so little could be cut without losing information.

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?

With 11 parameters, no output schema, and a dual-mode behavior, the description compensates well: it lists the returned sections, explains the promptId mode change, and flags the no-paging/size caveat and the disabled-feature error. An agent has enough to call it correctly and interpret the result.

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 adds real meaning beyond the schema by explaining that promptId switches the tool into a single-prompt mode whose semantics conflict with the other report filters. It does not, however, describe the filtering interaction among the remaining array filters.

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 opens with a specific verb and resource ('Returns the AI Search Visibility report of a site for a date range') and then enumerates the payload (metrics, trend, platform scorecards, competitor share, sources, AI answers). It also states the alternate mode selected by promptId, which clearly separates it from the sibling get_visibility.

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?

It gives explicit routing: the full report by default, or a single prompt with its runs when promptId is supplied, and warns that other filters then yield invalid_arguments. It also states where to obtain promptIds ('the prompts section of get_visibility') and names the feature_disabled condition.

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

All Keytomic 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?