Agent-native registry to discover APIs, MCP servers and CLIs, with live health checks.
Scored across 4 tools
Tools are mostly distinct: discover_capabilities is natural-language capability matching, search_registry is keyword/category search, get_entry is by-slug retrieval, and list_categories is a lightweight category overview. The only mild overlap is discover vs. search, but their descriptions make the difference clear.
All tool names follow a consistent snake_case imperative verb_noun pattern (discover_, get_, list_, search_), with no mixed conventions or vague verbs.
Four tools is a compact, well-scoped set for a registry lookup server. Each tool has a clear role, and none feel redundant or unnecessary.
The main registry workflows are covered: semantic discovery, keyword search, category listing, and entry details. A minor gap is the lack of an explicit browse-all or paginated list-all operation, but agents can work around this via search.
Match a natural-language need (e.g. 'send a transactional email', 'query Postgres') to the interfaces that can do it, ranked by capability match and verified reliability. Returns everything needed to call them: endpoint, auth mode, auth parameters, formats, rate limit and cost. Always returns a payload: when nothing matches, coverage is 'none', uncovered is true and the entries returned are reliable starting points, not matches.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the agent is trying to accomplish, in plain language. | |
| limit | No | ||
| category | No | Restrict to one interface layer. | |
| min_reliability | No | Drop interfaces whose reliability score is below this value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it details the return payload (endpoint, auth mode, etc.) and the no-match edge case (coverage='none', uncovered=true). This complements the readOnly and idempotent hints without contradicting them.
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, then explains the return payload and edge case in two additional sentences. It is concise and well-structured, with no fluff.
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 covers the tool's purpose, return contents, and the no-match behavior, which is sufficient given there is no output schema. However, it does not detail how ranking or reliability scoring works, nor does it describe the structure of returned entries beyond listing attributes.
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 75% (need, category, min_reliability have descriptions; limit does not). The description does not add parameter-specific meaning, so it relies on the schema. It provides a natural-language example for 'need' but not deeper semantics.
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 states a specific verb ('Match') and resource ('interfaces'), with concrete examples ('send a transactional email', 'query Postgres'). It clearly distinguishes from siblings by focusing on capability discovery rather than lookup or listing.
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 when the agent has a natural-language need, but it does not explicitly mention alternative tools like search_registry or get_entry, nor does it state when not to use this tool. It provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one approved Agent Nexus registry entry by slug, including its endpoint, auth method and last health probe.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Entry slug, e.g. 'stripe-api'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context about returned fields (endpoint, auth method, health probe), but does not disclose additional behavioral aspects such as error handling or access restrictions, which is acceptable but not exceptional.
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 front-loaded sentence that names the action, resource, selection key, and key return contents without redundancy. Every phrase earns its place, and there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only operation with one parameter and read/idempotent annotations, the description is sufficient: it explains what is fetched, how it is selected, and what key fields are included. It omits details about not-found or error behavior, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the slug parameter already has a clear description with an example. The description's phrase 'by slug' reinforces the parameter's role but does not add new semantic detail beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Fetch') and a specific resource ('one approved Agent Nexus registry entry by slug'), which distinguishes it from sibling tools like search_registry and list_categories. The phrase 'by slug' pinpoints the unique access pattern and makes the tool's role immediately clear.
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 clearly implies this tool is for retrieving a single known entry when the slug is available, rather than for discovery or broad searching. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the slug-based 'one entry' framing provides clear context and no misleading cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the three interface layers Agent Nexus indexes (APIs, MCPs, CLIs) with the number of approved entries in each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description doesn't need to repeat safety. It adds context by specifying the exact categories and what data is returned (counts), but it could mention the response format further. 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 sentence that is front-loaded with the core purpose. Every word adds information, and there is no redundancy or filler.
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 simplicity (no parameters, no output schema), the description is complete. It tells the agent exactly what will happen and what will be returned, and the sibling context is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is no schema to compensate for. The description appropriately describes the output, making it self-contained. No parameter semantics are needed, so the baseline 4 is justified for a no-parameter tool.
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 the exact resource (three interface layers) and the action (list) with concrete outcome (number of approved entries). It effectively distinguishes this from siblings like 'search_registry' by naming specific 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 implies a high-level overview use case, and although it doesn't explicitly state when not to use it or compare with siblings, the clarity of purpose makes the usage context clear. No exclusions are needed given the simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Agent Nexus registry of approved APIs, MCP servers and CLIs by keyword and optional category.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Keyword matched against name, summary, endpoint or slug. | |
| category | No | Restrict results to one interface category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the fact that the registry covers approved APIs, MCP servers, and CLIs)Skiping, which is useful but not deeply behavioral. It does not disclose pagination or result ordering 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?
A single, focused sentence that front-loads the primary action (Search), the resource, and the filtering method. There is no filler or repeated schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with three optional parameters and no output schema, the description is reasonably complete. It does not describe the return shape or pagination, but given the registry-search context and annotations, the missing detail is unlikely to cause incorrect invocation.
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 documents query and category with useful descriptions, and limit has default/min/max constraints. The description loosely maps to query and category but adds no parameter-level detail beyond the schema. With 67% schema coverage, the description does not fully compensate, but the missing param semantics are low-risk.
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 names a specific verb ('Search'), a precise resource ('Agent Nexus registry of approved APIs, MCP servers and CLIs'), and the mechanism ('by keyword and optional category'). This clearly separates it from sibling tools like list_categories, get_entry, and discover_capabilities.
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 conveys clear context for a keyword-driven registry lookup, but it does not explicitly say when this tool should be preferred over the sibling tools or when not to use it. The intended use is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
discover_capabilitiesget_entrylist_categoriessearch_registryAI agent registry — search, discover, register, and connect agents via MCP.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
Discover Agents and MCP capabilities with versions, permissions, and real-work trust context.
Add one secure layer between your agents and this server.
