Skip to main content
Glama

Adaga solutions — Data APIs Toolbox

ai_brand_visibility_tracker

Measure whether a selected AI model mentions a brand and cites its official domain in real answers. Use when you need repeatable, answer-level evidence with persistent history and deltas for the same brand, domain, queries and model. Returns mentioned, cited, citationCount, model-provided URLs, the complete answer and an accuracy warning. Use aeo_ai_visibility_checker instead for technical website readiness, or local_presence_monitor for Google reviews and local-business signals. Results are specific to the selected model, prompts and run date; they are not a ranking guarantee or verified commercial truth. Auth: Apify API token required in Authorization: Bearer; a separate OpenRouter apiKey is required for real measurements. Rate limits: 60 calls/min/IP on this facade; no pagination. Pricing: $0.05 per run + $0.05 per measured answer + $0.10 per official-domain citation, plus any OpenRouter provider costs. dryRun returns a technical sample without provider calls or event charges.

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": {
      "brand": "<brand>",
      "domain": "<domain>"
    },
    "name": "ai_brand_visibility_tracker"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandYesExact brand or company name to find in the answer text.Adaga solutions
modelNoModel used for every query. Choose a fixed model for strictly comparable history; openrouter/free selects an available free model.openrouter/free
apiKeyNoSecret key required only for real measurements. Leave empty only when dryRun is true.
domainYesOfficial domain without protocol, for example adagasolutions.lu. Subdomains count as official citations.adagasolutions.lu
dryRunNoReturn a clearly marked technical sample without calling an AI provider or charging events. This is not a visibility result.
queriesNoOne to ten stable prompts used for the visibility measurement.
maxTokensNoUpper bound per answer. Reasoning models may need at least 1,000 tokens.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With zero annotations, the description carries the full burden and does: dual auth requirements (Apify token plus a separate OpenRouter apiKey for real measurements), rate limit of 60 calls/min/IP, no pagination, itemized pricing including per-answer and per-citation charges, dryRun semantics (no provider calls, no event charges), and a caveat that results are model/prompt/date-specific and not a ranking guarantee.

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?

Dense but well ordered: purpose, usage, returns, alternatives, caveats, then operational facts (auth, limits, pricing, dryRun). Every sentence carries weight for a paid, credentialed tool, though the apiKey/dryRun constraints are stated twice across description and schema.

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 7-parameter, credentialed, paid tool with no output schema, the description enumerates the return fields (mentioned, cited, citationCount, model URLs, full answer, accuracy warning) and covers cost, limits, and failure/edge semantics. Nothing an agent needs before calling is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description mostly restates what the schema already documents (apiKey only for real measurements, dryRun returns a sample). The only genuine addition is the comparability rationale for pinning a fixed model across runs, which is marginal against an already-annotated 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?

States a specific verb and resource: measure whether a selected AI model mentions a brand and cites its official domain in real answers. It also carves out its scope against two named siblings (aeo_ai_visibility_checker for technical readiness, local_presence_monitor for local signals), so an agent can distinguish it 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?

Explicitly says when to use it (repeatable, answer-level evidence with persistent history and deltas for a stable brand/domain/queries/model set) and when not to (two named alternatives with their domains of use). It additionally routes the agent to dryRun for a no-cost technical sample, covering the cautious-caller case.

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