Loading ToolBench
Local-first Agentic Resource Discovery publisher and registry that serves AI skills and tools to agents over a local HTTP and MCP server.
Server implements 4 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search, get_resource, get_skill, execute). Descriptions are substantive (100-250 chars) and explain WHAT, WHEN, and output behavior. However, parameter descriptions are sparse or missing entirely, 'limit' and 'filter' in search lack descriptions; 'include_body' in get_resource/get_skill lack descriptions. Output schemas are not documented. Error handling guidance is absent. The execute tool's sandbox model is innovative but underdocumented (no mention of error modes, timeout behavior, or recovery). get_skill is a pure alias of get_resource, violating single-responsibility; this should be deprecated or removed. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only.
Write JavaScript that calls the registry to discover/filter/aggregate resources in one shot. A `registry` global is pre-injected: registry.search(query, opts?) — same ranking as the search tool, opts = { limit, filter: { type, tags, capabilities } } — registry.get(identifier), registry.listAll(filter?). Return a value; it is JSON-serialized back. Sandboxed: no network, no filesystem, time- and memory-limited. Write plain JS.
Fetch one catalog entry by its URN identifier, optionally including the artifact body (the SKILL.md of a skill, the definition file of a subagent).
Alias of get_resource, kept for existing clients.
Search the local ARD registry by natural-language query. Returns ranked results (score 0-100) with metadata but NOT bodies — use get_resource for those. Entries are AI Skills (type application/ai-skill) and subagent definitions (type application/ai-agent+md); filter.type selects a family.
Parameter descriptions missing or incomplete. 'limit', 'filter', 'include_body', and 'code' parameters lack descriptions explaining their purpose, constraints, or expected format. LLMs cannot infer parameter semantics from names alone.
Output schemas not documented. Tool descriptions do not specify the structure of returned results (fields, types, pagination). LLMs cannot plan downstream calls or extract required data without knowing response shape.
get_skill is a pure alias of get_resource, violating single-responsibility principle. Duplicate tools waste LLM reasoning cycles and create ambiguity about which to call. Should be deprecated or removed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
No error handling guidance. Tool descriptions do not explain failure modes, recovery steps, or what to do if a search returns no results, a resource is not found, or the sandbox times out. Agents have no recovery path.
No tool annotations. All tools are read-only but lack readOnlyHint annotation. This prevents clients from optimizing caching, retry logic, or safety checks.