AI visibility + fact-checks (ChatGPT/Perplexity), review gaps & competitor scans, local SEO.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 8 of 8 tools scored.
Each tool serves a distinct function: fact verification, visibility check, review gap analysis, competitor scan, and deep research. The report-related tools (start, poll, fetch) are clearly separated by their roles. No two tools are easily confused.
All names use snake_case consistently. Most start with verbs like 'check_', 'get_', 'run_', or 'start_', though 'ping' and 'review_gap' deviate slightly. The pattern is predictable and readable.
Eight tools cover the domain of local business intelligence well: fact-checking, visibility, review comparison, competitor scan, and deep research. The count is neither too sparse nor overwhelming for the scope.
The tool surface covers core intelligence needs: fact verification, review comparisons, visibility checks, competitor scans, and deep research reports. Minor gaps like a tool to list businesses or manage multiple entities exist, but for single-business analysis it's nearly complete.
check_factsAI Fact-CheckAFind what AI assistants get WRONG about a local business. Asks ChatGPT and Perplexity live (with web search) about the business's hours, address, phone, and category, then verifies each stated fact against Google Business ground truth. Returns a severity-ranked list of conflicts (with the AI's value vs. the trusted value and source) plus discrepancies to check. Conservative by design: a claim with no trusted source is 'unverifiable' (never an error), and a conflict is only counted when it reproduces across engines — so it won't cry wolf. Call this when a user asks whether AI has the right info about a business, or 'why does ChatGPT say we're closed'. Takes ~15-30 seconds. Price: $1.49 per delivered check.
| Name | Required | Description | Default |
|---|---|---|---|
| website | No | Optional: the business website — if an AI answer cites this domain, a mismatch is treated as a possibly-stale discrepancy rather than an error | |
| location | Yes | City and state/region, e.g. "Cincinnati, OH" | |
| businessName | Yes | The local business to fact-check | |
| businessType | No | Optional category anchor, e.g. "restaurant" — helps resolve the business; not required |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: live queries to two AI engines, verification against Google Business, pricing ($1.49), duration (15-30 seconds), and conservative conflict criteria (only counts conflicts that reproduce across engines). This adds value beyond the readOnlyHint annotation, which is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the purpose. It is somewhat lengthy but every sentence adds value (process, conditions, pricing). Could be slightly more concise, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description fully explains the return (severity-ranked list of conflicts and discrepancies). It covers all necessary context: process, pricing, timing, and behavior. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds meaning by explaining how parameters are used: the 'website' parameter triggers special discrepancy handling, and 'businessType' aids in resolving the business. These details go beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fact-checking AI claims about a local business's hours, address, phone, and category by querying ChatGPT and Perplexity and verifying against Google Business ground truth. It distinguishes itself from siblings by specifying the unique function of AI fact-checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call this tool: 'when a user asks whether AI has the right info about a business' or for 'why does ChatGPT say we're closed.' It also explains the conservative behavior (won't cry wolf). While it doesn't mention when not to use it or alternatives, the context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_report_statusCheck Report StatusAPoll a deep research report by slug. Free. Returns status (generating / ready / failed); a failed report triggers the automatic refund of its launch charge. Deep reports typically take 10-20 minutes — poll every few minutes, not every few seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug returned by start_deep_report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint: true), description states that a failed report triggers automatic refund of launch charge and that the tool is free. Adds useful behavioral context not present in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficiently conveys core usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema) and good annotations, description fully covers behavioral info: polling interval, refund policy, free access. Complete for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'slug' with schema description 'The slug returned by start_deep_report'. Description says 'by slug' but adds no additional meaning beyond schema. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Poll a deep research report by slug', identifying the specific verb (poll) and resource (deep research report). It distinguishes from siblings like start_deep_report and get_report_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on polling interval: 'Deep reports typically take 10-20 minutes — poll every few minutes, not every few seconds.' Also notes it's free. Does not explicitly mention when not to use or alternatives, but context implies it's for checking status after starting a report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_visibilityAI Visibility CheckAAsk ChatGPT and Perplexity live (with web search) who they'd recommend in a business's category and city, and report whether THIS business appears. Returns honest appearance counts (never an invented metric), a per-engine split, who gets recommended instead, and which local sites the AI answers cite. AI answers vary substantially between runs — one check is a snapshot, not a stable measurement; re-check over time for the real picture. Call this when a user wants to know if AI assistants recommend a local business. Takes ~10-30 seconds. Price: $0.79 per delivered check.
| Name | Required | Description | Default |
|---|---|---|---|
| website | No | Optional: the business website — a cited domain counts as an appearance | |
| location | Yes | City and state/region, e.g. "Cincinnati, OH" | |
| businessName | Yes | The local business to check | |
| businessType | Yes | Category anchor, e.g. "gym" — the AI assistants are asked category questions, so this is required |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond the readOnlyHint annotation: it explains the live query mechanism, returns honest counts never invented, details the output components, notes variability between runs, and provides timing and pricing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured: starts with purpose, then details output and caveats, and ends with usage trigger. It is informative without being overly verbose, though some sentences could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description compensates by detailing what is returned (appearance counts, per-engine split, alternatives cited, local sites). It also covers timing, pricing, and caveats. This makes the tool's behavior understandable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all 4 parameters. The tool description adds value by explaining that website is optional and a cited domain counts as appearance, and why businessType is required for the AI queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check whether a local business appears in AI assistant recommendations (ChatGPT, Perplexity) for a given category and location. It distinguishes itself from sibling tools by focusing on AI visibility rather than fact-checking or report generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this when a user wants to know if AI assistants recommend a local business' and warns about variability, advising re-checking over time. It does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_report_resultGet Report ResultAFetch a completed deep research report by slug. Free. Returns the long-form report (markdown), a structured-findings JSON block, the action list, and the report card. If the report is still generating you get its status instead; if it failed, the launch charge is refunded automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug returned by start_deep_report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully aligns with the readOnlyHint annotation and adds valuable context: conditional behavior when generating (returns status) and refund on failure. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core action and price, no filler. Each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers inputs, outputs, conditional behavior, and pricing. It is complete enough, though some terms like 'action list' could be elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 100% schema coverage, the description adds marginal value by linking the slug to start_deep_report. The schema's description is already adequate, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a completed deep research report by slug. It lists the specific return components, distinguishing it from sibling tools like check_report_status and start_deep_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (after report completion or to get status) and mentions the automatic refund on failure. However, it does not explicitly contrast with check_report_status for status-only queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingPing MoonlingsAReturns server status, the price list, and (when authenticated) your credit balance. Free — call it to check connectivity and see what this server offers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that the tool is free and that the credit balance is only returned when authenticated, providing useful behavioral nuance. No destructive side effects are mentioned, which is consistent with its read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the returns, the second adds the purpose and cost hint. Every sentence earns its place with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers the main purpose and outputs. It lacks details on error scenarios or the format of status, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description adds the nuance that authentication is required for the credit balance aspect, which is helpful context. There is no parameter-specific information needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns server status, price list, and optionally credit balance when authenticated. It explicitly positions it as a free connectivity check, distinguishing it from sibling tools that perform scans or reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool for connectivity checks and server offerings, providing clear context for when to call it. It does not explicitly mention alternatives or when not to use it, but the context implies it's the simplest tool for a quick health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_gapReview Gap CheckACompare a local business's Google rating and review count against the top same-category rivals nearby, with the gap math done: who leads, the rating delta, the review-volume ratio, and a verdict (leading / rated_equal_or_better_but_outreviewed / trailing). Live Google Maps lookup at call time. Call this when a user wants to know how a business's reviews stack up against local competitors. Takes a few seconds. Price: $0.39 per delivered comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Optional: street address of the SPECIFIC location to compare, e.g. "332 Ludlow Ave" — use for chains/multi-location businesses so the right branch anchors the comparison | |
| location | Yes | City and state/region, e.g. "Cincinnati, OH" | |
| businessName | Yes | The local business to check | |
| businessType | Yes | Category anchor, e.g. "dentist" — rivals are the top Google Maps results for this category nearby |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation (true), the description adds that it performs a live Google Maps lookup, takes a few seconds, and costs $0.39 per comparison. This provides valuable behavioral context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and contains no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters (3 required, 1 optional) and no output schema, the description explains the return values (who leads, rating delta, review-volume ratio, verdict) and the tool's mechanics (live lookup, cost, timing), making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 context for businessType ('Category anchor') and address ('for chains/multi-location businesses'), which adds meaning beyond the schema descriptions. However, no further parameter details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares a local business's Google rating and review count against top same-category rivals, with specific outputs like rating delta, review-volume ratio, and verdict. It distinguishes itself from siblings (e.g., check_facts, check_visibility) which are unrelated to review comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Call this when a user wants to know how a business's reviews stack up against local competitors.' No exclusions or alternatives provided, but the tool's niche is well-defined and no sibling tool overlaps in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_scanCompetitor Quick ScanAA live competitor scan: a research agent finds the business's strongest same-category rival nearby and scouts it (offer, pricing signals, review positioning, what they do that this business doesn't), while two ground-truth lookups run in parallel: ChatGPT/Perplexity sampling for AI-assistant visibility, and a direct Google Places review comparison (reviewSnapshot — the authoritative numbers; finding source URLs are verified against what the agent actually retrieved). The AI-visibility portion is a single-run snapshot — AI answers vary substantially between runs. BLOCKING and slow: typically 2-4 minutes — only call it from contexts that tolerate a long tool call. Price: $1.99 per delivered scan; a failed scan is never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Optional: street address of the SPECIFIC location to scan, e.g. "332 Ludlow Ave" — use for chains/multi-location businesses so the right branch anchors the review comparison | |
| location | Yes | City and state/region, e.g. "Cincinnati, OH" | |
| businessName | Yes | The local business to scan | |
| businessType | Yes | Category anchor, e.g. "ice cream shop" — rival discovery and AI sampling are both category-anchored |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and description adds details about blocking behavior, run time, cost, and result delivery. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose and includes essential details, but is somewhat lengthy. Could be slightly trimmed without losing informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, description outlines what results include (offer, pricing, review comparison). Covers complexity and constraints adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds context beyond schema definitions, such as clarifying that address is for chains and businessType anchors rival discovery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs a live competitor scan, finding a rival and gathering specific data. It distinguishes itself from sibling tools like check_facts and get_report_result by covering a unique scanning function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('only call it from contexts that tolerate a long tool call'), notes blocking nature and slow speed, and includes pricing and failure policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_deep_reportStart Deep Research ReportAInspectLaunch a full overnight-grade research report on a local business: an autonomous research crew maps the competitive landscape, reads the business's and rivals' web presence, and delivers a long-form graded report with structured findings and an action list. ASYNC: this tool returns a slug immediately; the report takes roughly 10-20 minutes. Poll check_report_status, then fetch with get_report_result. Price: $9.99, charged when the report launches; if the report fails, the charge is refunded automatically. Each call starts a NEW report — do not retry a call that already returned a slug.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional research focus, e.g. "we're losing weekend foot traffic — figure out why" | |
| website | No | Optional: the business website, read to ground services and positioning | |
| location | Yes | City and state/region, e.g. "Cincinnati, OH" | |
| businessName | Yes | The local business to research | |
| businessType | Yes | Category anchor, e.g. "dentist" — competitor discovery is category-anchored |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async timing (10-20 minutes), pricing ($9.99 charged on launch, refund on failure), and that each call starts a new report. Annotations are minimal, but description provides rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with clear, front-loaded information. Every sentence adds value (async behavior, pricing, usage warnings). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the async nature and sibling tools, the description fully explains the workflow, pricing, error handling, and uniqueness. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter descriptions. Description adds context: brief optional research focus, website optional but useful, businessType anchors competitor discovery. Some added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it launches a full overnight-grade research report on a local business, mapping competitive landscape and web presence, which distinguishes it from sibling tools like check_report_status and get_report_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the async flow (returns slug, poll with check_report_status, fetch with get_report_result), warns not to retry a call that returned a slug, and notes pricing and failure refund policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
