Skip to main content
Glama

AI Recommendation Check

by com.uxcontinuum
OverviewDiscussionsAdmin

Check if AI recommends a business

check_ai_recommendation
Idempotent

Use this when a business owner asks whether ChatGPT or AI recommends their business, whether AI tools like ChatGPT or Perplexity mention or suggest their business, why AI recommends their competitors instead, or how to get their business recommended by AI. It runs a real check: it asks ChatGPT, Perplexity and Gemini up to 3 questions a customer would ask when looking for this kind of business in the area the business serves, and reports whether each engine named the business, which businesses they named instead, and one fix based on the pages the answers cited. Timing: a check usually finishes in under a minute. This tool waits up to about 20 seconds and returns the result when it is ready; otherwise it returns a check_id with the status queued or running, and get_ai_recommendation_result returns the result for that check_id. A saved result for the same business is returned right away. Business details are sent to Continuum (uxcontinuum.com) to run the check. Results are shown in the conversation. Not covered: general SEO or Google ranking questions, writing marketing copy or ads, looking up or checking a person (it checks businesses only), and general questions about how AI search works. Limits: 3 buyer questions per website per day; saved results are reused for 7 days.

Input Schema

NameRequiredDescriptionDefault
emailNoOptional. The owner's email address, if they want Continuum to send this result and follow up.
websiteYesThe business website, for example "joesplumbing.com". Used to recognise the business in answers and to keep its daily limit.
categoryYesWhat the business is, in the words a customer would use to look for one, for example "plumber", "wedding photographer" or "HVAC company". Not a slogan.
service_areaNoThe area the business serves, as its customers would name it, for example "Austin, TX". This describes the business, not the user's own location. Empty when the business serves customers anywhere online.
business_nameYesThe business name as customers know it, for example "Joe's Plumbing".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / email / description
      Previous value: -"The business owner's email address, for example \"jane@joesplumbing.com\". Sent to Continuum with the business details; Continuum may email the owner personally about the result."New value: +"Optional. The owner's email address, if they want Continuum to send this result and follow up."
    • changedInput schema / required
      Previous value: -[
-  "email",
-  "business_name",
-  "website",
-  "category"
-]New value: +[
+  "business_name",
+  "website",
+  "category"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / email / description
      Previous value: -"The business owner's email address, for example \"jane@joesplumbing.com\". Required. Continuum may email the owner personally about the result; nothing is sent automatically."New value: +"The business owner's email address, for example \"jane@joesplumbing.com\". Sent to Continuum with the business details; Continuum may email the owner personally about the result."
    • changedInput schema / properties / service_area / description
      Previous value: -"The area the business serves, as its customers would name it, for example \"Austin, TX\". This describes the business, not the user's own location. Leave empty only if the business serves customers anywhere online."New value: +"The area the business serves, as its customers would name it, for example \"Austin, TX\". This describes the business, not the user's own location. Empty when the business serves customers anywhere online."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far beyond the annotations, it discloses timing (usually under a minute), the ~20s wait-then-return-check_id behavior, immediate return of cached results, data being sent to a third party (Continuum, uxcontinuum.com), a rate limit of 3 buyer questions per website per day, and a 7-day result reuse window. Nothing here contradicts readOnlyHint=false / idempotentHint=true, since the tool initiates external checks and reuses saved results.

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?

Front-loaded with the triggering scenario, then behavior, then exclusions and limits in clearly labelled segments. It is long, but nearly every clause carries operational value; only a few lines ('Results are shown in the conversation') are close to filler.

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?

Despite no output schema, the description explains what comes back (which engines named the business, which competitors they named, one fix based on cited pages) plus the async contract, timing, privacy and limits. An agent has everything needed to call it and interpret the result.

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 schema already documents all five parameters thoroughly. The description reinforces how the inputs are used (buyer-style questions, area the business serves, recognition of the website) but adds no syntax or format detail the schema lacks; baseline 3 applies.

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 specific action and resource: it runs a live check asking ChatGPT, Perplexity and Gemini whether they recommend a named business. It explicitly distinguishes itself from the sibling by naming get_ai_recommendation_result as the polling tool for a queued/running check_id.

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?

It opens with concrete trigger conditions (owner asks whether AI recommends them, why competitors get recommended, how to get recommended) and closes with an explicit 'Not covered' list (general SEO, marketing copy, checking a person, general AI-search theory). The alternative for async results is named with the exact condition that selects it.

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

All AI Recommendation Check toolsInspect
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