Skip to main content
Glama

AI Answers and Brand Visibility

ai_answers
Read-only

Put a buyer's question to an AI assistant that searches the live web, and see whether a brand and its competitors are named in the answer, in what rank, with the citations and cited domains behind it. The assistant is ChatGPT unless engine names claude, perplexity or gemini; an assistant the server has no key for answers not_configured and costs nothing. samples (1 to 5, default 1) asks the same question more than once, for a mention rate. Returns metrics per assistant, not the raw answers. Charged per call to the assistant at the price list in credits (see llms.txt), the same as POST /v1/ai/answers: the worst case is held first, only the calls made are charged, and a call where the assistant failed is charged nothing. Gemini, when it searches Google, is a base price plus a price for each distinct search query it runs (the model decides how many; up to 10 a call are held for, and a call is only made when that worst case fits in what is held): you are charged for the queries that ran. The most the call can cost is held first and you are charged for what it returns; a call that fails costs nothing.

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": {
      "prompt": "<prompt>",
      "brand": "<brand>"
    },
    "name": "ai_answers"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandYesBrand name to look for in the answer
engineNoThe assistant to askchatgpt
promptYesThe question to put to the assistant, as a buyer would ask it
countryNoTwo-letter ISO country code of the marketae
samplesNoTimes the question is asked of the assistant
languageNoLanguage tag of the market, for example en or aren
competitorsNoCompetitor names or domains to track
brand_domainNoThe brand's domain, for example roasters.ae
idempotency_keyNoOptional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare readOnly and openWorld; the description goes well beyond them by disclosing that the tool searches the live web, returns per-assistant metrics rather than raw answers, that an unconfigured engine answers not_configured at no cost, and the full hold-then-charge billing model including free failures and Gemini per-query pricing. This is exactly the kind of non-schema behavior an agent needs before spending credits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is cleanly front-loaded in one sentence, but the billing explanation sprawls and restates itself: 'the worst case is held first, only the calls made are charged, and a call where the assistant failed is charged nothing' is repeated nearly verbatim in the final sentence. Tightening would preserve all information in half the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the needed work of saying the return is per-assistant metrics (mentions, rank, citations, cited domains) rather than raw answers, and it fully covers cost risk for a paid, multi-engine call. Only minor gaps remain, such as what the metrics look like and idempotency handling, which the schema already covers.

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 coverage is 100%, so the baseline is 3. The description usefully enriches `engine` (which values exist, what happens without a key) and `samples` (range, default, purpose), but says nothing extra about `country`, `language`, `competitors`, `brand_domain` or `idempotency_key` beyond what the schema already states.

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 concrete verb-and-resource framing: put a buyer's question to a live-web AI assistant and see whether a brand and its competitors are named, at what rank, with citations and cited domains. That is specific enough to separate it from siblings like google_serp or geo_citation_radar 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 Guidelines3/5

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

It gives useful call-context (default engine, behavior when a key is missing, samples for mention rate, cost shape) but never states when to choose this over alternatives such as google_serp or geo_citation_radar. Usage is implied rather than routed.

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