mcp-server

AI Visibility Check

alterlab_ai_visibility

Run prompts against AI answer engines through their public, logged-out interfaces and get, per engine and run, the answer text, whether the brand is mentioned and its position, competitors mentioned, cited URLs and domains and a sentiment label, plus per-prompt mention rate, share of voice and citation share with the sample size. Answers vary run to run, so set runs_per_prompt. Billed per successful engine answer only; an engine that needs login returns engine_unavailable_logged_out and is not billed. Use action=quote (or action=check with quote_only=true) to get the price first, and set hard_cap_microcents to refuse any run quoted above it. action=check (default) runs the check; action=status and action=results read a past run by run_id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "alterlab_ai_visibility"
  }
}

Input Schema

Name	Required	Description
`brand`	No	Brand to look for (check and quote).
`action`	No	check (default) runs the prompts; quote prices them without running; status and results read a run by run_id.
`run_id`	No	Run id from a check (status and results).
`country`	No	Country code for localised answers. Default: engine default.
`engines`	No	Engines to query (check and quote).
`prompts`	No	Prompts to ask (check and quote).
`quote_only`	No	Return the quote without running or billing. Default: false.
`competitors`	No	Competitor names to track. Default: none.
`brand_domains`	No	Domains that count as the brand when cited. Default: none.
`runs_per_prompt`	No	Runs per prompt and engine, 1-5. Default: 1.
`hard_cap_microcents`	No	Refuse the run if the quote exceeds this many microcents. Default: no cap.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses non-determinism ("answers vary run to run"), the billing model (charged per successful engine answer only), the failure mode engine_unavailable_logged_out that is not billed, and the hard_cap_microcents refusal behavior. These are material behaviors for a paid, non-idempotent operation that the readOnlyHint=false and idempotentHint=false flags alone would not convey.

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?

It is a single dense paragraph that front-loads the outcome description and moves to cost/action guidance; nearly every clause carries information. Some action semantics are restated from the schema enum, which is minor redundancy rather than waste.

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 an 11-parameter tool with no output schema, the description supplies exactly what is missing: the shape of the result (answer text, brand mention and position, competitors, cited URLs and domains, sentiment, plus mention rate, share of voice, citation share with sample size). Cost, failure, and run-lifecycle behavior are all covered.

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 genuine meaning: why runs_per_prompt should be raised, that hard_cap_microcents refuses a run whose quote exceeds it, and that quote_only duplicates action=quote. It does not explain the interplay of brand, brand_domains, and competitors, which keeps it below 5.

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 names a specific verb and resource (run prompts against AI answer engines via their logged-out public interfaces) and enumerates the returned artifacts per engine and per run, then distinguishes its four actions (check, quote, status, results). No sibling tool in the list covers AI answer-engine visibility, so an agent can identify this tool from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states clearly when to use each action (quote or quote_only to price first, check to run, status/results to read a past run) and advises setting runs_per_prompt because answers vary between runs. What it lacks is any statement of when NOT to use this tool relative to siblings such as alterlab_serp or alterlab_search, so a 4 rather than a 5.

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

All mcp-server 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.