Agent-native registry to discover APIs, MCP servers and CLIs, with live health checks.
Scored across 6 tools
Each tool targets a distinct retrieval mode: goal-based discovery, keyword search, single-slug lookup, full enumeration, taxonomy listing, and write submission. The descriptions explicitly cross-reference each other to steer away from misselection (e.g. 'if you do not have a slug, do not guess — use search_registry'). The discover vs. search boundary (plain-language need vs. literal keyword) is clearly drawn.
All six tools follow a clean snake_case verb_noun pattern: discover_capabilities, get_entry, list_categories, list_entries, search_registry, submit_entry. No camelCase mixing, no vague standalone verbs. The convention is predictable and readable throughout.
Six tools is well-scoped for a registry discovery server, covering the distinct read patterns plus one write. Each tool earns its place without redundancy, and the set stays comfortably in the ideal 3-15 range.
The read path is thorough (discover, search, get, list, list_categories), but the submission lifecycle is a dead end: no update, delete, or status-check tool exists, and submit_entry explicitly references 'list_my_submissions' which is not in the tool set. Agents can submit but cannot manage or track submissions via tools.
Call this first whenever a task needs an external service (email, payments, search, storage, LLMs, data...) or when a service you use is failing. Maps a plain-language goal (e.g. 'send a transactional email') to callable APIs, MCP servers or CLIs. Returns matches[] with slug, endpoint, auth, formats, rate limit, pricing and a 0-100 reliability score; if nothing fits, coverage='none' and matches[] lists reliable starting points. Rate limits: 100 calls/day anonymous, 1,000/day with a free key, 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 already declare readOnly/idempotent/non-destructive, so the bar is met; the description goes further by disclosing concrete rate limits (100/day anonymous, 1,000/day free key, 50,000/day Agent Pro) and the degraded-mode behavior (coverage='none' still returns reliable starting points). These are operational traits an agent cannot get from the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger condition before the mechanics, then return shape, then rate limits, then the alternative-tool pointer. Every sentence carries information an agent needs; no filler or restatement 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?
Despite an output schema being present, the description summarizes the payload (matches[] with slug, endpoint, auth, formats, rate limit, pricing, reliability) and the empty-result case, and covers the usage trigger and rate ceilings. For a 4-param discovery tool, 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%, with constraints and defaults documented for need, limit, category and min_reliability, so the schema carries the parameter burden. The description only loosely implies the 'need' input ('a plain-language goal') and adds no format or syntax guidance beyond it. Baseline 3 applies when the schema does the heavy lifting.
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+resource ('Maps a plain-language goal to callable APIs, MCP servers or CLIs') and makes the scope unmistakable. It explicitly distinguishes itself from the closest sibling: 'For a known keyword or slug, use search_registry.' An agent can route between discover_capabilities and search_registry without opening either 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 trigger ('Call this first whenever a task needs an external service... or when a service you use is failing') plus a named alternative for the keyword/slug case. Both the when-to-use and the when-to-use-something-else conditions are spelled out, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before calling a known service, check it is live right now and get its exact contract. Fetches 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 health probe (hourly for priority entries, otherwise on a rolling daily cycle) — 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 readOnly/idempotent/non-destructive, and the description goes well past them with error semantics ('An unknown or unapproved slug is an error, not an empty result') and health-probe freshness cadence (hourly for priority entries, otherwise rolling daily). It also flags the value proposition over siblings: 'the detail level the listing tools omit.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then scope, then return shape, then fallback routing — a logical order with no filler. It runs long at five sentences and repeats the read-only/idempotent point the annotations already carry, so it is slightly denser than necessary.
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?
Despite an output schema, it still previews the {entry} payload fields, which tells the agent this call is worth making versus a listing tool. Precondition, error behavior, and fallback paths are all present; 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 coverage is 100% and the schema already spells out case-sensitivity, 1-80 chars, no URL/display name, and approved-only resolution. The description reinforces the 'exact slug, don't guess' constraint but adds no format or syntax detail beyond the schema field.
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 ('Fetches the full record of ONE approved registry entry') and immediately scopes it ('takes no filters and no paging'). The distinction from search_registry, discover_capabilities and list_entries is explicit, so an agent can route without inspecting any 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 the precondition ('whose exact slug you already have, e.g. from a previous ... result'), the alternatives for each missing-slug case ('use search_registry for a keyword or discover_capabilities for a plain-language need'), and an explicit prohibition ('do not guess one'). The catalogue-walk case is routed to list_entries as well.
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, idempotentHint and destructiveHint=false, so repeating 'read-only, idempotent' adds little. The description does contribute real context beyond them: it is parameterless, safe to call once (cacheable), counts reflect only approved entries and are live, and it never returns entries themselves — a scope boundary the annotations do not express.
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 return content, then the guidance, then the exclusions. Three dense sentences with no filler; every clause either describes content, routes to an alternative, or sets a scope boundary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only enumeration tool, the description covers what it returns, why to call it, and when to use something else. An output schema exists, so return formatting need not be explained; nothing an agent needs in order 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?
Zero input parameters, so the baseline is 4. The description still adds meaning by tying the returned category values to the consuming tools' 'category' argument, clarifying the output-to-input contract even though no schema parameter exists to document.
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 ('Return the fixed taxonomy of Agent Nexus') and enumerates the exact contents ('api', 'mcp', 'cli' with label, one-line definition, live approved count). An agent can distinguish it from list_entries, search_registry and discover_capabilities without opening any 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 explicit when-to-use ('call it once to learn the exact values accepted by the category argument', 'size the catalogue before paging') and explicit when-not, routing to three named siblings: list_entries to enumerate a layer, search_registry for a keyword, discover_capabilities for a plain-language need.
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 declare read-only/idempotent/non-destructive, but the description adds behavior they cannot express: the total/pages values shift with the category filter, the filter and per_page must stay constant across pages or paging desynchronizes, entries are summaries rather than full records, and a bulk-mirror endpoint exists. That is substantive operational context beyond the annotation set.
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 purpose and the use/don't-use split, then layers paging mechanics and an escape hatch. Dense but nearly every clause carries information; the NDJSON mirror sentence is the one optional add-on, and the 'Returns {...}' shape listing is partly redundant given the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated, filterable list tool with an output schema already present, the description covers paging loop termination, filter/per_page stability, summary-vs-full-record expectations, sibling routing, and a bulk alternative. 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%, so the baseline is 3, but the description adds cross-parameter invariants the per-field schema text only states in isolation: keep the category filter identical across pages, keep per_page constant, and stop at the 'pages' value from the first response. It is mostly reinforcement of the schema rather than new per-parameter meaning, hence not a 5.
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 ('Enumerate the whole approved catalogue') plus the ordering guarantee ('deterministic slug order, page by page'). It also explicitly contrasts itself with the specific-lookup path, so an agent can separate it from search_registry or discover_capabilities without opening a 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 the when ('you want everything — mirroring, auditing, building your own index'), the when-not ('not when you are looking for something specific'), and routes to three named alternatives by intent: search_registry for keyword, discover_capabilities for plain-language needs, list_categories for valid category values. Near-exhaustive routing guidance.
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?
Beyond the annotations (read-only/safe), the description details critical behavioral traits like the literal matching constraint ('it does not interpret a goal'), the exact return structure ({count, results[]}), and specific ordering behavior ('ordered alphabetically by name, not by relevance').
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 information is highly dense and front-loaded, starting with the immediate purpose and moving efficiently through usage constraints, sibling routing, and detailed output specifications without unnecessary 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 definition is comprehensive, covering inputs, search constraints (literal matching), output format, error handling ('An empty results[]... is a valid answer'), and performance caveats (limit/ordering). Nothing necessary for correct invocation 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?
Although schema coverage is 100%, the description adds valuable semantic advice. It warns users that 'Results are ordered alphabetically by name, not by relevance,' directly influencing how the `limit` parameter should be used, providing contextual behavioral knowledge.
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 performs a 'Keyword lookup in the Agent Nexus registry.' Crucially, it differentiates itself from siblings like `discover_capabilities` and `get_entry` by defining the specific use case: 'when you already know what to look for.'
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 is explicitly defined by providing routing advice. It tells the agent to use `discover_capabilities` for 'plain-language need' and `list_entries` to 'walk the whole catalogue in order,' leaving no doubt about when this search function should be selected.
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 already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description builds meaningfully on top: creates a pending row that is NOT published, human review before discoverability, no overwrite/delete, re-submission creates a duplicate pending row, and specific rate limits (20/hr members, 1/24h per agent key and source address). Missing only failure-mode details, but the mutation semantics are unusually well disclosed.
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?
Long but front-loaded and dense with actionable facts; each sentence carries information about auth, review, rate limits, or return handling rather than filler. Slightly over-packed into a single paragraph, which costs a little scannability.
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 the gaps that matter: both auth paths, review/approval delay, rate limits, health-probe consequence, the return shape {slug, status}, and how to poll for the decision. An agent can call this end-to-end without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real ranking/review meaning beyond the schema: capabilities[] is 'what other agents are matched against', and docs_url plus invocation_example are 'what a reviewer checks first'. It also flags the five required fields, which the schema already encodes but reinforces the approval stakes.
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?
Opens with a specific verb + resource ('Register a new interface (HTTP API, MCP server or CLI) in the Agent Nexus catalogue') and immediately disambiguates from siblings by naming list_my_submissions and search_registry. An agent knows exactly what this does versus the read-only discovery tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it and when not to: 'Use list_my_submissions to review what you already submitted; use search_registry first to check the interface is not already listed.' It also names the alternative authentication path (free agent key) with its endpoint.
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"
+}Discovery registry for AI agents: 700+ APIs, MCP servers and CLIs, health-checked with real requests (hourly for priority entries, otherwise on a rolling daily cycle) — 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.
AI agent registry — search, discover, register, and connect agents via MCP.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Add one secure layer between your agents and this server.
