Loading ToolBench
A production-ready JavaScript sandbox runtime with streaming protocol, tool broker, and browser isolation. Provides secure code execution for agents and LLMs with tool bridging capabilities.
EnclaveJS demonstrates basic tool structure but falls significantly short of production-grade quality. The server exposes 9 tools across two demo apps (broker-server.ts and mock-tools.ts), all with minimalist descriptions and incomplete schemas. Naming follows some conventions (verb_noun pattern present in most cases), but parameter descriptions are sparse or absent in critical areas. No input validation logic visible in source code. Error handling guidance is absent. Output schemas are undocumented. The tools appear to be demonstration/example tools rather than production implementations, reflected in their READ_ONLY risk classification and toy nature (greet, getCurrentTime, multiply). Only 3 of 9 tools have complete parameter type definitions visible. No security patterns (secret injection, permission gates, audit trails) are evident in the available source code. Composition follows single-responsibility patterns reasonably well, but lack of chaining IDs and result documentation makes multi-step workflows difficult.
Adds two numbers together
Returns mock data for a given key
Fetches JSON data from an external API
Returns current timestamp and server information
Returns a greeting message
Adds two numbers (a + b)
Multiplies two numbers together
Reverses a string
No input schemas documented for 4 tools: getCurrentTime, fetchExternalApi, useSecret, and unnamed tool implementations. Tools with {} empty schemas provide zero guidance to LLMs about what parameters are expected.
Descriptions are generic and insufficient for LLM tool selection. 'Returns current timestamp and server information' (getCurrentTime), 'Fetches JSON data from an external API' (fetchExternalApi), 'Demonstrates secret injection and usage' (useSecret) lack actionable context about WHEN and WHY to call these tools vs alternatives.
No output schemas documented for any tool. LLMs cannot infer what fields will be returned, making downstream tool chaining impossible. E.g., does getCurrentTime return {timestamp, timezone, server_name} or just a string?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Demonstrates secret injection and usage
fetchExternalApi accepts no documented parameters despite taking an URL endpoint. The empty {} schema hides what data the tool actually accepts and what the LLM should provide.
useSecret has no schema and a vague description ('Demonstrates secret injection'). Does it read a secret? Return a secret? How does the LLM invoke it? Demonstration code does not constitute production-ready tooling.
No error handling or recovery guidance in any tool description. E.g., fetchExternalApi does not document what happens if the endpoint is unreachable, returns non-JSON, or times out. An LLM cannot decide to retry, ask the user, or proceed with partial results.
Parameter descriptions are missing or incomplete for several tools. 'name' in greet has a description, but getCurrentTime, fetchExternalApi, and useSecret have no parameter information at all (empty schemas).
No idempotency or state-change documentation. Tools like multiply and addNumbers appear read-only, but greet, getCurrentTime, and fetchExternalApi do not clarify whether they have side effects. Agents need to know if a tool is safe to retry.
Tool descriptions do not include dependency hints or multi-step context. E.g., if fetchExternalApi requires credentials, the description should say 'Call useSecret first if API requires authentication.' Undocumented dependencies cause failed calls and wasted attempts.