Loading ToolBench
Universal MCP server for HOL Registry Broker discovery, chat, registration, and workflow automation.
The server defines 17 tools with basic descriptions and input schemas. However, critical quality gaps significantly limit LLM usability: (1) Tool names lack clear action verbs, e.g., 'hol.stats', 'hol.capabilities', 'workflow.discovery' are noun-heavy rather than verb_noun patterns. (2) Descriptions exist but are generic and lack context on WHEN to use each tool vs. alternatives, e.g., 'Retrieve server statistics' does not explain what metrics are returned or why an agent would call it. (3) Parameter descriptions are minimal; many lack guidance on constraints, formats, or allowed values. (4) Input schemas are declared but lack full JSON Schema structure with explicit type constraints, ranges, or enums. (5) Output schemas are not documented, LLMs cannot predict what fields to expect. (6) No explicit idempotency hints for write operations (chat.createSession, chat.sendMessage, registerAgent claim idempotencyKey support but tool descriptions do not explain this). (7) Error handling is not addressed in any tool description. Tools like hol.search accept 'limit' (number) and 'type' (string) but do not specify min/max or valid values. Overall, the server meets a basic threshold (all tools have names, descriptions, and input specs) but falls short of production-grade LLM tool design.
Retrieve server capabilities and feature availability including authentication status
Create a new chat session with an agent
End an active chat session
Retrieve chat message history for a session
Check the readiness status of an agent for chat
Resume an existing chat session
Send a message in an active chat session
Tool names lack clear action verbs and follow inconsistent naming convention. 'hol.stats', 'hol.capabilities' are noun-based; 'workflow.discovery' is vague. Should use patterns like 'get_server_stats', 'list_capabilities', 'search_agents_in_registry'. LLMs rely on verb_noun patterns to infer intent before reading descriptions.
Descriptions lack LLM-actionable context. Tool descriptions state WHAT they do but not WHEN to use them or how they differ from similar tools. E.g., 'hol.search' vs 'hol.vectorSearch', when should an agent prefer one over the other? No guidance provided. Descriptions should be 50 - 200 chars and answer: What? When? What are prerequisites?
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 61 | - | v1 |
Get a registration quote for agent profile and endpoint
Register a new agent in the HOL Registry
Resolve a Universal Agent ID (UAID) to retrieve agent details
Search the HOL Registry for agents and services by query string
Retrieve server statistics and operational metrics
Vector-based semantic search across the HOL Registry
Wait for and retrieve the result of an agent registration
Delegate a discovery task to the AI assistant for finding and summarizing agents
Workflow for discovering agents and services in the HOL Registry with AI assistance
Workflow for registering agents in the HOL Registry with validation and completion tracking
Output schemas are completely undocumented. Tools return results but LLMs cannot predict structure, no field names, types, or example objects provided. This forces agents to guess what fields are available, risking failed downstream tool calls. Every tool must document its return type.
Parameter descriptions are minimal and lack constraint guidance. 'limit' (number) parameters have no min/max documented. 'type' string parameter in hol.search has no enum or allowed values listed. 'protocol' in hol.registerAgent is not constrained. Per the rubric, parameters must state expected format, range, and allowed values explicitly.
Write operations (hol.chat.createSession, hol.chat.sendMessage, hol.registerAgent) declare 'idempotencyKey' parameters but tool descriptions do NOT explain how idempotency works, what the key format is, or when to use it. LLMs need explicit guidance: 'Pass the same idempotencyKey to replay the same request safely without duplicate side effects.'
No error handling guidance in any tool description. Error responses must tell LLMs what to do next (retry, ask user, fail). Risk classification (retryable vs user-fixable vs fatal) is missing. Tools like hol.resolveUaid offer no hint about how to handle 'UAID not found', agent must guess whether to retry or suggest an alternative.
Parameter type schema is incomplete. Input schemas show parameter names and descriptions but lack full JSON Schema structure (no explicit 'type', 'required', 'enum', 'minimum', 'maximum', 'pattern'). E.g., hol.search 'limit' parameter has no min/max constraint visible in schema.
Workflow tools (workflow.discovery, workflow.registration, workflow.delegate) have generic, overlapping descriptions. 'Workflow for discovering agents' vs 'Delegate a discovery task', unclear when to use each. Workflow composition and dependencies are not documented. Agents cannot reason about which workflow to invoke for a given task.