Fenlight

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.

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

Name	Required	Description	Default
`brand`	Yes	Brand name to look for in the answer
`engine`	No	The assistant to ask	chatgpt
`prompt`	Yes	The question to put to the assistant, as a buyer would ask it
`country`	No	Two-letter ISO country code of the market	ae
`samples`	No	Times the question is asked of the assistant
`language`	No	Language tag of the market, for example en or ar	en
`competitors`	No	Competitor names or domains to track
`brand_domain`	No	The brand's domain, for example roasters.ae

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond readOnlyHint/openWorldHint: discloses that unconfigured assistants return not_configured at zero cost, that the worst case is held before running with only actual calls charged, that failed calls are free, and the Gemini search-query pricing model. It also states the return shape (metrics per assistant, not raw answers).

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?

Purpose and engine behavior are front-loaded, and each sentence carries new information. It is dense single-paragraph prose with a long billing run-on about Gemini that could be tightened, but nothing is expendable.

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 covers the returned content (metrics per assistant, rank, citations, cited domains) and the cost/held-credit model, which is what an agent needs to call it safely. The exact metric fields remain unspecified, a minor gap.

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 baseline is 3. The description adds value beyond that: engine fallback default, the not_configured outcome per engine, and the samples range/default used for mention rate.

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?

Names a specific action and resource: ask an AI assistant that searches the live web whether a brand and competitors are mentioned, with rank, citations and cited domains. This is clearly distinguishable from the SERP-scraping siblings.

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?

The opening sentence frames the use case (buyer's question, brand vs. competitors) and the engine/samples notes make the invocation context clear. It never explicitly says when to prefer this over company_serp_footprint or geo_citation_radar, so no exclusions or alternatives routing.

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

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