Loading ToolBench
A distributed capability mesh DNS server for resolving servers by capability with health checking and event logging
MeshDNS has 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (resolve, listServers, registerServer, etc.). Descriptions are present and adequate (50-150 chars), explaining WHAT each tool does. However, parameter descriptions lack depth, many omit format constraints, ranges, or validation rules. Output schemas are not documented in the source. Error handling is minimal; no recovery guidance visible. Security concerns: registerServer and updateServer accept credentials/tokens as parameters (owner_contact could leak secrets). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Composition is reasonable, tools are single-purpose and chainable (resolve → listServers → registerServer).
Delist a server from the mesh. Requires Bearer token authorization with the write key.
Export all servers in the mesh with their current state and metadata.
List servers with optional filters and cursor-based pagination.
Register a new server in the mesh with capabilities and health check URL.
Resolve servers that provide the given capability. Returns active (up) servers ordered by uptime descending.
Get statistics about the mesh including server counts and recent event counts.
Update an existing server's configuration. Requires Bearer token authorization with the write key.
Parameter descriptions lack format constraints and validation rules. E.g., 'name' parameter has regex ^[a-z0-9][a-z0-9-]{1,63}$ but description does not state this. 'limit' has max 100 but description does not specify range. LLMs cannot read JSON Schema patterns, they rely on description text.
No output schemas documented. Tools return JSON but LLMs do not know what fields to expect (e.g., does resolve() return uptime_30d, last_checked_at, status?). This forces LLMs to guess field names for downstream calls.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. deleteServer is DESTRUCTIVE but unmarked. resolve and listServers are READ_ONLY but unmarked. Agents cannot distinguish safe from dangerous operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Error handling is not visible in source. No recovery guidance, error categorization, or actionable error messages. If registerServer fails due to duplicate name or invalid URL, the LLM has no guidance on what to do next.
Security: owner_contact parameter in registerServer/updateServer could leak secrets if agents pass API keys or tokens. No guidance that this field should contain only contact info, not credentials. Credentials should use server-side secret injection.