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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 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.
categories.listALists 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 | |||
| Name | Required | Description |
|---|---|---|
| error | No | |
| categories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context: it is a 'thin call', the response structure, and the note about directory.overview. This goes beyond annotations but is not extremely rich, hence 4.
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 sentences plus a note. Every sentence adds value: purpose, usage, 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?
For a tool with no inputs and an existing output schema, the description is complete. It explains the output (categories with slug, name, description), a usage hint, and an alternative. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% (empty). The description adds value by explaining the output format, which is beyond what the schema provides. Baseline 4 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 it lists all product categories and explains the purpose: to get category slugs for filtering product searches. It distinguishes itself from directory.overview by calling itself a 'thin call' and noting the alternative provides a 'full directory briefing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to retrieve category slugs for filtering) and when to prefer an alternative ('prefer directory.overview as a single up-front call'). This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
directory.overviewASingle '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 | |||
| Name | Required | Description |
|---|---|---|
| error | No | |
| tools | No | |
| directory | No | |
| categories | No | |
| lockedVerticals | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context by detailing the return structure (taxonomy, categories, product counts, locked-vertical flags, capability slugs, capability-kind taxonomy) and the response format. 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 a single paragraph that front-loads the purpose and then details the return value and usage. It is somewhat lengthy but every sentence adds value, explaining both behavior and response structure. Very slight redundancy (e.g., 'taxonomy' and 'categories' overlap) but still concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, the presence of an output schema (mentioned in context signals), and annotations, the description is fully complete. It explains the tool's purpose, when to use it, and exactly what it returns, leaving no ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline score is 4. The description does not need to explain parameters but adds rich meaning about the output structure, which is beyond what the empty 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 clearly states it is a 'Single call this first entry-point' that 'briefs an agent on the entire Revuo directory,' specifying the verb (overview) and resource (directory). It distinguishes itself from sibling tools by explaining it grounds subsequent searches and tool 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 says to use it 'once at the start of a session' and lists the sibling calls it grounds, 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_serverAScore 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. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| probe | No | |
| checks | No | |
| server | No | |
| target | No | |
| summary | No | |
| topFixes | No | |
| categories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description aligns by explaining the tool is read-only and returns score data. It also discloses that checks with evaluated=false are Revuo gaps, not server faults, adding context beyond annotations. A small deduction for not explicitly stating that the tool does not modify any resources, though it's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, starting with the main purpose, then detailing modes, return values, and special notes. It is slightly verbose but each sentence adds necessary context. Could be tightened by removing some redundant phrases, but overall efficient.
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 (two modes, return structure with multiple fields), the description covers all aspects: mode selection, return object, error handling, and special case of evaluated=false. Output schema exists and is referenced, so return values are fully documented.
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 each parameter described. The description adds value by clarifying the relationship between slug and url (mutually exclusive) and explaining the refresh parameter's effect. This compensates for the lack of enum values or nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it scores an MCP server against the Revuo quality rubric, with two distinct modes (slug for cached, fast; endpoint URL for live probe). This verb+resource combination uniquely identifies the tool and differentiates it from siblings, which are about listing, searching, and managing categories/products/tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use slug (cached probe data, fast) vs endpoint URL (live probe), and notes mutual exclusivity. Also describes the refresh parameter for forcing a fresh probe. Provides clear context for choosing between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.find_agent_readyAFind 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. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| products | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint, openWorldHint) by detailing the ranking basis, calibration thresholds, tiebreaker behavior, and the exact structure of the response including fields like position, rank, and agent readiness sub-scores. This provides comprehensive behavioral insight.
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 clear sections for purpose, pagination, calibration, and response format. It is slightly lengthy but every sentence adds value. Front-loading the purpose and sorting makes it immediately useful.
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 (scoring, pagination, multiple response fields), the description is remarkably complete. It covers the scoring scale, calibration, pagination behavior, tiebreaker rules, and the full response object structure. No output schema is needed because the description provides all necessary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters (skip, limit, minimumScore) with default values. The description adds valuable context: it explains the meaning of minimumScore thresholds (e.g., default 30 filters out non-agent-ready products) and notes that skip/limit enable pagination. This enhances understanding beyond the schema alone.
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 finds products with the highest agent readiness scores, defines the scoring scale (0-100), and explains the sorting by compositeScore. This clearly distinguishes it from siblings like 'products.find_by_capability' or 'tools.find_for_task' which focus on other aspects.
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 the tool returns products sorted by compositeScore descending, supports pagination via skip/limit, and has a default minimumScore filter. It also clarifies that tier is not a tiebreaker. However, it does not explicitly state when to use this tool versus alternatives like 'products.search' or 'rankings.get', leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.find_by_capabilityAFind 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') |
| Name | Required | Description |
|---|---|---|
| error | No | |
| message | No | |
| products | No | |
| matchType | No | |
| capability | No | |
| suggestedSlugs | No | |
| resolvedFeatures | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations, detailing ranking (currentScore desc, then name), that paid tier is not a ranking input but appears as annotation, and that results include position and rank for merging across tools. Also explains match types and empty responses.
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?
Though lengthy, every sentence adds necessary detail about match types, ranking, and response structure. Information is front-loaded with purpose, then progressively detailed.
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 fully covers the tool's purpose, behavior, ranking, match types, and response structure, even though an output schema exists. No gaps remain for this complex 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 coverage is 100%, so baseline is 3. The description adds value by explaining that 'capability' accepts natural language or slug, that category scopes search, and what ranking behavior is, improving understanding beyond schema alone.
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, listing types (integration, data format, standard, compliance). It distinguishes from siblings like 'products.search' by focusing on capability matching 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?
Provides clear context for when to use (capability-based search) but lacks explicit 'when not to use' or direct alternatives among siblings. The ranking details and paid tier note add useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.getAGet 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) |
| Name | Required | Description |
|---|---|---|
| mcp | No | |
| error | No | |
| product | No | |
| agentReadiness | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by detailing the response structure, including edge cases like unverified status, knownLimitations with evidence, and alternatives with disclosure. It also mentions possible errors (not_found). 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 then details the response object in a structured way. While somewhat lengthy, every sentence adds value, and the structure helps the agent parse the information efficiently.
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 only one parameter and includes a detailed inline output schema (response structure), the description is complete for an agent to understand what the tool returns, including nested objects, error codes, and optional fields. No additional context is needed.
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% for the single parameter 'slug', which has a clear description ('Product slug (URL-friendly identifier)'). The description does not add further meaning to the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details for a product by slug, including MCP integration data and agent readiness scores.' This is a specific verb+resource with explicit inclusions, distinguishing it from sibling tools like products.search or 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?
The description implies usage context: use this tool when you need full product details including MCP and agent readiness for a specific product identified by slug. However, it does not explicitly state when not to use or mention alternatives, though the detailed response helps the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.get_mcp_setupAGet 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) |
| Name | Required | Description |
|---|---|---|
| error | No | |
| message | No | |
| product | No | |
| servers | No | |
| hasMcpSupport | No | |
| agentReadiness | No | |
| totalToolCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world hints. The description adds value by detailing the response structure, error format, and caching pattern for drift detection, which goes beyond what annotations provide. 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 main purpose, but it is dense and lengthy due to including detailed response structure. It is well-organized but could be more concise by relying on an output schema.
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 single parameter, good schema coverage, annotations, and existence of an output schema, the description is complete. It covers response structure, error handling, and usage advice (caching, drift detection), leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'slug' parameter. The description does not add new semantic information about the parameter beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets MCP server setup instructions for a product, including servers, tools, connection details, and access type. It distinguishes itself from sibling tools like tools.get and products.get by focusing on setup instructions.
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 what to do with the results (use mcpJson for remote, repositoryUrl for local, cache hash for drift detection) but does not explicitly state when to use this tool over alternatives like products.get or tools.get. Usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
products.searchASearch 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 |
| Name | Required | Description |
|---|---|---|
| error | No | |
| query | No | |
| products | No | |
| matchType | No | |
| resolvedCapabilities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses critical behavioral details: paid tier is not a ranking input, every result includes position/rank for merging, conflict-of-interest disclosure (houseProduct), sponsored status, unverified flag semantics, and error codes. This fully informs the agent of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured: core behavior first, then ranking, response shape, and field details. Every sentence adds unique value, though some details (e.g., exact field semantics) could be inferred from the output schema. It is concise for the amount of information conveyed.
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 provided, the description covers all necessary aspects: query resolution logic, ranking, result structure, field meanings, and error handling. It is fully complete for an agent to select and invoke this 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?
The input schema has 100% coverage with descriptions for both parameters. The description adds crucial context: 'query' accepts capability slugs or natural language, with fallback to name match; 'category' is an optional slug. This exceeds 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 the tool searches for B2B SaaS products by name or capability. It explains the two-step resolution (canonical taxonomy first, then fallback) and distinguishes from siblings like 'products.find_by_capability' and '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 solid guidance on when to use this tool (general search by name or capability) and how results are ranked and annotated, enabling consistent merging. It does not explicitly state when not to use it, but the sibling context implies alternatives for specific needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rankings.getAGet 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. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| entries | No | |
| trigger | No | |
| category | No | |
| unranked | No | |
| computedAt | No | |
| methodologyUrl | No | |
| methodologyVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the `readOnlyHint` and `openWorldHint` annotations: rankings are monthly snapshots, stable between recomputes, citable, positions never sold, and machine-readable houseProduct disclosure. 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 dense but well-structured, front-loading the main purpose and then adding key details. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, output schema present, nested objects), the description fully explains the response structure including entry fields, unranked info, and error format. It is complete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the ranking computation but does not significantly enhance understanding of the `category` and `limit` parameters beyond the schema. No additional parameter semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'published editorial ranking' for a category, specifying ordering basis and key traits. It distinguishes itself from siblings like `categories.list` by focusing on rankings rather than listing categories.
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 context for when to use this tool (to retrieve published rankings) but does not explicitly exclude alternatives or mention when not to use it. The context is sufficient to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.changesADetect 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. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| drifted | No | |
| message | No | |
| product | No | |
| servers | No | |
| hasMcpSupport | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds detailed behavioral context: exact mismatch detection, timestamp-based drift, fingerprint caching, multi-server handling, and response structure, fully disclosing the tool's behavior 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 long but well-structured, front-loading the core purpose and then detailing usage, response, and errors. Every sentence adds value, though it could be slightly more concise. No redundant phrases.
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, output schema, annotations), the description covers all necessary aspects: detection modes, caching, multi-server considerations, response fields, error codes, and reference to related tool. It is self-contained and complete for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description provides additional meaning by explaining the relationship between knownHash and server, the caching use case, and the interpretation of 'drifted' versus 'driftedSince', enriching the parameter semantics 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 the tool detects schema drift for MCP tools, using specific verbs (detect, check) and resource (schema drift). It distinguishes from siblings by addressing a unique use case not covered by other tools like tools.get or tools.list_by_name.
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 guidance on when to use (re-verify before trusting), how to use (knownHash or since, with server qualification for multi-server products), and contrasts with web search. It lacks explicit mention of alternatives among sibling tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.find_for_taskAFind 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 |
| Name | Required | Description |
|---|---|---|
| task | No | |
| error | No | |
| buckets | No | |
| message | No | |
| results | No | |
| matchType | No | |
| suggestedQueries | No | |
| capabilityProducts | No | |
| resolvedCapabilities | No | |
| suggestedCapabilities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ranking logic (relevance score, boost for callable-now/remote/healthy), confirms paid tier is not a ranking input, explains result annotations (accessModel, healthScore, etc.), and states default filter for remote servers. No contradiction with annotations (readOnlyHint, 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 quite lengthy but well-structured with clear sections (audience, ranking, result format, empty case). It is front-loaded with the main purpose. Some detail could be compressed, but overall efficient for the complexity of the tool.
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 all aspects: usage, ranking, result structure, annotations, empty case, and differentiation from siblings. Given the tool's complexity and the presence of an output schema, the description is exceptionally 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% and schema descriptions are clear. The tool description adds context for the access parameter (optional access-class filter) and explains default values for limit and remoteOnly, providing extra meaning 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 the tool finds the best MCP tools for a given task, specifies the verb 'find', resource 'MCP tools', and distinguishes from siblings like products.search or products.find_by_capability by explicitly stating the audience and alternative use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: audience (agent builders), when to use this tool vs alternatives (for B2B SaaS recommendations, use products.search), default behavior (remoteOnly true, Open tools boosted), and ranking details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.getAGet 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') |
| Name | Required | Description |
|---|---|---|
| tool | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations by detailing the full response structure (including fields like normalizedName, healthScore, etc.) and error handling. Annotations already mark it as read-only and open-world, and the description complements this 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 concise and well-structured: a clear purpose sentence, followed by parameter guidance, then the response and error structure. Every sentence provides necessary information 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 high schema coverage and a fully described output schema, the description is complete. It covers the tool's purpose, required parameters, response format, and error cases, leaving no ambiguity for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the rationale for passing both parameters (because same-named tools can exist across products), providing additional meaning beyond the schema's basic 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 verb 'Get' and the resource 'detailed information about a specific MCP tool', scoped to one product. It distinguishes from siblings by emphasizing that same-named tools across products are distinct, which is a key differentiator.
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 context on when to use the tool (when detailed info about a tool is needed) and emphasizes the need to pass both productSlug and tool name. However, it does not explicitly mention when not to use it or compare to sibling tools like tools.search or tools.find_for_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.list_by_nameAList 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') |
| Name | Required | Description |
|---|---|---|
| error | No | |
| tools | No | |
| total | No | |
| normalizedName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context: paid tier is only an annotation, ranking basis is productName, and every result includes position, rank, and preflight annotations. 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 purpose but includes detailed response field listings, which adds length. While informative, it could be more concise by omitting exhaustive field enumeration.
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 (disambiguation across products), the presence of input schema, annotations, and output schema, the description fully covers semantics, usage, and behavior, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining 'normalized tool name' and providing examples ('search', 'create_issue'), improving agent understanding beyond the schema's 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 specifies 'List every (product, tool) pair that shares a normalized name,' clearly stating the verb and resource. It distinguishes from siblings by calling it a 'disambiguation lookup' and noting that same name across providers does not imply interchangeability.
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 the tool (disambiguation lookup) and provides context (same name not interchangeable). It implicitly guides against using it for comparing tools across providers, though explicit alternatives to sibling tools like 'tools.search' are not given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tools.searchASearch 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 |
| Name | Required | Description |
|---|---|---|
| error | No | |
| tools | No | |
| searchMode | No |
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 context: ranking details, result structure with position and rank, access model, health score, error codes, and fallback behavior. No contradictions found.
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 and single-paragraph, front-loaded with main purpose, but could be better organized with bullet points for readability. It is not overly verbose given the complexity, but structure could improve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complex search tool, annotations, and an output schema, the description covers ranking, result fields, access models, error handling, and fallback modes. It is complete enough for an 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 four parameters. The description adds no parameter details beyond what's in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for MCP tools by capability,' specifying the verb and resource. It distinguishes from sibling tools like tools.list_by_name and tools.find_for_task by explaining the result structure and ranking behavior.
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 when to use the tool (searching by capability), explains ranking based on semantic or lexical mode, and describes optional filters like access class and remoteOnly. It lacks explicit when-not or alternative suggestions, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
