Loading ToolBench
A Model Context Protocol server for executing code against multiple API backends (REST, GraphQL, SPARQL) with auto-staging, schema discovery, and sandboxed V8 isolate execution.
OpenBind provides 5 tools with complete input schemas and descriptions. Naming follows verb_noun patterns (catalog_search, execute, graphql_execute, sparql_execute, search). Descriptions are detailed (150-300 chars) and explain WHEN to use each tool. However, parameter descriptions lack specificity on constraints (e.g., max_results accepts 'number' but no min/max bounds stated in schema). Output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling is absent from visible code. Security model (sandboxed V8, no secrets in isolate) is sound but not explicitly documented in tool descriptions.
Search the API catalog (legacy mode). The tool accepts query/category/max_results parameters and performs keyword-based search over the static ApiCatalog. Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling execute.
Execute JavaScript code against REST APIs with auto-staging, schema discovery, and sandboxed V8 isolate execution. Code runs with api.get/api.post wrappers, catalog search helpers, and console.log() capture. API keys never enter the isolate — all HTTP goes through the host's apiFetch.
Execute JavaScript code against GraphQL APIs with schema introspection, auto-staging, and sandboxed V8 isolate execution. Code runs with gql.query() for GraphQL execution, schema.* helpers for introspection, and optional REST API support (hybrid mode). API keys never enter the isolate — all HTTP goes through the host's gqlFetch.
Search the OpenAPI spec (new mode) or API catalog (legacy mode). In OpenAPI mode, write JavaScript code to search the spec using helper functions (searchPaths, listTags, getOperation, describeOperation) or access spec.paths directly. In catalog mode, use keyword search with query/category/max_results parameters.
Execute JavaScript code against SPARQL endpoints with query execution, endpoint introspection, auto-staging, and sandboxed V8 isolate execution. Code runs with sparql.query(), sparql.ask(), sparql.raw() for SPARQL execution, and common ontology prefix helpers. The endpoint URL never enters the isolate — all HTTP goes through the host's sparqlFetch.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining or data extraction.
Numeric parameter 'max_results' lacks min/max bounds in schema. Description states 'default 10, max 25' but schema does not enforce via JSON Schema constraints (minimum, maximum fields).
Error handling and recovery guidance absent from visible tool code. No documented error categories (retryable, user-fixable, fatal) or actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Parameter 'workspace' (optional, execute/graphql_execute) lacks description of what 'workspace ID' means, how to obtain one, or when to use it. LLMs cannot reason about optional parameters without context.
Tool descriptions reference downstream tools (e.g., 'use ${prefix}_query_data to explore') but those tools are not visible in the provided source. Broken tool-chain references.