Agent Nexus

Search registry

search_registry

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 22, 2026

changedInput schema / properties / category / description

Previous 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."

changedInput schema / properties / limit / description

Previous 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."

changedInput schema / properties / query / description

Previous 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."

Changed2 schema fields changedSep 21, 2026

addedInput schema / properties / limit / description

Added value: +"Maximum number of entries to return (1-50)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "results": {
+      "items": {},
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "results"
+  ],
+  "type": "object"
+}

First observedSep 16, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent, but the description adds substantial non-structured behavior: results are ordered alphabetically not by relevance, there is no pagination beyond limit, empty results[] is a valid success case, and only literal substrings (with certain chars stripped) match. These are exactly the traits an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, followed by routing, then behavior. Most sentences carry unique value, but 'Read-only and side-effect free' duplicates the annotations and the return-shape sentence is partly redundant given the output schema, adding slight bulk to an already dense block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with three documented parameters, full schema coverage, annotations, and an output schema, the description covers matching semantics, ordering, pagination limits, and empty-result handling. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema's own parameter descriptions are already unusually detailed (case-insensitive matching, stripped characters, AND semantics, limit range). The description restates the same limit/ranking caveats without adding syntax or format meaning the schema lacks, so baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('keyword lookup in the Agent Nexus registry') plus the exact matching mode (literal text, not goal interpretation). It explicitly distinguishes itself from discover_capabilities, list_entries, and get_entry, so an agent can route correctly without opening any sibling schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use condition ('when you already know what to look for: a product name, vendor, slug or endpoint fragment'), an explicit when-not ('it does not interpret a goal'), and names the three alternative tools with the conditions that select them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Agent Nexus tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?