Loading ToolBench
Model Context Protocol server for Bruno collections — lets AI clients discover and execute Bruno requests reusing Bruno's runtime, auth, and environments.
Four well-named tools with clear verb-noun patterns (list_*, get_*, execute_*). All have descriptions (194 - 250 chars, within baseline 34 - 392). Input schemas present with type declarations and parameter descriptions. Output schemas not explicitly documented in source. Error handling guidance absent, tools do not indicate what to do on failure or how to recover. Tool composition is sound: list_collections → list_requests → get_request → execute_request forms a logical chain. Risk annotations (READ_ONLY, DESTRUCTIVE) present but not formally integrated into schema. Missing: pagination guidance for list_requests (could return hundreds of items), output field documentation, and recovery hints for common failures.
Execute a named request from a Bruno collection through Bruno's runtime, applying the collection's environment variables, scripts, assertions, tests, and configured auth. Returns the status, request and response headers, response body in full, and assertion/test results. Returns the HTTP status, headers, response body, and any test results.
Gets the full details of an API request without executing it. Returns the HTTP method, URL, headers, body, authentication, scripts, and tests. Use this to inspect what a request does before running it or to understand its configuration.
List all available Bruno collections: by default the ones this server was configured or discovered to expose. Returns the name, filesystem path, and available environments for each. Use this first to discover what collections exist and get the path needed for other tools. Optionally filter by a search term (matched against name, path, and workspace name).
List every request in the given collection, flattened across folders. Returns just enough to identify and address each one: the relative path used to invoke get_request and execute_request, the type (http-request, graphql-request, grpc-request, ws-request), plus method and URL when statically known. Call get_request for a single request's headers, body, auth, scripts and tests; those are deliberately not listed here, so this stays fast on large collections. Optionally filter by a search term (matched against name, path, and URL) and/or HTTP method.
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., does execute_request return response_body, status_code, headers separately?). Breaks tool chaining and forces guesswork.
No error recovery guidance. Descriptions lack hints like 'If collection not found, try list_collections() first' or 'Invalid environment name, call list_collections to see available environments.' Agents cannot self-correct on failure.
list_requests lacks pagination parameters (limit, offset, page_size). Description states 'flattened across folders' but does not specify result cap. Large collections could return hundreds of items, exhausting context window.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
execute_request description does not explicitly state it is destructive/has side effects. Risk annotation present in metadata but not in description text. LLMs may not recognize this as an irreversible operation requiring caution.
Parameter 'variables' in execute_request is typed as 'object' with no schema constraints. LLMs cannot validate structure. Should specify: object with string keys and values, or reference environment variable naming rules.