Revuo
Server Details
Agent-callable B2B SaaS directory: capability-structured, continuously verified listings.
- 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.
Most tools have clear distinct purposes, but some overlap exists between products.search and products.find_by_capability, and between tools.search and tools.find_for_task. Detailed descriptions help differentiate them, but an agent might still misselect.
The naming follows a rough noun.verb pattern, but there are variations: some verbs use underscores (find_agent_ready, find_by_capability) while others are single-word (list, get, search). The 'mcp.score_server' name deviates from the pattern. Overall readable but inconsistent.
14 tools is well-scoped for a directory service covering product search, detail retrieval, MCP tool discovery, and schema drift detection. Each tool serves a distinct need without excessive redundancy.
The tool surface covers core use cases: browsing categories, searching products, retrieving product/MCP details, and monitoring tool changes. Minor gaps like product submission or user-specific features are absent but not critical for the stated purpose.
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 indicate readOnly and openWorld. Description adds that it's a 'thin call' and specifies response shape (slug, name, description). 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?
Two short sentences plus a note, front-loaded with purpose. Every sentence adds value with 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?
For a zero-parameter tool with annotations and output schema, the description fully covers purpose, usage context, and alternatives. Complete for agent decision-making.
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?
No parameters; schema coverage 100%. Baseline 4 for zero-param tool. Description does not need to add param info.
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 'Lists all product categories' and distinguishes from sibling 'directory.overview' which provides a fuller briefing. Also links to products.search and products.find_by_capability for filtering.
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 (get slugs for filtering) and when not to (prefer directory.overview for full briefing). Provides sibling tool name as alternative.
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 declare readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds value by explaining the tool returns a snapshot of the directory taxonomy and should be called only once per session, providing behavioral context 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?
Description is efficient, front-loading the key usage instruction ('single call this first entry-point'). Every sentence contributes valuable information (purpose, usage, response structure). No redundancy or fluff despite its length.
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 zero-parameter tool with an existing output schema, the description is fully complete. It explains the response shape (directory object, lockedVerticals, categories with subcategories) and explicitly lists all the fields returned, leaving no ambiguity.
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?
No parameters exist, and schema description coverage is 100%. The description does not need to explain parameters but goes beyond by detailing the structure of the returned directory object, which indirectly adds clarity about what information is available without needing input.
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 the tool returns the entire Revuo directory taxonomy including subcategories, product counts, locked-vertical flags, capability slugs, and canonical capability kinds. It explicitly distinguishes itself from sibling tools like products.search and products.find_by_capability by positioning itself as the foundational entry-point that grounds 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?
Description explicitly instructs 'call this first' and 'use this once at the start of a session' to inform all subsequent queries. It lists the sibling tools that depend on this call (products.search, products.find_by_capability, tools.find_for_task), providing 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.
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?
Annotations already mark the tool as readOnly and openWorld. The description adds substantial behavioral context: it performs a scoring operation, uses cached or live data, returns structured results including diagnostics, and explains the meaning of evaluated=false (implementation gaps). 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 front-loaded with the tool's purpose, followed by parameter usage, return structure, and error handling. It is relatively long but all sentences add value, no redundancy. Minor lack of bullet-point structure reduces readability slightly.
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 of a scoring tool with multiple categories, checks, and error modes, the description covers all essential aspects: parameter roles, output shape, core vs extension scores, evaluated=false semantics, and error codes. It explicitly notes unimplemented features, ensuring accurate expectations.
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 clear descriptions for all three parameters (url, slug, refresh). The description reinforces mutual exclusivity and adds operational context (fast vs live), but does not provide significant new semantic meaning beyond what the schema already conveys. Baseline score 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 action ('Score an MCP server') and the resource ('against the Revuo quality rubric'), with distinct usage for cached slug vs live URL. It differentiates from sibling tools which are listing, searching, or retrieving static data.
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 the optional refresh parameter. It clarifies the scoring semantics (evaluated=false is a gap, not a failure). However, it does not explicitly state when not to use the tool or suggest alternatives among siblings, leaving minor ambiguity.
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?
Adds beyond annotations: clarifies ranking (compositeScore desc, tier not tiebreaker), pagination behavior, and score thresholds. No contradiction with readOnlyHint and openWorldHint.
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?
Every sentence adds value: purpose, sorting, calibration, ranking nuance, and response format. Efficiently structured and 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?
Comprehensive: explains input params, output structure, score interpretation, and pagination. No gaps given presence of output schema and rich annotations.
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; description adds default minimumScore (30), calibration, and pagination semantics. Provides extra context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds products with highest agent readiness scores, using specific verb and resource. Distinguishes from siblings like products.search and products.find_by_capability by focusing on ease of AI integration.
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 on sorting, pagination, and score calibration. Implicitly tells when to use (for agent readiness), but lacks explicit comparisons to alternative tools like 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.
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?
The description adds significant behavioral detail beyond annotations: ranking basis (currentScore desc), paid tier handling (not a ranking input), result structure with position and rank, empty response cases, and match type distinctions. No contradiction with readOnlyHint or openWorldHint.
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 efficient, organized from input to output, with examples and edge cases. Every sentence adds value, and key information is front-loaded. 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 the tool's complexity (3 params, output schema exists, annotations present), the description covers all essential aspects: input formats, ranking logic, response shape, empty results, and annotations behavior. It is self-contained and leaves few questions.
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?
Although schema coverage is 100%, the description enriches the capability parameter by explaining it accepts both slugs and natural language, defines match types (exactSlug, canonicalSlug, nlpFallback), and details how resolution works. This goes well beyond the schema's minimal description.
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 finds B2B SaaS products supporting a specific capability, with concrete examples (salesforce-integration, xrechnung-support, etc.). It distinguishes from sibling tools by focusing on capability-based search, making the purpose unambiguous.
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 it accepts canonical slugs or natural language and describes match types, providing clear context. However, it does not explicitly contrast with sibling tools like products.search, leaving some ambiguity about exact usage boundaries.
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 and openWorldHint. The description adds error behavior (not_found), field semantics (unverified, knownLimitations), and hints at advisory usage ('weigh before recommending'). Rich context beyond 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?
Front-loaded with the core purpose. The response shape is detailed but well-structured. Could be slightly more concise, but every part adds value.
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 of the response (nested objects, multiple fields, error codes), the description provides a comprehensive outline. The output schema is effectively described, making it fairly 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?
Input schema has 100% coverage for the single parameter 'slug'. Description does not add new details beyond schema's 'URL-friendly identifier'. 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?
States clearly that it gets full details for a product by slug, including specific response fields. Distinguishes from siblings like 'products.get_mcp_setup' and 'products.find_agent_ready' by being the general get-details tool.
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?
No explicit when-to-use or alternatives mentioned. The purpose is clear but the description lacks guidance on choosing between this tool and other product-related tools.
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 declare readOnlyHint=true (safe read) and openWorldHint=true. Description adds significant behavioral context: server structures, connect blocks with attribution tracking, schema caching for drift detection, response formats, error codes. 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?
Description is detailed but front-loaded with main purpose. Every sentence adds value, though slightly verbose. Structured with clear sections for connect blocks, caching, response shapes.
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 one parameter and complex output with known output schema, description fully explains input, output format, error handling, and behavioral nuances (tracking, caching). Complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'slug' with 100% schema coverage. Schema description 'Product slug (URL-friendly identifier)' is sufficient. Description does not add additional meaning but maintains baseline.
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 states specific verb 'Get MCP server setup instructions' for a product, including what is returned (servers, tools, connection details, remote/local access). It clearly distinguishes from siblings like 'products.get' (basic info) and 'products.find_agent_ready' (filtering).
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 by detailing what the tool returns, but lacks explicit guidance on when to use it vs alternatives or prerequisites. No when-not-to-use or exclusionary statements.
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?
Beyond annotations (readOnlyHint, openWorldHint), the description expands extensively on behavioral traits: ranking logic, tier as annotation only, conflict-of-interest disclosure (houseProduct), sponsored flag, unverified interpretation, verifiedAt semantics, and error codes. This provides comprehensive transparency.
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, front-loading the core search logic. While slightly long, every sentence contributes value. It could be slightly more concise, but it remains 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?
Given the output schema is fully described in the description, including ranking, errors, and all product fields, the tool is completely documented. 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?
Schema coverage is 100%, but the description adds meaningful context: query resolution prioritizes capability taxonomy then falls back to name/substring match; category is an optional filter. This goes beyond the schema's 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 searches for B2B SaaS products by name or capability, with a fallback mechanism. It distinguishes itself from siblings like products.find_by_capability and products.find_agent_ready by detailing the search resolution process.
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 clear use context, including when the search resolves against capability taxonomy vs falling back to name search. However, it does not explicitly mention when to use this tool over siblings, leaving some ambiguity.
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?
Beyond readOnlyHint and openWorldHint annotations, the description adds critical behavioral traits: rankings are published snapshots on a monthly schedule, stable between recomputes, and citable. It explains the editorial score basis and confirms positions are never sold, adding value beyond 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 dense but well-structured: purpose first, then ordering basis, key traits, response details. Every sentence adds value, though it could be slightly more concise. It is front-loaded with the most critical 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 output schema exists and schema coverage is 100%, the description thoroughly explains the response fields (position, rank, score, breakdown, unranked info) and error format. It covers all essential aspects for an agent to understand the tool's output.
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 both parameters. The description adds context: category slug example and reference to categories.list for valid slugs, and confirms default and cap for limit. This extra context improves usability.
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 gets the published editorial ranking for a category, specifies the ordering basis (computed editorial score only), and distinguishes it from tier-based filtering or paid placements. It is specific and distinct from sibling tools like categories.list or 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?
The description provides strong context on when to use the tool (getting published rankings) and clarifies key caveats (tier not a ranking input, positions never sold). It does not explicitly list alternatives or when-not-to-use, but the context is sufficient for appropriate usage.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds significant behavioral context: it's for detecting 'rug-pull / tool-poisoning', explains the response structure, and notes that web search cannot answer this. 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 lengthy but well-structured, with important information front-loaded. Every sentence adds value, though the inline response and error details could be slightly trimmed given the output schema exists. Still, it remains clear and 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 tool's complexity (4 parameters, annotations, output schema), the description is comprehensive. It covers the core logic, edge cases (multi-server, missing parameters), and expected response and error codes. No gaps are apparent.
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 parameters are documented. The description adds meaningful semantics beyond the schema: it explains the source of knownHash (from products.get_mcp_setup), the format of since (ISO-8601), and the role of server in multi-server products. This enhances understanding.
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: detecting drift in a product's MCP tool schema. It uses specific verbs ('Detect') and resources ('product's MCP tool schema'), and distinguishes itself from sibling tools by focusing on schema drift detection, a unique 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?
The description provides clear usage instructions: pass slug with either knownHash or since timestamp for drift detection, and explains multi-server handling. While it doesn't explicitly state when not to use it, the context implies it's for re-verifying cached schemas, contrasting with fetching current schema via products.get_mcp_setup.
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 substantial behavioral context: ranking algorithm details (relevance scoring, boosting of callable-now/remote/healthy tools), access model explanations, and how callableNow is determined. It does not contradict 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 lengthy but well-structured with clear sentences and logical flow. It covers many details necessary for proper use. Slightly verbose but earns its length with valuable 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?
The description is fully complete: it explains the response structure (including empty case), output schema exists, and edge cases are covered. Together with annotations and schema, the agent has all necessary information to invoke 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 parameter descriptions already in the input schema. The description adds minor context (e.g., 'Open tools are boosted, not required') but does not significantly enhance understanding of parameter semantics beyond what the schema provides.
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 explicitly states the tool's purpose: 'Find the best MCP tools for a given task.' It distinguishes from siblings by directing B2B SaaS recommendations to products.search or products.find_by_capability. The detailed explanation of ranking and result structure reinforces clarity.
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 usage guidance, including the intended audience ('agent builders looking for installable MCP tools') and clear when-not-to-use advice ('for B2B SaaS recommendations, prefer products.search or products.find_by_capability'). It also explains defaults like remoteOnly=true.
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?
The description details the response shape (fields like normalizedName, displayName, etc.) and error format (code 'not_found'). It does not contradict annotations (readOnlyHint, openWorldHint). It adds value beyond annotations by explaining the structure and potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the purpose and then provides response/error details. It is concise and efficient, with 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 the presence of an output schema and the simplicity of the tool (2 required params, no enums, no nested objects), the description covers the necessary behavioral and usage context. It includes a representative response shape and error case, making it complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context that the tool name is normalized and that names are not unique across products, reinforcing the schema's parameter descriptions. This is a slight improvement but not major.
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 retrieves detailed information about a specific MCP tool, scoped to one product. It uses specific verbs and resources, and distinguishes from sibling tools like tools.list_by_name (listing) or tools.search (searching).
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 tells the user to pass both productSlug and tool name, and clarifies that same-named tools across products are distinct. While it doesn't explicitly state when not to use it, the context from sibling tools implies that for listing or searching, other tools should be used.
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?
The description adds significant behavioral detail beyond annotations, including ranking basis (productName, not paid tier), result structure with position/rank, and preflight annotations per tool. No contradiction with readOnlyHint=true.
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 concise and front-loaded with the main purpose. It efficiently conveys key details without extraneous information, though it uses multiple sentences.
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 presence of an output schema, the description thoroughly explains the response structure (normalizedName, total, tools array with fields) and key behavioral notes (ranking, preflight annotations), making it 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% with a clear description for the 'name' parameter. The tool description reinforces the parameter's purpose (normalized tool name) but does not add new semantic information beyond the 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 it lists every (product, tool) pair sharing a normalized name, positioning it as a disambiguation lookup. It distinguishes from siblings like tools.search and tools.get by focusing on normalized name grouping.
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 explains when to use this tool (given a normalized name to see all tools with that name) and notes that same name across providers does not mean interchangeability. It lacks explicit comparison to sibling tools but provides sufficient context.
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?
The description adds extensive behavioral context beyond annotations: it explains the result structure with position and rank, preflight annotations for callability and safety, search mode behavior, and error handling. This significantly helps the agent understand what to expect and how to interpret results.
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 with the purpose front-loaded, followed by details on search modes, result structure, and errors. It is comprehensive without being overly verbose, though it could be slightly more concise in the response specification part.
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, the description covers all necessary aspects: purpose, parameter behavior, search modes, ranking, result structure with full fields, and error handling. It is completely sufficient for an agent to invoke the tool correctly and interpret responses.
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 schema already documents all parameters. The description adds context about the search mechanism and the 'access' filter's purpose, but does not significantly elaborate on individual parameter semantics beyond the schema. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for MCP tools by capability.' It specifies that each result is a (product, tool) pair and emphasizes that tools with the same name across providers are not interchangeable, which distinguishes it from sibling tools like tools.list_by_name or tools.find_for_task.
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 semantic vs lexical search, how ranking works, and the optional access filter. It does not explicitly state when not to use this tool or provide direct alternatives, but the detail about search modes and ranking provides clear context on appropriate usage.
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!