Loading ToolBench
MCP server for generating QR codes - URL, WiFi, phone, email, SMS, vCard, text
Single tool 'generate_qr' has a complete input schema with 17 parameters, all typed and described. Tool description is adequate (95 chars) but generic, lacks WHEN to use it or what it returns. Parameter descriptions are present but terse (avg 40 chars), missing format/constraint details. No output schema documented. Error handling not visible in source. Schema is well-structured (enums for type/format/errorCorrection) but lacks guidance on parameter interdependencies (e.g., which params apply to which QR type). Naming is clear and verb-forward ('generate_qr'), but description could better explain the multi-type capability and output format.
Generate a QR code. Supports: URL, WiFi, phone, email, SMS, vCard, and plain text. Returns base64 PNG or SVG string.
Output schema not documented. Tool description does not specify what fields are returned (base64 string, image dimensions, error details, etc.). LLMs cannot plan downstream usage without knowing the response structure.
Parameter interdependencies undocumented. The 'type' enum determines which other parameters are valid (e.g., 'url' type requires 'url' param; 'wifi' type requires 'ssid'). LLMs will pass irrelevant params or miss required ones without explicit guidance.
Tool description lacks context on when to use it and what it returns. Current description (95 chars) is functional but minimal. Should explain: 'Returns base64-encoded PNG or SVG string suitable for embedding in HTML/email. Supports 7 QR types: URL, WiFi credentials, phone, email, SMS, vCard, plain text.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Parameter descriptions are terse and lack format/constraint details. E.g., 'size' says 'QR code size in pixels (default: 400)' but does not specify valid range (e.g., 100 - 2000). 'errorCorrection' lists enum values but does not explain what each level means (L=7%, M=15%, Q=25%, H=30% recovery).
No error handling guidance visible. If an invalid WiFi encryption type or malformed email is passed, the tool should return a clear, actionable error (e.g., 'Invalid encryption: got "WEP2", must be WPA, WEP, or nopass'). Current implementation likely returns a generic error.