Loading ToolBench
Bambuddy MCP provides 4 proxy tools with generally clear naming and descriptions, but has significant gaps in parameter documentation and output schemas. Tool names follow verb_noun convention well (list_categories, search_tools, execute_tool, find_printer). Descriptions are detailed and context-aware, ranging from 100-200+ characters and explaining WHEN to use each tool and what to do next. However, critical issues emerge in parameter handling and schema completeness. The search_tools and execute_tool parameters lack explicit type constraints (enums for limit bounds, no validation guidance). Output schemas are completely undocumented, LLMs cannot predict what fields to expect from execute_tool responses, forcing blind chaining. The execute_tool tool accepts an 'arguments' object with no schema definition, making it impossible for LLMs to validate what nested parameters are valid before calling. The embed_image parameter guidance is present but could be stricter about when images are available. Error handling descriptions mention censoring but lack recovery guidance for failed API calls. Overall, the server prioritizes usability for simple discovery (list_categories, search_tools, find_printer) but leaves the most complex tool (execute_tool) under-specified.
Execute a Bambuddy API tool by name. Use search_tools first to find the tool name and its required arguments. Images are saved to disk by default — use xdg-open to show them to the user. Only set embed_image=true if you need to analyze the image content yourself.
Find a printer by name. Returns printer details including the printer_id needed by other tools. Use this when you know a printer's name but need its ID.
List all available tool categories and the total tool count. Use this first to understand what's available.
Search for tools by keyword. Returns matching tool names, descriptions, and input schemas. Use this to find the right tool before calling execute_tool.
execute_tool's 'arguments' parameter has no input schema. LLMs cannot validate what parameters are acceptable before calling, forcing blind submission of nested objects.
No output schemas documented for any tool. LLMs cannot predict response structure, field names, or types. This forces speculative chaining and makes downstream tool calls fragile.
search_tools 'limit' parameter lacks bounds documentation. LLMs could pass absurd values (0, -1, 999999) with no guidance on valid range.
execute_tool description mentions censoring but provides no error recovery guidance. If a censored field is attempted, the LLM cannot self-correct without explicit error messaging.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
find_printer 'name' parameter accepts substring match (case-insensitive) but this behavior is not explicit. LLMs may expect exact match or regex patterns, leading to confusion.
execute_tool does not declare what permissions are required (read vs write, API scopes). Agents cannot reason about privilege levels or plan around permission failures.
No guidance on timeout behavior. If an API call hangs, LLMs do not know if they should retry, escalate, or abandon the request.