Loading ToolBench
bruno-mcp demonstrates solid fundamentals with all 8 tools properly registered, described, and schematized using Zod validation. Tool naming follows verb_noun conventions (create_*, list_, get_) and is generally clear. However, several tools have moderate parameter documentation gaps, output schemas are not formally documented, and error handling is generic (catch-all error messages without recovery guidance). The server handles file I/O operations with appropriate risk labeling (WRITE vs READ_ONLY) and includes helpful emoji-based success/failure indicators, but lacks the depth of error classification and user-fixable guidance expected of production-grade tools. Descriptions are adequate (mostly 50-150 chars, within the 10-1024 baseline) but could better explain WHEN to use each tool and any prerequisites. Schemas are present and properly typed, but output structures are not formally documented in the tool definitions.
Add pre-request or post-response scripts to Bruno requests
Create a new Bruno API testing collection with configuration
Generate a set of CRUD (Create, Read, Update, Delete) API requests
Create environment configuration files for Bruno collection
Generate .bru request files for API testing
Generate comprehensive test collections with multiple related requests
Get statistics about a Bruno collection including request counts and structure
Output schemas not formally documented. Tool responses return structured text (content type: 'text' with emoji-prefixed success/error messages) but do not declare expected output fields in the tool definition. LLMs cannot reliably extract structured data for downstream tool chaining.
Error handling lacks recovery guidance and categorization. All error paths return generic catch-all messages like 'Error creating collection: [error message]' without suggesting next steps (e.g., 'Does the output path exist?' or 'Try with a different collection name'). Errors are not classified as retryable vs. user-fixable vs. fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
List all Bruno collections in a directory
Parameter descriptions lack format/constraint guidance. For example, 'baseUrl' in create_collection is described only as 'Optional base URL for the collection' without clarifying the expected format (must be valid URL, which Zod validates but description doesn't warn). 'outputPath' lacks clarity on whether it must be absolute vs. relative, exist vs. be created, or what permissions are required.
Pagination and limits not implemented for list_collections. Returns unstructured text summary rather than paginated structured results. For domains with many collections, this risks context window exhaustion and prevents batching patterns.
No tool annotation hints. Tools like create_collection, create_request (WRITE operations) and list_collections, get_collection_stats (READ_ONLY) are not decorated with idempotentHint, destructiveHint, or readOnlyHint. This forces LLMs to reason about side effects from descriptions alone.
Tool descriptions do not explain WHEN to use the tool or distinguish it from similar tools. For example, create_test_suite vs. create_crud_requests both generate multiple requests, the description does not clarify the distinction or when to choose one over the other. Agents may pick wrong tool.
No dry-run or confirmation for destructive operations. Tools like add_test_script modify files directly without a preview or confirmation option. Agents make mistakes, no confirmation pattern prevents accidental overwrites.
Parameter names could be more specific. 'ignore' in create_collection and 'config' in create_request auth object are generic. 'ignore' should be 'ignore_patterns' or 'ignore_globs'; 'config' should clarify what it contains (e.g., 'bearer_token' for bearer auth, 'username' and 'password' for basic auth).