Revuo.ai MCP
Server Details
The directory AI agents call when a buyer asks an LLM for a B2B software recommendation. Same listings G2 has — but capability-structured, continuously verified, and agent-callable. One listing visible to both audiences.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 14 of 14 tools scored.
Tools are generally distinct, but products.search and products.find_by_capability overlap in capability-based search, causing potential ambiguity. However, descriptions clarify the differences.
Naming follows a dot-separated pattern with verb-noun, but there are inconsistencies: use of underscores (mcp.score_server), varying verb choices (list, find, get, search), and mixing of object and action order.
14 tools cover a comprehensive range of functionality for a directory/MCP server—from browsing categories to detailed tool search and drift detection—without feeling excessive.
The set covers most key operations (CRUD, search, rankings, MCP setup, change detection), but lacks tools for updating or modifying data, which is acceptable for a mostly read-driven directory API.
Available Tools
14 toolscategories.listARead-onlyInspect
Lists all product categories in the directory. Use category slugs to filter product searches in products.search / products.find_by_capability. Response: { categories: [{ slug, name, description }] }. Note: this is a thin call. For a full directory briefing (subcategories, capability slugs per category, product counts, locked-vertical flags), prefer directory.overview as a single up-front call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| categories | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that this is a 'thin call' and specifies the response format, providing additional context beyond annotations. No contradictions.
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, each adding distinct value: main purpose, usage in product search, and comparison to alternative. 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?
Given no parameters and an existing output schema, the description provides the response format explicitly and guides usage. It is complete for 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 tool has zero parameters, and schema coverage is 100% (trivially). The description does not need to add parameter info, and it doesn't. Baseline for 0 params is 4.
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 'Lists all product categories in the directory,' which is a specific verb+resource. It distinguishes itself from the sibling directory.overview by noting that for more detail, directory.overview should be used.
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 tells when to use this tool (to get category slugs) and when not to (for full directory briefing), and suggests the alternative directory.overview. Also implies use in conjunction with products.search and products.find_by_capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
directory.overviewARead-onlyInspect
Single 'call this first' entry-point that briefs an agent on the entire Revuo directory. Returns the taxonomy with subcategories, product counts per category, locked-vertical flags (the three verticals Revuo prioritizes), capability slugs valid per category, and the canonical capability-kind taxonomy (integration/compliance/format/standard/workflow). Use this once at the start of a session to ground every subsequent products.search / products.find_by_capability / tools.find_for_task call. Response: { directory: { name, tagline, url, policyUrl, capabilityKinds[] }, lockedVerticals[], categories[] (each with subcategories[], productCount, isLockedVertical, capabilitySlugs[]), tools: { ...tool-name hints } }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| tools | No | |
| directory | No | |
| categories | No | |
| lockedVerticals | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and openWorldHint. The description adds valuable context about the response structure, locked-vertical flags, and the canonical capability-kind taxonomy. 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 extremely concise (two sentences) and front-loaded with the most critical information ('single call this first'). Every sentence adds value without 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 tool has no inputs and an output schema, the description comprehensively explains the response structure (directory, lockedVerticals, categories, tools) and the purpose of each component. It is fully complete for this overview 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?
There are zero parameters, so the baseline is 4. The description provides no parameter details as none exist, but explains the response structure sufficiently.
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 is a 'single call this first entry-point' that briefs an agent on the entire Revuo directory. It specifies the exact taxonomy and information returned, and distinguishes itself from sibling tools by positioning it as a prerequisite for subsequent calls.
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 instructs to 'call this once at the start of a session' and lists which subsequent tools it grounds (products.search, products.find_by_capability, tools.find_for_task). This provides unambiguous usage guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp.score_serverARead-onlyInspect
Score an MCP server against the Revuo quality rubric. Pass either a product slug (scored from cached probe data on the product's direct-probe MCP entry; fast) OR an endpoint URL (probed live). Returns: { target, server, summary { coreAwarded/Max/Percent, extensionAwarded/Max/Percent, probedAt }, categories[] (ServerMetadata, CapabilityQuality, ConfigurationUX, RevuoExtensions), checks[] (every rubric check with awarded/max/passed/evaluated/fixSuggestion/evidence), topFixes[] (failed checks ranked by points-at-stake), probe (probe diagnostics) }. Core score (max 100) is Smithery-comparable. Extension score covers Revuo-specific signals (response time today; freshness, error envelope, schema stability are not yet implemented and report evaluated=false — excluded from totals, never counted as a failure). A check with evaluated=false is a Revuo gap, not the server's fault. Errors: { error: { code: 'bad_input'|'not_found', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | MCP endpoint URL (HTTPS) to probe and score. Mutually exclusive with slug. | |
| slug | No | Product slug whose direct-probe MCP server to score. Mutually exclusive with url. | |
| refresh | No | When passing slug, force a fresh probe instead of using cached probe data. Default false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| probe | No | |
| checks | No | |
| server | No | |
| target | No | |
| summary | No | |
| topFixes | No | |
| categories | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, openWorldHint=true), the description details that live probing makes network requests, explains caching behavior, return structure, and special cases like evaluated=false. It adds significant 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?
The description is well-structured and front-loaded with the main purpose, but it is somewhat verbose with minor redundancy (e.g., 'Core score (max 100) is Smithery-comparable'). Still, every part serves a purpose.
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 complexity (3 optional parameters, mutual exclusivity, rich output), the description covers all necessary details: return structure, error codes, update semantics, and clarifications for evaluated=false. It is complete alongside the output schema.
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%, but the description adds meaning by clarifying mutual exclusivity of slug and url, explaining that slug uses cached data, and that refresh forces a fresh probe. This goes beyond the schema definitions.
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 scores an MCP server against the Revuo quality rubric, specifying the verb 'Score' and resource 'MCP server'. It distinguishes two modes (slug vs URL) and is distinct from sibling tools which focus on listing, searching, and retrieving product 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 explains when to use slug (fast, cached) vs URL (live probe) and provides context for the refresh parameter. While it does not explicitly state when not to use the tool, the sibling tools cover different operations, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.find_agent_readyARead-onlyInspect
Find products with the highest agent readiness scores — products that are easiest for AI agents to integrate with. Sorted by compositeScore desc; supports skip/limit pagination. All readiness scores are 0-100, higher better. Calibration: <30 = not agent-ready (default minimumScore filter), 30-49 = early/limited, 50-69 = decent, 70-89 = strong, 90+ = exceptional. Ranking basis: compositeScore desc. Tier is NOT a tiebreaker here — buyer intent is technical fit, not paid placement. Every result carries { position (1-based, within the returned page), rank (0..1; 1.0 = top of this page) } so callers can merge results across tools consistently. Response: { products: [{ position, rank, slug, name, tagline, websiteUrl, tier (free|verified|featured), unverified (true when no approved vendor claim), verifiedAt (ISO; nullable), agentReadiness: { compositeScore, apiScore, protocolScore, sdkScore, integrationScore, dxScore } (each 0-100), mcp?: { hasMcpSupport, totalToolCount, serverCount } }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of results to skip (for pagination). Default 0. | |
| limit | No | Maximum number of results to return per page. Caps at 50. | |
| minimumScore | No | Minimum composite agent readiness score (0-100). Higher = more agent-ready. 0 returns everything; 50 is a usable threshold. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| products | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds details about score interpretation (calibration), tiebreaker rules, and positional information for merging results, which goes beyond the 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 quite detailed but every sentence adds value. It is front-loaded with purpose and pagination, followed by calibration and response format. Slightly dense but acceptable for the complexity.
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 output schema is described, the description is fully complete: it covers purpose, pagination, score calibration, ranking nuances, and even the exact response fields. 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?
Input schema coverage is 100%. The description adds meaning by explaining the sorting order, calibration of minimumScore, and that 0 returns everything. This provides useful context 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 it finds products with highest agent readiness scores, and explains the scoring calibration. It distinguishes itself from sibling tools like 'products.search' by focusing specifically on agent readiness ranking.
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 usage for ranking by agent readiness but does not explicitly mention when to use this tool versus alternatives. It lacks 'when not to use' guidance, though the context of sorting and pagination is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.find_by_capabilityARead-onlyInspect
Find B2B SaaS products that support a specific capability — an integration with a named service ('salesforce-integration'), a data format ('xrechnung-support'), an industry standard ('eclass-support'), or a compliance certification ('soc2'). Accepts either a canonical capability slug or natural language; resolves to a structured capability when possible. Ranking basis: currentScore desc (computed editorial score), then name. Paid tier is NOT a ranking input — it appears only as an annotation. Every result carries { position (1-based), rank (0..1; 1.0 = top, scales linearly down by ordinal position) } so callers can merge results across tools consistently. Response: { capability, matchType (none|exactSlug|canonicalSlug|nlpFallback — exactSlug & canonicalSlug are deterministic; nlpFallback is heuristic), resolvedFeatures[], products[] }. Each product: { position, rank, slug, name, tagline, websiteUrl, tier, unverified (true when no approved vendor claim), verifiedAt, evidence[] (per-claim: featureSlug, evidenceUrl, notes, source, confidence) }. Empty: { capability, matchType, message, suggestedSlugs[] } when no capability matched, or products: [] when capability matched but no products claim it yet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| category | No | Optional category slug to scope the search (e.g. 'pim', 'tender-management', 'billing') | |
| capability | Yes | Capability slug ('salesforce-integration') OR natural-language description ('integrates with Salesforce') |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| message | No | |
| products | No | |
| matchType | No | |
| capability | No | |
| suggestedSlugs | No | |
| resolvedFeatures | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details ranking basis (currentScore desc, then name), that paid tier is not a ranking input, and the response structure including position/rank and empty result scenarios. 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 front-loaded with the main purpose and is well-structured, but it is verbose, especially repeating the output schema details. It could be more compact without losing 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?
Given the tool's complexity (three parameters, output schema, annotations), the description is thorough: it covers input variants, ranking, response format for both success and empty cases, and matching types. It provides sufficient context for an AI agent to use the tool correctly.
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% with descriptions for all three parameters. The tool description adds no substantive information beyond what is already in the schema (e.g., capability accepts slug or natural language is in schema). 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 uses a specific verb ('Find B2B SaaS products that support a specific capability') with clear examples of capabilities (integration, data format, standard, certification). It distinguishes itself from siblings like products.search by focusing on capability matching and structured resolution.
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 explains that it accepts capability slugs or natural language and resolves them, but does not explicitly contrast with alternatives like products.search or products.find_agent_ready. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.getARead-onlyInspect
Get full details for a product by slug, including MCP integration data and agent readiness scores. Response: { product: { slug, name, tagline, description, websiteUrl, logoUrl, pricingModel, currentScore (0-100), tier (free|verified|featured), unverified (true when no approved vendor claim), verifiedAt (ISO; absent if never crawled), categories[], knownLimitations?[] (sourced weaknesses, each with evidenceUrl — weigh before recommending), alternatives?[] (neutral, score-ranked same-category options, self excluded, houseProduct disclosed) }, mcp?: { hasMcpSupport, totalToolCount, totalUseCount, servers[] }, agentReadiness?: { compositeScore (0-100), aiSummary } }. Errors: { error: { code: 'not_found', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug (URL-friendly identifier) |
Output Schema
| Name | Required | Description |
|---|---|---|
| mcp | No | |
| error | No | |
| product | No | |
| agentReadiness | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by detailing the response structure (including error codes) and noting that unverified products have no verifiedAt. 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?
Description is front-loaded with purpose and provides structured response details. It is somewhat verbose but well-organized, with clear separation of response sections and error handling.
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 a single parameter and an output schema (implied), the description covers all essential aspects: purpose, response format including nested objects, error codes, and special flags like unverified. No gaps are evident.
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 the description does not add additional parameter semantics beyond what is in the schema. The description focuses on the response rather than parameter details.
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 'Get full details for a product by slug', specifying verb, resource, and identifier. This distinguishes it from sibling tools like products.search and products.find_by_capability, which have different purposes.
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?
Usage is implied (when you need full product details by slug), but there is no explicit guidance on when to use this tool versus alternatives like products.search or products.get_mcp_setup. No exclusions or conditional usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.get_mcp_setupARead-onlyInspect
Get MCP server setup instructions for a product. Returns available servers, their tools, connection details, and whether they support remote (hosted) access. Each server carries a machine-usable connect block: { transport ('http'|'local'), url, mcpJson (paste-ready snippet), claudeMcpAddCommand (claude mcp add ...), installLinkUrl (a tracked link that routes through Revuo for vendor attribution, then redirects to the product) }. For remote servers use mcpJson/claudeMcpAddCommand directly; for local servers follow repositoryUrl. Each server also carries schema { hash, stable, lastChangeAt } — cache the hash and pass it to tools.changes(knownHash) later to detect tool-schema drift (rug-pull / tool-poisoning). Response when MCP support exists: { product: { slug, name, websiteUrl, tier, unverified, verifiedAt }, hasMcpSupport: true, totalToolCount, servers[], agentReadiness? }. Response when product exists but lacks MCP: { product: {...}, hasMcpSupport: false, message }. Errors: { error: { code: 'not_found', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug (URL-friendly identifier) |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| message | No | |
| product | No | |
| servers | No | |
| hasMcpSupport | No | |
| agentReadiness | No | |
| totalToolCount | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true; the description confirms read-only behavior and adds significant detail about the response, including server connection blocks and schema hash usage. No contradiction.
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 with multiple sentences and nested details (e.g., connect block structure, response shapes). While informative, it could be more concise; the main purpose is front-loaded.
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 is extremely thorough, covering success and error responses, caching advice, drift detection, and even response examples. This is far beyond minimal, making the agent well-informed for complex usage.
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 single parameter 'slug' is fully described in the input schema (URL-friendly identifier). The description does not add new meaning beyond the schema, meeting the baseline of 3.
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 'Get MCP server setup instructions for a product' and details what is returned (servers, tools, connection details, remote/local support). It distinguishes from sibling tools like 'products.get' and 'tools.get' by focusing on MCP setup.
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 comprehensive usage context including response structures for MCP support presence/absence and error cases. It hints at caching and drift detection, but does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.searchARead-onlyInspect
Search for B2B SaaS products by name OR by capability. The query is first resolved against the canonical capability taxonomy (e.g. 'salesforce-integration', 'xrechnung-support', 'soc2'); on hit, products that claim that capability are returned. Falls back to name/slug/tagline substring search. Optional category scope. Ranking basis: currentScore desc (computed editorial score), then name. Paid tier is NOT a ranking input — tier appears only as an annotation on results. Every result carries { position (1-based), rank (0..1; 1.0 = top, scales linearly down by ordinal position) } so callers can merge results across tools consistently. Response: { query, matchType (none|exactSlug|canonicalSlug|nlpFallback), resolvedCapabilities[], products[] }. Each product carries { position, rank, tier (free|verified|featured — annotation only), houseProduct (true = built by Revuo's founder; conflict-of-interest disclosure), sponsored (true = paid Featured placement), unverified (true when the listing has no approved vendor claim; omitted otherwise — absence means an approved vendor claim, NOT crawl freshness; use verifiedAt for that), verifiedAt (ISO timestamp of last claim crawl; absent if never crawled), currentScore (0-100), compositeScore (agent-readiness 0-100, nullable), matchedCapability (true if surfaced by capability path) }. Errors: { error: { code: 'not_found'|'bad_input', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — capability slug or natural-language description; falls back to name match | |
| category | No | Optional category slug to filter results |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| query | No | |
| products | No | |
| matchType | No | |
| resolvedCapabilities | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds extensive behavioral details beyond readOnlyHint and openWorldHint: query resolution, fallback, ranking, result structure, tier treatment, error codes. No contradictions.
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?
Very informative but dense; front-loads key info. Could be slightly shortened, but every sentence adds value. Well-structured with logical flow.
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?
Covers query behavior, ranking, result fields, error codes. Despite no output schema provided, description itself is comprehensive. Sufficient for agent understanding.
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 description adds significant meaning: query parameter resolution process, category as optional scope filter. Exceeds schema detail.
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 tool searches for B2B SaaS products by name or capability, with detailed resolution process (canonical taxonomy, fallback). Distinguishes from sibling tools like products.find_by_capability.
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 when to use (search by name/capability) and ranking basis. Lacks explicit when-not-to-use or alternative suggestions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rankings.getARead-onlyInspect
Get the published editorial ranking ("Best {Category}") for a category. Ordering basis: computed editorial score ONLY (verified capability coverage, evidence verification rate & freshness, agent readiness, data completeness — weights published at /api/methodology). Tier is NOT a ranking input for this tool; positions are never sold. Rankings are published snapshots (monthly schedule; manual publishes are marked) — stable between recomputes and citable. Each entry carries { position, rank (0..1), slug, name, score (0-100), breakdown (raw 0-100 per dimension), tier (annotation only), houseProduct (true = built by Revuo's founder — same formula as everyone, disclosed machine-readably), unverified, verifiedAt }. unrankedCount + unranked[] name the category products that failed an eligibility gate, with reasons. Response: { category, computedAt, methodologyVersion, methodologyUrl, trigger, entries[], unranked[] }. Errors: { error: { code: 'not_found', ... } } — also returned when a category has no published ranking yet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max ranked entries to return (caps at 50) | |
| category | Yes | Category slug (e.g. 'pim-software'). Use categories.list for valid slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| entries | No | |
| trigger | No | |
| category | No | |
| unranked | No | |
| computedAt | No | |
| methodologyUrl | No | |
| methodologyVersion | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, non-sale of positions, monthly publication schedule, machine-readable disclosure of houseProduct, and detailed response structure. Complements readOnlyHint and openWorldHint annotations effectively.
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 fairly long but every sentence adds value (ordering, transparency, schedule, response fields). Front-loaded with main purpose. A bit dense but not wasteful.
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?
Extremely complete: includes ordering basis, eligibility gates, error codes, response format, and methodology link. Output schema is described inline, so no gaps. Adequate for a tool of this complexity.
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 already covers both parameters fully (100% coverage). Description adds useful context: category slug usage example and limit cap at 50, enhancing clarity 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?
Clear verb 'Get' targeting 'published editorial ranking' for a specific resource (category). Distinguishes from sibling tools like products.search by focusing on ranking rather than general search.
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 what it does and where to find valid category slugs (categories.list). Does not explicitly mention when not to use, but purpose is well-defined. No direct alternative among siblings for rankings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.changesARead-onlyInspect
Detect whether a product's MCP tool schema has DRIFTED since you cached it — rug-pull / tool-poisoning detection (a server silently changing a tool's description or input schema after you approved it; web search structurally cannot answer this). Pass the product slug and EITHER the schema hash you cached earlier (knownHash, from products.get_mcp_setup → server.schema.hash — the strongest signal: an exact mismatch means the tools changed) OR the ISO-8601 timestamp you cached at (since). With neither, it returns the current fingerprint to cache for next time. A product may expose MULTIPLE servers: knownHash is per-server, so pass server (a qualifiedName) with knownHash on a multi-server product — otherwise knownHash is applied only when there's exactly one server. Re-verify before trusting a previously-approved tool. Response: { product, hasMcpSupport, drifted (did ANY tracked server change vs your reference; null when no reference given), servers[] (each: qualifiedName, currentSchemaHash, schemaStable, lastSchemaChangeAt, toolCount, directlyProbed, driftedSinceKnownHash, driftedSince, advice) }. Errors: { error: { code: 'not_found'|'bad_input', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug whose MCP tool schema to check. | |
| since | No | ISO-8601 timestamp you last cached at. Reports whether a schema change was recorded after it. | |
| server | No | The server qualifiedName your knownHash belongs to. Required with knownHash on a multi-server product. | |
| knownHash | No | The schema hash you cached earlier (products.get_mcp_setup → server.schema.hash). Exact-mismatch drift signal. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| drifted | No | |
| message | No | |
| product | No | |
| servers | No | |
| hasMcpSupport | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral details beyond annotations: it explains drift detection logic, response fields, error codes, and the fingerprint caching behavior. Annotations already indicate readOnly and openWorld, and the description adds context without contradiction.
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 dense but well-structured: it starts with the core purpose, then parameter details, then response schema. While it is lengthy, every sentence adds value. Could be slightly more concise, but it remains effective.
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 output schema exists, the description covers return values comprehensively, including error handling. It explains the response shape (fields like product, drifted, servers) and conditions. No gaps remain for an agent to invoke correctly.
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 description adds significant meaning: explaining knownHash as an exact-mismatch signal, since as a timestamp check, and the condition for using server with multi-server products. This goes beyond the brief 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: 'Detect whether a product's MCP tool schema has DRIFTED since you cached it — rug-pull / tool-poisoning detection'. This is a specific verb+resource combination that distinguishes it from sibling tools like tools.get or tools.search.
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 parameter usage guidance: when to use knownHash vs since, when to pass server, and the scenario of re-verifying previously approved tools. It implicitly distinguishes from web search and other tools, though it does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.find_for_taskARead-onlyInspect
Find the best MCP tools for a given task. Describe what you want to accomplish (e.g. 'manage github issues', 'send slack messages', 'query a database') and get ranked results — each result is one (product, tool) pair, since same-named tools across providers are NOT interchangeable. By default only shows tools available via remote (network-hosted) servers. Audience: agent builders looking for installable MCP tools — for B2B SaaS recommendations, prefer products.search or products.find_by_capability. Ranking basis: relevance score desc (+1 per term hit, +3 for full-phrase hit); within an equal relevance tier, callable-now (Open access) + remote + healthy tools are boosted ahead — never a hard filter (a product-bound tool stays in its own money query), then productName. Paid tier is NOT a ranking input — it appears only as an annotation. Every result carries { position (1-based), rank (0..1; 1.0 = top, scales linearly down by ordinal position) } plus preflight annotations { accessModel (open|keyed|account|commercial), healthScore (0-100, nullable), readOnly, destructive, callableNow (true = usable anonymously right now), setup (one-line 'how to get access' pointer for non-Open tools) }. Response: { task, matchType (none|exactSlug|canonicalSlug|nlpFallback), resolvedCapabilities[], capabilityProducts[] (B2B SaaS products that claim the same capability — empty when matchType=none), results[] (MCP-tool-level matches), buckets { callableNow, requiresSetup } }. Each result: { position, rank, normalizedName, displayName, description, inputSchema, relevance, accessModel, healthScore, readOnly, destructive, callableNow, setup, productSlug, productName, serverQualifiedName, isRemoteCapable, tier, unverified, verifiedAt }. Empty case: { task, matchType, message, suggestedQueries[], suggestedCapabilities[] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tool results to return | |
| access | No | Optional access-class filter: 'open' (callable anonymously), 'keyed', 'account', 'commercial', or 'unknown'. Omit for all — Open tools are boosted, not required. | |
| remoteOnly | No | If true (default), only return tools from remote-capable MCP servers | |
| taskDescription | Yes | Natural language description of the task you want to accomplish |
Output Schema
| Name | Required | Description |
|---|---|---|
| task | No | |
| error | No | |
| buckets | No | |
| message | No | |
| results | No | |
| matchType | No | |
| suggestedQueries | No | |
| capabilityProducts | No | |
| resolvedCapabilities | No | |
| suggestedCapabilities | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. The description adds extensive behavioral detail: relevance scoring formula, boosting logic (callable-now, remote, healthy tools), that paid tier is not a ranking input, and response structure. 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 very long and includes many details about ranking, response fields, and edge cases. While front-loaded with the main purpose, the length reduces conciseness. A more compact description could be better for an AI agent.
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 complexity (many sibling tools, detailed output schema, multiple parameters), the description is exceptionally complete. It covers ranking logic, response format including empty case with suggested queries, and preflight annotations. Output schema exists, so return values are documented separately.
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 meaning beyond schema by explaining taskDescription as 'natural language description' and clarifying the access filter options. It also contextualizes the limit parameter's default. Minor extra value justifies a 4.
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 begins with 'Find the best MCP tools for a given task' which is a specific verb+resource pair. It clearly distinguishes from sibling tools like products.search and products.find_by_capability by specifying audience and use case.
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 when to use this tool ('agent builders looking for installable MCP tools') and when not ('for B2B SaaS recommendations, prefer products.search or products.find_by_capability'). It also explains the ranking basis and default behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.getARead-onlyInspect
Get detailed information about a specific MCP tool, scoped to one product. Pass both the productSlug and the tool name — same-named tools across products are distinct. Response: { tool: { normalizedName, displayName, description, inputSchema, productSlug, productName, serverQualifiedName, isRemoteCapable, accessModel, healthScore, readOnly, destructive, tier, unverified, verifiedAt, position (always 1), rank (always 1.0) } }. Errors: { error: { code: 'not_found', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Normalized tool name (e.g. 'search_issues', 'send_message') | |
| productSlug | Yes | Slug of the product that exposes this tool (e.g. 'linear', 'github') |
Output Schema
| Name | Required | Description |
|---|---|---|
| tool | No | |
| error | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. Description adds response shape (fields like normalizedName, healthScore, etc.) and error format. No contradictions.
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?
Concise, front-loaded with purpose, then details. Every sentence adds value without waste.
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?
Complete given output schema and annotations: covers purpose, parameters, response shape, error handling. No missing context for a single-resource retrieval 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?
Schema covers 100% of parameters with descriptions. Description reinforces need for both parameters and explains why (distinct across products). Adds 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 'Get detailed information about a specific MCP tool, scoped to one product.' Differentiates from siblings like tools.search or tools.list_by_name by specifying single tool retrieval with product scoping.
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 says to pass both productSlug and tool name, notes that same-named tools across products are distinct. Does not explicitly state when to use vs alternatives, but context from siblings implies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.list_by_nameARead-onlyInspect
List every (product, tool) pair that shares a normalized name. A disambiguation lookup — same name across providers does NOT mean the tools are interchangeable. Ranking basis: productName. Paid tier is NOT a ranking input — it appears only as an annotation. Every result carries { position (1-based), rank (0..1) } plus preflight annotations { accessModel, healthScore, readOnly, destructive }. Response: { normalizedName, total, tools[] (each: position, rank, productSlug, productName, displayName, description, inputSchema, serverQualifiedName, isRemoteCapable, accessModel, healthScore, readOnly, destructive, tier, unverified, verifiedAt) }.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Normalized tool name (e.g. 'search', 'create_issue') |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| tools | No | |
| total | No | |
| normalizedName | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ranking basis (productName) and explicitly states paid tier is not a ranking input, only an annotation. Annotations already declare readOnlyHint and openWorldHint, so description adds complementary details.
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 front-loaded purpose. Some redundancy (e.g., paid tier note) but overall efficient and clear.
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?
Covers purpose, ranking, response structure with annotations. Output schema exists, so return values are documented elsewhere. Complete for a lookup 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?
Schema describes the single parameter (name) with examples. Description adds no new semantics beyond what schema provides. With 100% schema coverage, 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?
Clearly states 'List every (product, tool) pair that shares a normalized name' with a specific verb (list) and resource (product-tool pairs). Distinguishes from siblings like tools.search by framing it as a disambiguation lookup.
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 context that same name across providers does not imply interchangeability, implying use for disambiguation. Lacks explicit when-not-to-use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.searchARead-onlyInspect
Search for MCP tools by capability. Each result is one (product, tool) pair — tools sharing a name across providers are NOT interchangeable, so each provider's tool is its own row with its own description and input schema. Ranking basis: semantic relevance to the query (embedding search); on the lexical fallback (searchMode='lexical') results are name-ordered and rank does NOT reflect relevance. Paid tier is NOT a ranking input — it appears only as an annotation. Every result carries { position (1-based), rank (0..1; 1.0 = top) } so callers can merge results across tools consistently, plus preflight annotations { accessModel (open|keyed|account|commercial; whether an agent can call it without becoming a customer first), healthScore (0-100, nullable), readOnly, destructive } so you can judge callability and safety BEFORE selecting. Optional access filter narrows to a single access class. Response: { searchMode ('semantic'|'lexical'), tools: [{ position, rank, normalizedName, displayName, description, inputSchema, productSlug, productName, serverQualifiedName, isRemoteCapable, accessModel, healthScore, readOnly, destructive, tier, unverified (true when no approved vendor claim), verifiedAt (ISO; nullable) }] }. Errors: { error: { code: 'bad_input', ... } }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | Search query to find tools by name or capability. Natural-language phrases work best (semantic search). | |
| access | No | Optional access-class filter: 'open' (callable anonymously), 'keyed', 'account', 'commercial', or 'unknown'. Omit for all. | |
| remoteOnly | No | If true, only return tools available via remote (network-hosted) MCP servers |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| tools | No | |
| searchMode | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations readOnlyHint=true and openWorldHint=true already declaring safety, description adds detailed transparency: explains ranking basis, that paid tier is not a ranking input, and describes preflight annotations in response for callability and safety assessment. No contradictions.
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 thorough but well-structured, front-loaded with core purpose. Every sentence adds value, though length could be slightly condensed without loss.
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 complexity (4 params, rich output schema, annotations), description is complete: explains response format, preflight annotations, error handling, and ranking details. No gaps for agent to execute correctly.
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 parameters with descriptions. Description adds meaningful context beyond schema, e.g., 'Natural-language phrases work best (semantic search)' for query, explains access filter classes, and clarifies remoteOnly behavior.
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 'Search for MCP tools by capability' and specifies that results are (product, tool) pairs with non-interchangeability across providers. This is specific and distinguishes from siblings like 'tools.find_for_task' and 'products.search'.
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?
Explains when to use (searching by capability) and mentions fallback behavior (semantic vs lexical). Includes optional filters like access class and remoteOnly. Could more explicitly state when not to use, but sibling list provides alternatives.
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.
Discussions
No comments yet. Be the first to start the discussion!