Agent-native registry to discover APIs, MCP servers and CLIs, with live health checks.
Scored across 6 tools
Each tool has a clearly distinct purpose: goal-based discovery (discover_capabilities), single-slug lookup (get_entry), taxonomy (list_categories), full enumeration (list_entries), keyword search (search_registry), and write submission (submit_entry). Descriptions explicitly disambiguate against each other, steering callers to the right tool for each intent.
All six names follow a consistent verb_noun snake_case pattern (discover_capabilities, get_entry, list_categories, list_entries, search_registry, submit_entry). No mixing of conventions or vague verbs.
Six tools is well-scoped for a registry discovery server, covering distinct read patterns plus one write. Each tool earns its place with no redundant surface.
The read surface is complete: discovery, keyword search, enumeration, single-record fetch, and taxonomy, plus a submit write path. Minor gaps exist for submission management — submit_entry references list_my_submissions and a poll-based submission status endpoint, but neither is exposed as a tool.
Map a plain-language goal (e.g. 'send a transactional email') to callable APIs, MCP servers or CLIs. Returns {need, coverage, count, uncovered, note, matches[]}; each match has slug, endpoint, auth, formats, rate limit, pricing and a 0-100 reliability score. Never empty on a valid need: if nothing fits, coverage='none' and matches[] lists reliable starting points. Errors: an invalid or too-short need fails input validation; a backend failure returns isError=true with the message. Rate limits: 100 calls/day anonymous, 1,000/day with a free key (POST /api/public/keys, no account), 50,000/day on Agent Pro. For a known keyword or slug, use search_registry.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the agent is trying to accomplish, in plain language. 3-300 characters, required. | |
| limit | No | Maximum number of matching interfaces to return, 1-20. Default 5. | |
| category | No | Restrict to one interface layer ('api', 'mcp' or 'cli' — see list_categories). Default: omitted, searches all three. | |
| min_reliability | No | Drop interfaces scoring below this 0-100 reliability value. Default 0 (no filter). |
| Name | Required | Description |
|---|---|---|
| need | Yes | |
| note | Yes | |
| count | Yes | |
| matches | Yes | |
| coverage | Yes | |
| uncovered | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent), and the description goes well beyond them: full return envelope, the never-empty guarantee with coverage='none' semantics, explicit error behavior for validation vs backend failures, and three concrete rate-limit tiers including how to raise the limit.
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 purpose, then output, errors and limits in scannable order. Slightly bloated because the inline return-shape listing duplicates the existing output schema, but every other sentence carries distinct operational 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?
For a discovery tool the agent has everything: what it returns, how to read an empty result, error modes, quota constraints, and the sibling to use instead. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents need, limit, category and min_reliability fully. The description adds only the plain-language example for 'need' and a pointer to list_categories; no extra syntax or interaction between parameters is explained.
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 precise verb+resource ('Map a plain-language goal ... to callable APIs, MCP servers or CLIs') with a concrete example of the input shape. It is immediately distinguishable from search_registry, which it names as the keyword/slug path.
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 routes the agent: use this tool for a plain-language goal, and use search_registry when a known keyword or slug is already available. The category parameter points at list_categories as the alternative for enumerating layers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full record of ONE approved registry entry whose exact slug you already have, e.g. from a previous discover_capabilities, search_registry or list_entries result. Read-only and idempotent: the same slug always returns the same entry until its health probe changes. Returns {entry} with endpoint, auth mode and parameters, input/output formats, rate limit, pricing, capabilities, docs URL, invocation example and the latest 6-hourly health probe — the detail level the listing tools omit. This is the single-record lookup: it takes no filters and no paging. If you do not have a slug, do not guess one — use search_registry for a keyword or discover_capabilities for a plain-language need; to walk the whole catalogue use list_entries. An unknown or unapproved slug is an error, not an empty result.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact lowercase slug of one entry, 1-80 chars, as returned in the 'slug' field of any other tool, e.g. 'stripe-api' or 'github-mcp'. Case-sensitive, no URL and no display name; only entries with status 'approved' resolve. |
| Name | Required | Description |
|---|---|---|
| entry | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, but the description adds meaningful behavior beyond those: the idempotency caveat that the same slug returns the same entry until its health probe changes, the explicit error semantics (unknown/unapproved slug is an error, not empty), and the contents of the returned {entry} including the 6-hourly health probe. These details inform the agent's expectations without contradicting the structured hints.
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 longer than average but well-structured: purpose is front-loaded, followed by behavioral traits, return payload, and usage routing. Most sentences earn their place—particularly the routing instructions and error semantics—but the read-only/idempotent restatement slightly duplicates annotations. Minor redundancy prevents a 5.
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 a single fully-documented parameter, a rich output schema, and strong annotations, the description adds the remaining context needed for correct invocation: error behavior, idempotency edge case (health probe changes), and explicit routing to alternatives. Nothing an agent needs to decide or call correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the slug parameter is fully documented in the schema (lowercase, 1-80 chars, case-sensitive, example values, approved-only resolution). The description reinforces that the slug must be exact and already known, but it does not add semantic meaning beyond what the schema already provides. Baseline 3 is appropriate under 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?
The description opens with a specific verb and resource: 'Fetch the full record of ONE approved registry entry whose exact slug you already have.' It explicitly contrasts with sibling tools by noting the detail level the listing tools omit, and points to search_registry, discover_capabilities, and list_entries for other lookup modes. An agent can immediately tell this is the single-record keyed lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable: use this tool when you already possess an exact slug (e.g., from a prior tool result); if you lack a slug, do not guess and instead use search_registry, discover_capabilities, or list_entries. It also states that the tool takes no filters and no paging, and that unknown/unapproved slugs produce an error. This is model how-to-use guidance with named alternatives and conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the fixed taxonomy of Agent Nexus: the three interface layers it indexes ('api', 'mcp', 'cli'), each with a label, a one-line definition and its live count of approved entries. Read-only, idempotent and parameterless — call it once to learn the exact values accepted by the 'category' argument of search_registry, list_entries and discover_capabilities, and to size the catalogue before paging. It never returns entries themselves: use list_entries to enumerate a layer, search_registry for a keyword, discover_capabilities for a plain-language need.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces these ('Read-only, idempotent and parameterless'). It adds value beyond annotations by describing the exact return shape (label, definition, live count) and the boundary that it never returns entries themselves. It does not mention authentication or rate limits, but for a parameterless read-only call this is not a gap given 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?
Three sentences, each with a distinct job: first states what is returned, second gives usage and alternatives, third clarifies what it does not return and routes to siblings. Every sentence earns its place and there is no filler or redundancy. The front-loaded first sentence gives the core purpose immediately.
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 parameterless, read-only taxonomy tool, the description is complete. It covers what it returns, when to use it, how it relates to all sibling tools, and the fact that it is idempotent and read-only. An output schema exists, so return-value details need not be in the description. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty object). The description adds the useful note that it is parameterless and explains that its output defines valid values for the 'category' argument of sibling tools. Since 0 params starts at baseline 4, and the description provides meaningful context beyond the schema, this score 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 states a precise verb and resource: 'Return the fixed taxonomy of Agent Nexus: the three interface layers it indexes ('api', 'mcp', 'cli')'. It also distinguishes itself from siblings by explicitly saying 'It never returns entries themselves' and pointing to list_entries, search_registry, and discover_capabilities for those needs. This is a model of sibling differentiation.
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 gives explicit when-to-use guidance: 'call it once to learn the exact values accepted by the 'category' argument of search_registry, list_entries and discover_capabilities, and to size the catalogue before paging.' It also provides clear when-not-to-use guidance by naming the alternative tools for each different need. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate the whole approved catalogue in deterministic slug order, page by page — use this when you want everything (mirroring, auditing, building your own index), not when you are looking for something specific. Read-only and idempotent. Returns {total, page, per_page, pages, results[]}: read 'pages' from the first response and increment 'page' until you reach it; 'total' and 'pages' reflect the 'category' filter when one is set, so keep the filter identical across pages or the paging shifts. Entries come back in summary form; call get_entry with a slug for the full record. For a keyword use search_registry, for a plain-language need use discover_capabilities, and for the accepted category values call list_categories. Bulk mirror alternative: GET https://agentnexus.app/api/public/entries.ndjson streams the full catalogue in one request.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page index. Start at 1 and increment until it equals the 'pages' value returned in the response; a page beyond the last one returns an empty results[] rather than an error. | |
| category | No | Optional filter, exactly one of 'api', 'mcp' or 'cli' (see list_categories). Omit to page through all three layers. When set, 'total' and 'pages' count only that layer. | |
| per_page | No | How many entries to return in this page, 1-50, default 25. Changing it between calls changes 'pages' and re-slices the catalogue, so keep it constant while paging. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| pages | Yes | |
| total | Yes | |
| results | Yes | |
| per_page | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true and idempotentHint=true, but the description adds rich behavioral context beyond that: pagination semantics (read 'pages' from first response and increment 'page'), the requirement to keep 'category' and 'per_page' constant across pages because 'total' and 'pages' reflect the filter and re-slicing, and the behavior of a page beyond the last returning an empty results[]. 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?
Though the description is substantial, every sentence earns its place. It front-loads the core purpose and then builds out pagination mechanics, filter caveats, sibling routing, and a bulk alternative in a logical order. No fluff, no repetition of schema details, and the structure makes it easy to scan.
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 (pagination, filters, five siblings, and a bulk mirror), the description covers everything an agent needs: how to page correctly, what the response shape is, how filters affect totals, when to use each alternative, and the NDJSON streaming option. The output schema exists, so the description correctly focuses on usage behavior rather than re-listing return fields.
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 each parameter already has a solid description, but the tool description adds crucial meaning beyond the schema: it explains that 'page' should start at 1 and increment until it equals 'pages', that 'category' changes the counts and must be kept identical across pages, and that changing 'per_page' re-slices the catalogue. This interplay is not present in the schema and is essential for correct use.
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 opens with a precise verb and resource: 'Enumerate the whole approved catalogue in deterministic slug order, page by page.' It explicitly contrasts with specific lookups ('not when you are looking for something specific') and names the sibling tools it is not, so an agent can distinguish it immediately without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit 'use this when' (mirroring, auditing, building your own index) and an explicit 'not when' (looking for something specific), then routes to specific siblings: search_registry for keywords, discover_capabilities for plain-language needs, list_categories for category values, and get_entry for full records. It also offers a bulk mirror alternative via NDJSON stream, leaving no ambiguity about when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword lookup in the Agent Nexus registry when you already know what to look for: a product name, vendor, slug or endpoint fragment, optionally narrowed to one category. Matches literal text only — it does not interpret a goal. To go from a plain-language need to a callable interface, use discover_capabilities instead; to walk the whole catalogue in order use list_entries, and for the full record of one known slug use get_entry. Read-only and side-effect free. Returns {count, results[]} where each result is a summary entry record (slug, name, category, summary, endpoint, trust fields). Results are ordered alphabetically by name, not by relevance; there is no pagination beyond the limit parameter — raise limit (max 50) or narrow the query to see more. An empty results[] when nothing matches is a valid answer, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Upper bound on entries returned, 1-50, default 10. Results are ordered by name, not by relevance, so a small limit on a broad keyword can hide better matches — raise it or use discover_capabilities when you are ranking candidates. | |
| query | No | Literal substring, max 120 chars, matched case-insensitively against name, summary, endpoint and slug — a product name ('resend'), a vendor, a slug fragment or a host ('api.stripe.com'). Single terms work best: the whole string is matched as one substring, so 'send email' finds nothing unless those words appear together. The characters % , ( ) are stripped. An empty query (the default) returns the first entries in name order, which is a browse, not a search. | |
| category | No | Optional filter, exactly one of 'api', 'mcp' or 'cli' (see list_categories). Combined with query as AND. Omit to search all three layers. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent, but the description adds substantial non-structured behavior: results are ordered alphabetically not by relevance, there is no pagination beyond limit, empty results[] is a valid success case, and only literal substrings (with certain chars stripped) match. These are exactly the traits an agent cannot infer from 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?
Purpose is front-loaded, followed by routing, then behavior. Most sentences carry unique value, but 'Read-only and side-effect free' duplicates the annotations and the return-shape sentence is partly redundant given the output schema, adding slight bulk to an already dense block.
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 read-only search tool with three documented parameters, full schema coverage, annotations, and an output schema, the description covers matching semantics, ordering, pagination limits, and empty-result handling. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's own parameter descriptions are already unusually detailed (case-insensitive matching, stripped characters, AND semantics, limit range). The description restates the same limit/ranking caveats without adding syntax or format meaning the schema lacks, so baseline 3 is correct.
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 and resource ('keyword lookup in the Agent Nexus registry') plus the exact matching mode (literal text, not goal interpretation). It explicitly distinguishes itself from discover_capabilities, list_entries, and get_entry, so an agent can route correctly without opening any sibling schema.
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?
Gives an explicit when-to-use condition ('when you already know what to look for: a product name, vendor, slug or endpoint fragment'), an explicit when-not ('it does not interpret a goal'), and names the three alternative tools with the conditions that select them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new interface (HTTP API, MCP server or CLI) in the Agent Nexus catalogue. Callers authenticate either as a signed-in member or with a free agent key (POST https://agentnexus.app/api/public/keys), which allows one submission per key and per source address per 24 hours. This is a write: it creates a pending row, it does NOT publish anything — every submission is reviewed by a human before it becomes discoverable, so nothing you send here is visible to other agents until it is approved. Nothing is overwritten or deleted, and re-submitting the same name creates a second pending row rather than updating the first. Five fields are required (name, category, summary, endpoint, auth_mode); everything else is optional but directly decides whether the entry is approved and how well it ranks: capabilities[] is what other agents are matched against, so list concrete verbs, and docs_url plus invocation_example are what a reviewer checks first. Rate limited to 20 submissions per hour for members and 1 per 24 hours per agent key and per source address, and the endpoint must answer a live health probe to keep a reliability score. Returns {slug, status}; poll GET https://agentnexus.app/api/public/submission?slug= for the decision, or pass contact_email to be emailed instead. Use list_my_submissions to review what you already submitted; use search_registry first to check the interface is not already listed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Public product name as its vendor spells it, 1-80 chars, e.g. 'Resend' or 'GitHub MCP Server'. Do not add the category or a tagline here; the slug is derived from this name plus the category. | |
| tags | No | Up to 8 short domain labels for browsing, e.g. ['email','messaging']. Domains, not actions — actions belong in capabilities[]. | |
| pricing | No | Cost in one short phrase, e.g. 'Free', 'Free tier then $20/month', 'Usage-based, $0.001/call'. Agents filter on this, so be concrete. | |
| summary | Yes | One line an agent can rank on: what the interface does, 10-300 chars. State the capability, not the marketing (e.g. 'Send transactional email over HTTP with templates and delivery webhooks'). | |
| category | Yes | Which layer this interface belongs to: 'api' for an HTTP contract called directly, 'mcp' for a Model Context Protocol tool server, 'cli' for a command-line surface. Decides how endpoint is interpreted (URL vs command). | |
| docs_url | No | Absolute https URL of the developer documentation (not the marketing home page). Omit if none exists; submissions without it are approved more slowly. | |
| endpoint | Yes | How the interface is actually reached, max 500 chars. For category 'api' the base URL (https://api.example.com/v1); for 'mcp' the server URL (https://example.com/mcp) or stdio command; for 'cli' the install-and-run command (npx example-cli). Must be reachable: it is probed daily and a dead endpoint loses its reliability score. | |
| auth_mode | Yes | How a caller authenticates, in a few words: 'none', 'Bearer API key', 'API key in query', 'OAuth 2.1', 'Basic auth'. Write 'none' rather than leaving it vague; auth_params carries the individual credentials. | |
| rate_limit | No | Published quota in the vendor's own words, e.g. '100 requests/minute', '10k calls/month on the free tier'. Leave empty rather than guessing. | |
| auth_params | No | Up to 10 individual credentials the caller must supply, each {name, location, required}. Leave empty when auth_mode is 'none'. Never include credential values here, only their names. | |
| description | No | Optional long form, max 4000 chars: what the interface does well, notable limits, quirks an agent should know before calling. Plain text; no HTML. | |
| capabilities | No | Up to 12 lowercase hyphenated verbs an agent's need is matched against, e.g. ['send-email','list-templates','verify-address']. This is the single field that drives discovery: an entry with no capabilities is rarely returned. One action per item, 2-40 chars, no sentences. | |
| input_format | No | MIME type or shape the interface accepts, e.g. 'application/json', 'multipart/form-data', 'command-line flags'. Empty string when not applicable. | |
| contact_email | No | Optional. Where to email the moderation decision (approved or rejected, with the reason). Never published, never shared. | |
| output_format | No | MIME type or shape the interface returns, e.g. 'application/json', 'text/csv', 'stdout text'. Empty string when not applicable. | |
| invocation_example | No | One copy-pasteable call that works: a curl command, a JSON-RPC body or a CLI line, max 1000 chars. Never include a real credential — use a placeholder such as $API_KEY. This is what reviewers check first. |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-destructive write, but the description discloses far more: the row is created in a *pending* state, it does NOT publish anything, a human reviews it before it becomes discoverable, nothing is overwritten, and re-submitting the same name creates a duplicate pending row rather than an update. It also states the rate limits (20/hr members, 1/24h per agent key and source address) and the live health-probe requirement.
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-loads the core action and the review gate before covering auth, rate limits, field priorities and the return value. It is densely packed and the sentences run long, but every clause carries information an agent needs; the only cost is readability from over-density.
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 the full lifecycle for a 16-parameter submission: auth, rate limits, approval workflow, key field priorities, the returned {slug, status}, and how to poll or receive an email decision. Since an output schema exists, the description needn't detail full return values, and it still names the poll endpoint, which closes the loop.
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 100% schema description coverage, the baseline is 3, but the description adds real prioritization the schema does not: which five fields are required, that capabilities[] is what other agents are matched against (and should be concrete verbs), and that docs_url plus invocation_example are what a reviewer checks first. That is meaningful call-shaping guidance beyond the schema text.
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 and resource ('Register a new interface... in the Agent Nexus catalogue') and enumerates the three interface kinds (HTTP API, MCP server, CLI), which maps directly onto the category enum. It also distinguishes itself from the sibling search_registry by explicitly telling the caller to use that tool first to check for duplicates.
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?
Gives explicit routing: 'Use list_my_submissions to review what you already submitted; use search_registry first to check the interface is not already listed.' It also spells out the two auth paths and their differing quotas, so the caller knows whether they are eligible before invoking.
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.
submit_entry1 field changedInput schema / properties / endpoint / descriptionPrevious value: -"How the interface is actually reached, max 500 chars. For category 'api' the base URL (https://api.example.com/v1); for 'mcp' the server URL (https://example.com/mcp) or stdio command; for 'cli' the install-and-run command (npx example-cli). Must be reachable: it is probed every 6 hours and a dead endpoint loses its reliability score."New value: +"How the interface is actually reached, max 500 chars. For category 'api' the base URL (https://api.example.com/v1); for 'mcp' the server URL (https://example.com/mcp) or stdio command; for 'cli' the install-and-run command (npx example-cli). Must be reachable: it is probed daily and a dead endpoint loses its reliability score."discover_capabilities1 field changedInput schema / properties / category / descriptionPrevious value: -"Restrict to one interface layer. Omit to search all three (default)."New value: +"Restrict to one interface layer ('api', 'mcp' or 'cli' — see list_categories). Default: omitted, searches all three."submit_entry1 field changedInput schema / properties / contact_email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"get_entry1 field changedInput schema / properties / slug / descriptionPrevious value: -"Entry slug, e.g. 'stripe-api'."New value: +"Exact lowercase slug of one entry, 1-80 chars, as returned in the 'slug' field of any other tool, e.g. 'stripe-api' or 'github-mcp'. Case-sensitive, no URL and no display name; only entries with status 'approved' resolve."list_entries3 fields changedInput schema / properties / category / descriptionPrevious value: -"Restrict the listing to one interface category."New value: +"Optional filter, exactly one of 'api', 'mcp' or 'cli' (see list_categories). Omit to page through all three layers. When set, 'total' and 'pages' count only that layer."Input schema / properties / page / descriptionPrevious value: -"Page number, starting at 1."New value: +"1-based page index. Start at 1 and increment until it equals the 'pages' value returned in the response; a page beyond the last one returns an empty results[] rather than an error."Input schema / properties / per_page / descriptionPrevious value: -"Entries per page (max 50)."New value: +"How many entries to return in this page, 1-50, default 25. Changing it between calls changes 'pages' and re-slices the catalogue, so keep it constant while paging."search_registry3 fields changedInput schema / properties / category / descriptionPrevious value: -"Restrict results to one interface category."New value: +"Optional filter, exactly one of 'api', 'mcp' or 'cli' (see list_categories). Combined with query as AND. Omit to search all three layers."Input schema / properties / limit / descriptionPrevious value: -"Maximum number of entries to return (1-50)."New value: +"Upper bound on entries returned, 1-50, default 10. Results are ordered by name, not by relevance, so a small limit on a broad keyword can hide better matches — raise it or use discover_capabilities when you are ranking candidates."Input schema / properties / query / descriptionPrevious value: -"Keyword matched against name, summary, endpoint or slug."New value: +"Literal substring, max 120 chars, matched case-insensitively against name, summary, endpoint and slug — a product name ('resend'), a vendor, a slug fragment or a host ('api.stripe.com'). Single terms work best: the whole string is matched as one substring, so 'send email' finds nothing unless those words appear together. The characters % , ( ) are stripped. An empty query (the default) returns the first entries in name order, which is a browse, not a search."submit_entry18 fields changedInput schema / properties / auth_mode / descriptionPrevious value: -"e.g. 'Bearer API key', 'OAuth 2.1', 'none'."New value: +"How a caller authenticates, in a few words: 'none', 'Bearer API key', 'API key in query', 'OAuth 2.1', 'Basic auth'. Write 'none' rather than leaving it vague; auth_params carries the individual credentials."Input schema / properties / auth_params / descriptionAdded value: +"Up to 10 individual credentials the caller must supply, each {name, location, required}. Leave empty when auth_mode is 'none'. Never include credential values here, only their names."Input schema / properties / auth_params / items / properties / location / descriptionPrevious value: -"header | query | env | flag"New value: +"Where the credential goes: 'header', 'query', 'env' (CLI/MCP environment variable) or 'flag' (CLI argument)."Input schema / properties / auth_params / items / properties / name / descriptionAdded value: +"Exact credential name as sent, e.g. 'Authorization' or 'api_key'."Input schema / properties / auth_params / items / properties / required / descriptionAdded value: +"False only when the call also works without this credential. Defaults to true."Input schema / properties / capabilities / descriptionPrevious value: -"Machine-matchable verbs, e.g. ['send-email','list-templates']."New value: +"Up to 12 lowercase hyphenated verbs an agent's need is matched against, e.g. ['send-email','list-templates','verify-address']. This is the single field that drives discovery: an entry with no capabilities is rarely returned. One action per item, 2-40 chars, no sentences."Input schema / properties / category / descriptionAdded value: +"Which layer this interface belongs to: 'api' for an HTTP contract called directly, 'mcp' for a Model Context Protocol tool server, 'cli' for a command-line surface. Decides how endpoint is interpreted (URL vs command)."Input schema / properties / description / descriptionAdded value: +"Optional long form, max 4000 chars: what the interface does well, notable limits, quirks an agent should know before calling. Plain text; no HTML."Input schema / properties / docs_url / descriptionAdded value: +"Absolute https URL of the developer documentation (not the marketing home page). Omit if none exists; submissions without it are approved more slowly."Input schema / properties / endpoint / descriptionPrevious value: -"Base URL, MCP URL or command."New value: +"How the interface is actually reached, max 500 chars. For category 'api' the base URL (https://api.example.com/v1); for 'mcp' the server URL (https://example.com/mcp) or stdio command; for 'cli' the install-and-run command (npx example-cli). Must be reachable: it is probed every 6 hours and a dead endpoint loses its reliability score."Input schema / properties / input_format / descriptionAdded value: +"MIME type or shape the interface accepts, e.g. 'application/json', 'multipart/form-data', 'command-line flags'. Empty string when not applicable."Input schema / properties / invocation_example / descriptionAdded value: +"One copy-pasteable call that works: a curl command, a JSON-RPC body or a CLI line, max 1000 chars. Never include a real credential — use a placeholder such as $API_KEY. This is what reviewers check first."Input schema / properties / name / descriptionAdded value: +"Public product name as its vendor spells it, 1-80 chars, e.g. 'Resend' or 'GitHub MCP Server'. Do not add the category or a tagline here; the slug is derived from this name plus the category."Input schema / properties / output_format / descriptionAdded value: +"MIME type or shape the interface returns, e.g. 'application/json', 'text/csv', 'stdout text'. Empty string when not applicable."Input schema / properties / pricing / descriptionAdded value: +"Cost in one short phrase, e.g. 'Free', 'Free tier then $20/month', 'Usage-based, $0.001/call'. Agents filter on this, so be concrete."Input schema / properties / rate_limit / descriptionAdded value: +"Published quota in the vendor's own words, e.g. '100 requests/minute', '10k calls/month on the free tier'. Leave empty rather than guessing."Input schema / properties / summary / descriptionPrevious value: -"One line: what it does."New value: +"One line an agent can rank on: what the interface does, 10-300 chars. State the capability, not the marketing (e.g. 'Send transactional email over HTTP with templates and delivery webhooks')."Input schema / properties / tags / descriptionAdded value: +"Up to 8 short domain labels for browsing, e.g. ['email','messaging']. Domains, not actions — actions belong in capabilities[]."submit_entry1 field changedInput schema / properties / contact_emailAdded value: +{
+ "description": "Optional. Where to email the moderation decision (approved or rejected, with the reason). Never published, never shared.",
+ "format": "email",
+ "maxLength": 200,
+ "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+ "type": "string"
+}discover_capabilities5 fields changedInput schema / properties / category / descriptionPrevious value: -"Restrict to one interface layer."New value: +"Restrict to one interface layer. Omit to search all three (default)."Input schema / properties / limit / descriptionAdded value: +"Maximum number of matching interfaces to return, 1-20. Default 5."Input schema / properties / min_reliability / descriptionPrevious value: -"Drop interfaces whose reliability score is below this value."New value: +"Drop interfaces scoring below this 0-100 reliability value. Default 0 (no filter)."Input schema / properties / need / descriptionPrevious value: -"What the agent is trying to accomplish, in plain language."New value: +"What the agent is trying to accomplish, in plain language. 3-300 characters, required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "coverage": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {},
+ "type": "array"
+ },
+ "need": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "uncovered": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "need",
+ "coverage",
+ "count",
+ "uncovered",
+ "note",
+ "matches"
+ ],
+ "type": "object"
+}get_entry1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "entry": {}
+ },
+ "required": [
+ "entry"
+ ],
+ "type": "object"
+}list_categories1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "categories": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "categories"
+ ],
+ "type": "object"
+}list_entries1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "page": {
+ "type": "number"
+ },
+ "pages": {
+ "type": "number"
+ },
+ "per_page": {
+ "type": "number"
+ },
+ "results": {
+ "items": {},
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "page",
+ "per_page",
+ "pages",
+ "results"
+ ],
+ "type": "object"
+}search_registry2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of entries to return (1-50)."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "results": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "results"
+ ],
+ "type": "object"
+}submit_entrylist_entriesdiscover_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.
