Loading ToolBench
MCP server that exposes the AgentRegistry catalog over the Model Context Protocol, allowing Claude and other MCP clients to list and fetch resources (agents, MCP servers, skills, prompts, models, plugins, deployments, runtimes) as typed tools with v1alpha1 envelope structure.
AgentRegistry MCP server exposes 16 read-only tools following a consistent naming and schema pattern. All tools follow verb_noun naming (list_*, get_*) with clear, descriptive short descriptions (50-90 chars). Input schemas are complete with typed parameters and descriptions. However, output schemas are NOT documented in the provided source code, and several design issues reduce overall quality: (1) output structure is not formally declared, forcing LLMs to infer response fields; (2) pagination is present but not well-integrated into the mental model across all list_* tools; (3) many parameters lack constraint documentation (enums, ranges, defaults); (4) error handling guidance is absent, no recovery suggestions or error categorization. The server is well-structured for discovery use cases but lacks production-grade refinement in schema documentation and error guidance.
Fetch a published agent as a v1alpha1 envelope (defaults to the latest tag).
Fetch a deployment as a v1alpha1 envelope by namespace/name.
Fetch a published model as a v1alpha1 envelope (defaults to the latest tag).
Fetch a published plugin as a v1alpha1 envelope (defaults to the latest tag).
Fetch a published prompt as a v1alpha1 envelope (defaults to the latest tag).
Fetch a runtime as a v1alpha1 envelope by namespace/name.
Fetch a published MCP server as a v1alpha1 envelope (defaults to the latest tag).
Output schemas are not documented. No formal declaration of what fields list_agents, get_agent, etc. return. LLMs cannot plan downstream calls or extract required fields (e.g., does get_agent return 'version', 'metadata', 'spec'?). This violates pattern:tool and forces LLMs to guess response structure.
Parameter descriptions lack constraint documentation. 'limit' parameter states 'default 30, max 100' but this is in the description text, not a formal JSON Schema constraint (minItems, maxItems, minimum, maximum). LLMs cannot reliably respect bounds if they are not in structured schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Fetch a published skill as a v1alpha1 envelope (defaults to the latest tag).
List published agents as v1alpha1 envelopes with optional namespace, substring-name, and tag filters.
List deployments as v1alpha1 envelopes with optional namespace and substring-name filters.
List published models as v1alpha1 envelopes with optional namespace, substring-name, and tag filters.
List published plugins as v1alpha1 envelopes with optional namespace, substring-name, and tag filters.
List published prompts as v1alpha1 envelopes with optional namespace, substring-name, and tag filters.
List runtimes as v1alpha1 envelopes with optional namespace and substring-name filters.
List published MCP servers as v1alpha1 envelopes with optional namespace, substring-name, and tag filters.
List published skills as v1alpha1 envelopes with optional namespace, substring-name, and tag filters.
No error handling guidance. Tools are read-only with no explicit error recovery suggestions. What if 'namespace' is invalid or 'agent not found'? The descriptions do not tell LLMs whether to retry, ask the user, or call an alternative discovery tool.
Pagination cursor semantics are unclear. 'cursor' parameter is documented as 'Pagination cursor for fetching the next page' but no return structure is specified. Do list_* tools return 'next_cursor' or 'has_more' or a 'links.next' field? Without this, LLMs cannot implement multi-page iteration reliably.
Enum constraints missing for 'tag' parameter. Description says 'Filter by specific tag (e.g., 'latest', 'v1')' but does not declare valid values. Are tags arbitrary user-defined strings, or a constrained set? LLMs will invent tag values if not told otherwise.
No tool annotations for read-only semantics. Despite all 16 tools being read-only queries, tool definitions do not include readOnlyHint or idempotentHint. This prevents agents from safely batching or retrying without explicit confirmation.