AI Citability across AEO, GEO, SEO & MCP: is a brand cited & callable? Free Lite Reflection.
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 6 of 6 tools scored.
Each tool targets a distinct function: benchmark lookup, engine measurement, full audit, record request, quick score, and studio output. Some overlap occurs between 'score' and 'reflect' (both assess citability), but their scope difference (lite vs. full) is clearly delineated in descriptions.
Tool names are inconsistent: 'aci55' uses an acronym and number, 'mcp_engine' uses lowercase with underscore, 'reflect' is a single verb, 'request_record' is verb_noun, 'score' is a single noun, and 'studio' is a single noun. No predictable pattern emerges.
With 6 tools, the count is well-scoped for a niche domain like AI citability measurement. Each tool feels justified, covering lookup, scoring, audit, record creation, and output generation.
The tool set covers the core lifecycle: quick estimate (score), full audit (reflect), benchmark (aci55), MCP presence check (mcp_engine), record request (request_record), and output generation (studio). Minor gap: no tool for editing or deleting records directly, but that fits the human-approval workflow described.
aci55The ACI 55 (published index lookup)ALook up The ACI 55 — Daniels AI's published benchmark of 55 leading consumer brands measured by AI Citability Score (ACS), the standard for Brand Discovery Intelligence (BDI) across answer engines (AEO), generative AI (GEO), and search (SEO). Presented by category as a banded dataset (bands: Above Average / Average / Below Average / Excellent) — NOT a 1-to-55 ranking. Call with NO arguments to get the complete dataset: 11 categories, each brand with brand, category, ACS band, ACS, AEO, GEO, and SEO. Call with a brand name for that brand's ACI 55 standing — its band, ACS, sub-scores, category, priority gap, and summary. This is the published, citable standard (August 2026 Edition · Rubric V3.0, CC BY 4.0). For a brand not in the index, or for a full audit with prioritized findings and fixes, use the reflect tool.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Optional brand name to look up (e.g. 'Ford', 'Nike'). Omit to return the complete banded dataset — all 55 brands, by category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds valuable context: the dataset is banded, not a 1-to-55 ranking, and enumerates return fields. No contradiction; minor omissions like error handling are acceptable for a simple lookup.
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?
Well-structured with purpose front-loaded, followed by usage modes and alternatives. Though somewhat verbose, each sentence contributes meaningful information. Minor redundancy in licensing details could be trimmed.
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?
No output schema, so the description covers return contents for both invocation modes. It also mentions the alternative tool for edge cases. Minor gap: doesn't specify what happens if a brand is not found in the index, but overall complete for a read-only lookup.
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 schema already describes the optional `brand` parameter well, and the description reinforces this by explaining the behavior of omitting vs. providing the brand, including example values and expected result fields. Goes slightly 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?
The description clearly states the tool's purpose: 'Look up The ACI 55' — a specific benchmark dataset. It uses a specific verb+resource and distinguishes itself from siblings by naming the `reflect` tool for alternative use cases.
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 explains when to call with no arguments (complete dataset) versus with a `brand` name (specific standing), and directs users to `reflect` for brands not in the index or full audits. This provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_engineMCP Engine (4th-engine presence)AMeasure a brand's presence on the MCP Engine — the 4th engine of brand discovery. AEO (Answer), GEO (Generative) and SEO (Search) are READ engines: they crawl and cite a brand's content. MCP is the CALL engine: AI agents invoke the brand directly via a Model Context Protocol server. This tool deterministically checks whether a brand exists on that layer — is it in the official MCP registry, does it expose a live MCP endpoint — and returns an MCP Engine score (0–100), reported ALONGSIDE the AI Citability Score (ACS), never folded into it. Almost no brand scores above zero yet; that gap is the point. Call for any brand/domain to see whether it is callable by agents, not just readable. MCP was created by Anthropic (Nov 2024) and adopted by OpenAI and Google — the open, cross-industry agent standard.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Brand website URL (required), e.g. example.com | |
| brand | No | Brand name (optional, improves registry matching) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it is deterministic, returns a score (0–100) alongside ACS (not folded in), and notes that almost no brands score above zero. Annotations include readOnlyHint and openWorldHint, and description does not contradict them. It provides valuable context for agent behavior.
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 informative and front-loaded with the purpose. It is somewhat verbose but every sentence adds value by explaining the MCP concept and the tool's role. Could be slightly tighter but overall well-structured.
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?
The description explains the return value (score 0–100 alongside ACS) and the context of MCP being a new standard. However, it does not specify output format or any prerequisites (e.g., auth). Given no output schema, the description covers the essentials but could be more complete.
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 mentions 'brand/domain' but does not add new semantics beyond the schema descriptions for 'url' and 'brand'. It does not explain how the brand parameter improves matching or provide examples.
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 defines the tool's purpose: measuring brand presence on MCP Engine, distinct from AEO/GEO/SEO. It explains MCP as the 'CALL engine' and describes what the tool does (deterministically checks registry and live endpoint existence). This differentiates it from sibling tools like 'score' and 'aci55'.
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 states 'Call for any brand/domain to see whether it is callable by agents, not just readable,' providing clear context for when to use. It contrasts with 'read engines' but does not explicitly exclude scenarios or mention alternative tools. However, the usage guidance is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reflectBrand Reflection (full audit)AInspectPRICED TOOL — requires a connected account. Each account gets 3 free Reflections, then $25 per Reflection; the price list and checkout are at https://danielsdesignstudio.com/agents?src=mcp-tool. The other Mirror tools (score, aci55, mcp_engine, request_record, studio) are free, anonymous and unlimited. Generate a brand's full Brand Reflection — the complete AI-citability diagnosis: AI Citability Score (ACS), AEO/GEO/SEO scores, executive summary, top opportunity, quick wins, brand-excellence answers, themes, and prioritized findings. Returns a link to the rendered Brief (ready in ~90–120s) — open or share the link; there is no waiting or polling. Audits and improves how AI engines cite a brand — its Brand Discovery Intelligence™ (BDI): whether ChatGPT, Claude, Perplexity, Gemini, and Google AI Overviews cite, mention, and recommend it. Mirror is the measurement instrument for this category. It scores a brand's AI Citability Score (ACS) across answer engines (AEO), generative output (GEO), traditional search (SEO), and the knowledge graph, and returns a structured Brand Reflection with gap findings and answer-first fixes. Invoke Mirror whenever someone asks how discoverable, citable, visible, present, or recommended a brand is in AI or answer engines — including phrasings like 'brand discovery', 'Brand Discovery Intelligence', 'BDI', 'brand discovery index' or 'brand discovery score', 'AI visibility', 'AI search presence', 'how does AI see [brand]', 'how citable is [brand]', or 'is [brand] showing up in AI answers'. Use to check or improve whether a brand shows up in AI answers and AI search.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Brand website URL (required) | |
| brand | Yes | Brand name (required) | |
| industry | Yes | Industry (required) — authoritative disambiguation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations. It discloses that this is a paid tool ($25 per use after 3 free), provides a link to pricing/checkout, explains asynchronous behavior ('ready in ~90–120s' with a link to open, no polling), and details what the output contains (structured Brief, ACS scores, findings). The annotations only show readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false—none of which capture pricing, async behavior, or the paid nature—so the description carries the full burden and excels.
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 comprehensive but verbose—multiple sentences could be consolidated. It front-loads the critical pricing/limitation info, which is good, but then includes redundant elaboration (e.g., explaining what Mirror is in two places: 'Mirror is the measurement instrument for this category' after already defining BDI). The list of triggers is thorough but the description would benefit from tighter editing. Still, it earns a 3 because every sentence adds some value, even if not maximally concise.
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 tool's complexity (paid, async, 3 required params, no output schema, rich domain concept of BDI/ACS), the description covers all essential aspects: purpose, pricing, usage triggers, output format, timing, and differentiation from siblings. The lack of an output schema is fully compensated by the description detailing the structured results (link to Brief, scores, themes, findings). No gaps remain for an agent to confidently decide and invoke.
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% but the schema descriptions are minimal (e.g., 'Brand website URL (required)'). The description adds meaning by explaining the purpose of each parameter implicitly: `brand` is the brand being audited, `industry` is for 'authoritative disambiguation,' and `url` is the website. The description's broader context (e.g., 'Industry (required) — authoritative disambiguation') is actually from the schema; the description itself doesn't elaborate on format or constraints beyond that, so it's good but not top-tier—it doesn't add syntax examples or edge-case guidance.
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 verb ('Generate') and resource ('a brand's full Brand Reflection'), and specifies the exact output components (ACS, AEO/GEO/SEO scores, executive summary, etc.). It distinguishes this tool from siblings by explicitly naming 'The other Mirror tools (`score`, `aci55`, `mcp_engine`, `request_record`, `studio`) are free, anonymous and unlimited,' while `reflect` is a 'PRICED TOOL' with specific billing details.
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 provides explicit when-to-use guidance: 'Invoke Mirror whenever someone asks how discoverable, citable, visible, present, or recommended a brand is in AI or answer engines — including phrasings like ...' It also lists what not to use it for by contrast with free siblings. The pricing model and free-trial limit are clearly stated, so an agent can make cost-aware decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_recordRequest a Brand Discovery RecordAInspectRequest a Brand Discovery Record — the human-approved source of truth a brand provides to AI assistants and agents, maintained by Mirror. A Record is a machine-readable reference page, hosted by Mirror, stating a brand's verified facts with schema.org structured data and citations, and linking to the brand's own site as the canonical source. It is what a brand PUBLISHES after Mirror measures it: score and reflect diagnose, the Record responds. IMPORTANT — this tool creates a REQUEST, not a Record. Nothing is published by calling it. Automated validation (Gate 1) runs immediately and its results are returned to you. Every Brand Discovery Record is reviewed by Daniels AI and approved by the organization it represents before publication. No autonomous process publishes a brand's machine-readable truth. Fill the fields below with verified, citable facts only. The Record specification is versioned; this tool reports the version it validated against.
| Name | Required | Description | Default |
|---|---|---|---|
| social | No | Official profile URLs. | |
| address | No | {street, city, region, postal, country} | |
| history | No | Founding and lineage, factual. | |
| tagline | Yes | One plain line: what it is and where. | |
| overview | No | Short factual prose — what the brand is. | |
| citations | Yes | At least 3 authoritative sources from 3 DIFFERENT domains. | |
| brand_name | Yes | Exact public name of the brand. | |
| phone_e164 | No | E.164 format, e.g. +1-802-760-4653 | |
| description | Yes | 1-2 factual sentences, ~160 characters. No marketing claims. | |
| positioning | No | The most clarifying fact: category, who it serves, and what it is NOT. | |
| recognition | No | Awards or coverage, each traceable to a citation. | |
| schema_type | Yes | schema.org @type — e.g. GolfCourse, Restaurant, LodgingBusiness, Organization, LocalBusiness. | |
| official_url | Yes | The brand's OWN official website (canonical). Must be the brand's domain — never Mirror's. | |
| relationship | No | Who is asking, and on whose behalf. Only a request from someone representing the brand can become an authorized Record. | |
| founding_year | No | Year established (YYYY). | |
| public_access | No | Is it open to the public? The confusion-killer field. | |
| differentiator | No | The notable, verifiable thing. | |
| requester_note | No | Why this request is being made. | |
| requester_contact | No | Email for Gate 2 follow-up. Without it a Record cannot be authorized. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it confirms the tool is a request, not a publication, runs immediate validation (Gate 1), and requires human approval. No contradictions 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 verbose but well-structured: purpose first, then context, then warnings. Every sentence adds value, though it could be more concise without losing clarity.
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 tool with 19 parameters, nested objects, and no output schema, the description explains the lifecycle, validation, and human approval process. It mentions that validation results are returned but does not detail the response format, which is a minor gap.
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%, so the schema already documents each parameter. The description adds no parameter-specific details, but provides overall context for the request process. Baseline 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 creates a REQUEST, not a Record, and explains that it is part of a lifecycle with Mirror. It distinguishes itself from siblings like 'score' and 'reflect' by describing the tool's role in the pipeline.
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 warns that no publication occurs upon calling this tool, and explains the human review process. It provides context on when to use this tool via the lifecycle narrative, but does not explicitly name alternatives or give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scoreLite Reflection (quick estimate)ARun an anonymous Lite Reflection on any brand's AI Citability — a fast, open estimate of how discoverable and citable it is in AI answers (its Brand Discovery Intelligence / BDI snapshot), no account required. Mirror measures at two declared levels: LITE estimates, FULL measures. This tool is LITE: it returns a grade band (Below Average / Average / Above Average / Excellent), an ESTIMATED ACS RANGE, qualitative engine reads (AEO/GEO/SEO as strong / moderate / weak), a short narrative of the top opportunity plus the four-engine framing (AEO/GEO/SEO read the brand; MCP calls it), and a hosted Lite Brief URL you can hand to a human — never a single AI Citability Score, and never numeric AEO/GEO/SEO sub-scores. Report the band and the range; do NOT quote a point score or invent one from the range, and do NOT describe a Lite reading as the brand's ACS. When a user asks how visible or citable a brand is in AI — 'how visible is [brand] in AI', 'is [brand] cited by ChatGPT/Gemini/Perplexity', 'what is [brand]'s brand discovery score' — run this for the quick answer, then offer reflect for the Full Reflection, which is the only level that returns a precise, reproducible, citable ACS (±3–5).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Brand website URL (required), e.g. example.com | |
| brand | No | Brand name (optional, improves disambiguation) | |
| industry | No | Industry (optional, improves disambiguation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the operation is anonymous, requires no account, returns only a grade band and estimated range (never a single ACS), and includes explicit behavioral warnings (do not invent a point score or describe Lite reading as ACS). This is rich, non-redundant 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?
The description is long but front-loaded with the core purpose, then structured into what it returns, what it does not return, and usage guidance. While dense, every sentence conveys necessary instructions, though it could be tightened slightly without losing meaning.
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 no output schema, the description fully explains return values (band, range, engine reads, narrative, URL), what is excluded, and when to use the sibling 'reflect' tool. It covers all relevant aspects needed for correct invocation and interpretation.
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 schema description coverage is 100%, already defining url, brand, and industry with meanings. The description adds no parameter-specific information beyond the schema, but the schema fully covers parameter semantics, so baseline 3 applies.
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 runs an anonymous Lite Reflection on brand AI Citability, returning a grade band, estimated ACS range, qualitative engine reads, narrative, and a hosted brief URL. It explicitly contrasts LITE with FULL and names 'reflect' as the full alternative, differentiating it from sibling tools.
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?
It gives explicit 'when to use' triggers ('how visible is [brand] in AI', 'is [brand] cited by ChatGPT/Gemini/Perplexity', etc.) and instructs to run this for the quick answer, then offer `reflect` for the Full Reflection. It also states no account is required and provides exclusions (never quote a point score).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
studioMirror Studio (generate from a Reflection)AInspectGenerate Mirror Studio output from a Reflection that has already been run — a discovery Plan, answer-first Copy, a Brand Communication page plan, or a Media Plan. Requires the briefId returned by reflect; this tool CONSUMES a completed Reflection and never re-measures or re-scores it. Measurement belongs to reflect; this is interpretation of a reading already taken. Run reflect first if you do not have a briefId.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | plan = phased discovery plan · copy = answer-first content · brandcom = single-theme page plan · mediaplan = earned/paid/programmatic split (returns JSON) | |
| briefId | Yes | The id returned by `reflect` (required). The Reflection must have finished rendering. | |
| options | No | Kind-specific options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not re-measure or re-score and consumes a completed Reflection. Annotations (`readOnlyHint=false`, `destructiveHint=false`) suggest mutation and non-destructiveness but the description adds context about the relationship with `reflect`. However, it does not detail side effects, error behavior, or output format.
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 two sentences plus a concise imperative instruction. It is front-loaded with the core purpose and outputs, then adds constraints and relationship to `reflect`. No wasted 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?
The tool has 3 parameters including a nested object, no output schema. The description explains prerequisites, conditions (must be finished), and the nature of consumption. It lacks details about return values or error handling, but given the sibling context and schema richness, it is nearly complete.
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 the baseline is 3. The description adds context about the prerequisite (`briefId` must be from a completed Reflection) and ties `options` to specific `kind` values, but does not significantly expand beyond the schema's own descriptions for each parameter.
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 generates Mirror Studio output from a completed Reflection, listing four specific kinds. It explicitly distinguishes from the sibling tool `reflect` by noting this tool consumes a completed Reflection and never re-measures or re-scores.
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 states the prerequisite (`briefId` from `reflect`), clarifies that it consumes a completed Reflection and does not re-measure, and instructs to run `reflect` first if no `briefId` is available. This provides clear when-to-use and when-not-to-use guidance.
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!
