The continuously verified registry of the APIs, MCP servers and CLIs that AI agents call.
Live: https://agentnexus.app · MCP endpoint (no login): https://agentnexus.app/api/public/mcp
Agent Nexus answers one question for an autonomous agent: "what can actually do this, right now, and how exactly do I call it?" Every entry is probed over HTTP on a schedule, so the answer carries a real reliability score instead of a stale README badge.
Listed on the official MCP registry as
app.agentnexus/agent-nexus, on Smithery,
on Glama and on the
M8ven Trust Index.
MCP (Streamable HTTP, stateless, anonymous — no consent screen, no key):
{
"mcpServers": {
"agent-nexus": {
"type": "http",
"url": "https://agentnexus.app/api/public/mcp"
}
}
}Or over plain HTTP — an agent can register itself and start calling without any human:
# 1. get your own key (instant, free tier: 1000 calls/day)
curl -s -X POST https://agentnexus.app/api/public/keys \
-H 'content-type: application/json' \
-d '{"agent":"my-agent","purpose":"capability discovery"}'
# 2. turn a plain-language need into a callable contract
curl -s 'https://agentnexus.app/api/public/discover?need=send%20transactional%20email' \
-H 'x-api-key: nx_...'Related MCP server: preflight-mcp
Tool | What it does |
| Plain-language need → ranked callable interfaces with auth, formats, limits, reliability |
| Keyword search across APIs, MCP servers and CLIs |
| Full contract for one interface |
| Browse the taxonomy |
Surface | Purpose |
| How an agent onboards itself, unattended |
| Full typed registry |
| Capability index |
| Streamable bulk export |
| Uptime history and recent incidents |
| OpenAPI + MCP server manifest |
| Discovery manifests |
| New and updated interfaces |
/explore · /connect ·
/status · /pricing ·
/keys
Tier | Who it is for | Daily calls |
Anonymous | Trying it out, no account | 100 |
Free key | Agent developers | 1 000 |
Agent Pro | Production agents that must not stall | 50 000 |
Publisher | API / MCP / CLI vendors: verified badge, monitoring, alerts | — |
TanStack Start (React 19, Vite), Tailwind CSS v4, Postgres with row-level security, server functions on an edge runtime, scheduled HTTP health probes. Built with Lovable.
Only publishable keys live in this repository; every secret is held server-side.
git clone https://github.com/Strategiumfinancepartner/AgentNexus.git
cd AgentNexus
npm i
npm run devOperated by BrainPath.io · support@agentnexus.app
Map 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: concrete rate limits (100/day anonymous, 1,000/day free key, 50,000/day Agent Pro), the returned fields (slug, endpoint, auth, formats, pricing, 0-100 reliability), and the no-match fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the purpose and immediately followed by the return shape and routing rule. The rate-limit sentence is useful for planning but is the least essential clause, keeping it just short of 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?
For a 4-parameter discovery tool with an output schema and full annotation coverage, nothing needed to invoke it correctly is missing: purpose, fallback semantics, alternative route, and quota constraints are all stated.
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 need, limit, category and min_reliability are already fully documented, including the enum and list_categories cross-reference. The description adds only indirect meaning (e.g. the reliability score tied to min_reliability) without new syntax or format detail, so the baseline 3 applies.
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: 'Map a plain-language goal ... to callable APIs, MCP servers or CLIs.' It also names the sibling it is not (search_registry), so an agent can distinguish it from search_registry/list_entries 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 an explicit routing rule: 'For a known keyword or slug, use search_registry.' It also covers the empty-result case by describing coverage='none' plus fallback matches, so the agent knows both when to call it and what it means when nothing fits.
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, openWorldHint and destructiveHint, so the safety profile is covered and the description's restatement of 'read-only and idempotent' is mild redundancy. It does add genuinely new behavior: idempotency holds only until the health probe changes, the response carries a 6-hourly probe plus invocation details, and an unknown/unapproved slug is an error rather than an empty result.
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 precondition before the alternatives, and every sentence carries routing or error information. The middle sentence enumerating returned fields (endpoint, auth mode, pricing, health probe, etc.) is the longest and is partly 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 single-parameter lookup with full annotation coverage and an output schema, this covers everything an agent needs: what it returns, why it differs from listing tools, when not to use it, and the failure mode for a bad slug. Nothing material 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% and the slug schema is already rich (case-sensitivity, length, approved-only), so baseline is 3. The description adds usage-level meaning the schema does not: the slug should come from a prior tool result rather than being guessed, and only approved entries resolve. It stops short of adding format or validation detail 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?
States a specific verb and resource ('Fetch the full record of ONE approved registry entry'), scopes it to an exact slug, and explicitly positions it as the single-record lookup that takes no filters or paging. An agent can distinguish it from search_registry, discover_capabilities and list_entries 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 an explicit precondition ('whose exact slug you already have'), names where the slug comes from, and routes the agent elsewhere when the precondition fails: search_registry for keywords, discover_capabilities for plain-language needs, list_entries for the whole catalogue. It also warns not to guess a slug.
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?
Annotations cover the safety profile (read-only, idempotent, non-destructive), yet the description adds traits annotations cannot express: literal substring matching with no goal interpretation, alphabetical rather than relevance ordering, no pagination beyond limit, and that an empty result set is valid rather than an error. These are exactly the runtime surprises an agent needs warned about.
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 routing decision, then matching semantics, ordering caveats and the empty-result rule — all high-value. The sentence describing the {count, results[]} shape duplicates the output schema, which is the one piece that doesn't earn its place.
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 three-param read tool with a full output schema and complete annotations, the description closes the remaining gaps: matching mode, sort order, pagination limits and the meaning of an empty result. An agent can call this correctly without further probing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schemas already spell out substring matching, the 120-char cap, stripped characters, the empty-query browse behavior and the 1-50 limit. The description's parameter content ('optionally narrowed to one category', 'raise limit (max 50)') largely restates that, so baseline 3 applies.
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 (keyword lookup) plus resource (Agent Nexus registry) and immediately bounds the scope to literal text, not intent. It explicitly distinguishes itself from discover_capabilities, list_entries and get_entry by naming each sibling's job.
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') and three named alternatives with the condition that selects each: discover_capabilities for plain-language needs, list_entries for catalogue walks, get_entry for a known slug. 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.
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.
v1.1.0discover_capabilitiesget_entrylist_categorieslist_entriessearch_registrysubmit_entryScored across 6 tools
Each tool has a clearly distinct purpose: plain-language discovery, keyword search, single-slug lookup, full catalogue listing, category taxonomy, and submission. The descriptions explicitly cross-reference boundaries (e.g., discover_capabilities vs. search_registry) so an agent can reliably tell them apart.
All tool names follow a consistent snake_case verb_noun pattern: discover_capabilities, search_registry, get_entry, list_categories, list_entries, submit_entry. The convention is predictable and readable throughout.
Six tools is well within the ideal 3-15 range and each earns its place: five read operations cover discovery, search, lookup, enumeration, and taxonomy, while one write operation handles submission. There are no redundant or filler tools.
Core discovery is thorough, covering goal-based, keyword, single-record, full-catalogue, and category views. However, the submission lifecycle has notable gaps: the referenced list_my_submissions tool is absent, and there is no update, delete, or submission-status tool, creating a dead end after submitting.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
AI agent registry — search, discover, register, and connect agents via MCP.
Live index of AI agents, MCP servers and tools with observed liveness and capability search.
