Skip to main content
Glama

found-by-ai-monitor

Verbatim engine answers, question by question

get_answers
Read-only

The exact answer each engine gave to each tracked buyer question in the latest deep measurement for areyoufoundbyai.com: engine, model, date, whether this business was named and on how many samples, live web search or model memory, the competitors named in that answer, the web searches the engine ran before answering (fan-out), and the question's Google demand. This is the receipt behind every score. Filter by a question substring or an engine; answers are trimmed to chars characters. Named: your business is named in the answer. Cited: your website is linked in the answer’s sources. Listed: your name appears in a list, heading or source title rather than in the prose. Found via search: a page appears in recorded search results; that alone is not a citation or recommendation. These can overlap. A web-search flag only records that search was used. Older positive flags may not distinguish these types; read the retained answer. Unavailable is not a negative result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
charsNoMaximum characters per answer, default 4000, max 12000
limitNoMaximum question rows, default 12, max 25
engineNoOne of ChatGPT, Perplexity, Gemini, Claude, Grok, DeepSeek, Google AI Overviews
offsetNoQuestion offset from nextOffset; default 0
questionNoSubstring of a tracked question, case-insensitive

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / chars / description
      Previous value: -"Maximum characters per answer, default 700, max 4000"New value: +"Maximum characters per answer, default 4000, max 12000"
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Question offset from nextOffset; default 0",
      +  "type": "integer"
      +}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest — and it delivers: answers are trimmed to `chars`, flags (Named/Cited/Listed/Found via search) are defined and noted as overlapping, it warns that older flags may not distinguish these types and that the retained answer should be read, and it clarifies that 'Unavailable is not a negative result.' These interpretation caveats are exactly the behavioral context annotations cannot supply.

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?

The core output is front-loaded in the first sentence, and the flag-definition sentences each earn their place by preventing misinterpretation. The opening sentence is an extremely dense run-on list, and the flag glossary could be tightened, but there is no filler or redundancy.

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 must convey the return shape, and it enumerates the fields well (engine, model, date, named count, search-vs-memory, competitors, fan-out searches, demand). What it omits is pagination mechanics — the `offset` parameter references `nextOffset`, a response field the description never explains. That single gap keeps it from a 5.

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 only restates parameters already documented ('Filter by a question substring or an engine,' 'trimmed to `chars` characters') and adds no format, default, or boundary detail beyond the schema. It does not compensate further because it does not need to.

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 states a precise verb+resource: it returns 'the exact answer each engine gave to each tracked buyer question in the latest deep measurement,' and enumerates the accompanying fields (engine, model, date, named/cited flags, competitors, fan-out searches, demand). This is specific enough that an agent can distinguish it from siblings like get_mentions or get_citation_sources, which aggregate rather than return verbatim per-question answers.

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 says 'Filter by a question substring or an engine,' which is parameter guidance rather than when-to-use guidance, and it frames the tool as 'the receipt behind every score' — an implicit cue. However, it never states when to prefer this over the sibling aggregation tools (get_mentions, get_citation_sources, get_share_of_voice) or any preconditions. Usage is implied but never explicitly 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.