Discovery registry for AI agents: 660+ APIs, MCP servers and CLIs, each health-checked every 6 hours with real requests — full initialize + tools/list handshakes for MCP, real calls for APIs — plus response-schema validation that catches responses which parse fine but are missing a required field.
Scored across 6 tools
Each tool targets a distinct mode of access: discover_capabilities maps plain-language goals, search_registry does keyword lookup, list_entries enumerates the whole catalogue, get_entry retrieves a single known slug, list_categories returns fixed taxonomy, and submit_entry writes. Descriptions explicitly cross-reference and clarify boundaries, leaving no meaningful overlap.
All six tools follow a consistent verb_noun pattern in snake_case (discover_capabilities, get_entry, list_categories, list_entries, search_registry, submit_entry). There are no deviations or mixed conventions.
Six tools are well-scoped for a registry discovery and submission server. Each tool earns its place, covering the core read paths (goal, keyword, enumerate, single record, taxonomy) and the write path without redundancy.
Read coverage is comprehensive, and submission creation is present. However, the description references a list_my_submissions tool that is not included, forcing agents to use an external HTTP endpoint to check pending submission status—a minor but noticeable gap in the MCP surface.
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. 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. Omit to search all three (default). | |
| 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 already establish read-only and idempotent behavior; the description adds concrete edge-case semantics: it is never empty on a valid need, coverage becomes 'none', and matches[] still surfaces reliable starting points. 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 compact and front-loaded, with the purpose stated before the returns and alternative. The detailed return-shape sentence is useful for anticipation but slightly redundant given an output schema exists.
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 4-parameter tool with rich annotations and an output schema, the description covers the key use case, edge behavior, and sibling routing. Nothing an agent needs to decide whether to call it 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%, so the schema already explains all four parameters. The description adds a useful example of a 'need' and links reliability to the scoring concept, but it does not materially add 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 leads with a specific verb and resource ('Map a plain-language goal ... to callable APIs, MCP servers or CLIs'), so an agent immediately knows what the tool accomplishes. It also distinguishes itself from the sibling search_registry by framing the input as a goal rather than a known keyword or slug.
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 states when to use the tool (plain-language goal discovery) and when not to ('For a known keyword or slug, use search_registry'). It also clarifies behavior on valid but unmatched needs, removing ambiguity about fallback use.
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. Returns {count, results[]} in summary form, and an empty results[] when nothing matches — that 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: it states that matching is literal text only and does not interpret a goal, it discloses the return format ({count, results[]}) and the empty-results behavior, and parameter descriptions reveal ordering by name, not relevance, and character stripping. This exceeds the annotation baseline but doesn't cover every possible edge (e.g., no mention of case-insensitivity in the main description, though it is in the query parameter).
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 main description is concise and front-loaded: it states the tool's purpose in the first sentence, then immediately provides usage guidance and sibling differentiation, followed by return format and edge-case behavior. Every sentence earns its place. The parameter descriptions are detailed but not bloated, and the structure groups related guidance logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 optional parameters, an output schema, and 5 siblings), the description is complete. It covers what the tool searches, how matching works, how to narrow by category, how results are ordered, what the return shape is, and what to do instead for other needs. The output schema exists, so return values are already structured; nothing an agent needs to invoke this 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%, so the schema documents all parameters thoroughly. The description goes beyond the schema by explaining the matching semantics (literal text only, single terms work best, whole string matched as one substring) and the ordering behavior (by name, not relevance) in the parameter descriptions. It adds practical context like when to raise the limit or use discover_capabilities for ranking. A 4 is appropriate because the description enriches the schema rather than merely repeating it; it's not a 5 because the schema-description coverage is already so high that the description's extra value, though helpful, is incremental.
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: 'Keyword lookup in the Agent Nexus registry when you already know what to look for.' It lists specific searchable fields (product name, vendor, slug, endpoint fragment) and specifies optional narrowing by category. It explicitly distinguishes itself from siblings (discover_capabilities, list_entries, get_entry), making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: use discover_capabilities for plain-language needs, list_entries to walk the catalogue in order, and get_entry for a full record of a known slug. It also warns that empty results are a valid answer, not an error, which is a crucial usage guideline. The parameter descriptions add further context, e.g., when to raise the limit or use discover_capabilities for ranking.
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 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 for agent keys, 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 every 6 hours 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 only say readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description goes far beyond that: it discloses that submissions are human-reviewed, not immediately visible, re-submissions create duplicate pending rows, nothing is overwritten or deleted, rate limits (20/hour members, 1/24h agent keys), and that the endpoint is health-probed every 6 hours. This is rich behavioral context that annotations cannot convey.
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-organized: purpose, auth, write semantics, required fields, rate limits, return value, and sibling routing all appear in a logical order. It is long, but every sentence carries operational information an agent needs. A slight trim of the health-probe detail could tighten it, but nothing is redundant.
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 16-parameter write tool with an output schema, the description covers everything an agent needs to call it correctly: auth method, required fields, rate limits, review workflow, return shape, polling/email follow-up, and sibling tools. The output schema exists, so the description needn't enumerate return fields, and it doesn't. This is 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 description coverage is 100%, so the schema already documents every parameter. The description adds value by prioritizing the five required fields, explaining that capabilities[] drives discovery, and noting that docs_url and invocation_example are what reviewers check first. It doesn't restate every schema detail, which is appropriate, but it does add decision-relevant 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 opens with a specific verb and resource ('Register a new interface... in the Agent Nexus catalogue') and immediately distinguishes the three accepted interface types (HTTP API, MCP server, CLI). It also clarifies the write semantics ('creates a pending row, it does NOT publish anything'), which separates it from read-only siblings like search_registry and get_entry. The purpose is unmistakable.
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: authenticate as a member or with a free agent key, check the registry first with search_registry, and use list_my_submissions to review prior submissions. It also states what this tool is not for (it does not publish, update, or delete). This is exemplary routing guidance.
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_categorieslist_entriessearch_registrysubmit_entry
Add one secure layer between your agents and this server.