Loading ToolBench
MCP server that converts URLs to QR codes with downloadable links
URL2QR-MCP is a single-tool server with a well-defined tool definition. The tool 'url_to_qrcode' has a clear action verb, complete JSON Schema with typed parameters, and functional descriptions. However, descriptions lack LLM optimization depth (parameter descriptions are minimal), output schema is undocumented, and error handling guidance is absent. The tool performs a focused, single responsibility (URL→QR conversion), making it compositionally sound. Schema is explicit and properly typed with enum constraints on errorCorrectionLevel, meeting structural baselines. Relative to the rubric's calibration, this is solid but not exceptional, descriptions are present but generic, and critical output documentation is missing.
Convert a URL into a QR code image and return the download link. The QR code will be saved as a PNG file and accessible via HTTP.
Output schema is not documented. The tool description states it returns 'the download link' but the actual response structure (fields, types, example URL format) is never specified in the tool definition or code comments visible in the excerpt.
Tool description is generic and lacks LLM-guidance context. At 150 characters, it states WHAT (convert URL to QR) but omits WHEN to use it vs alternatives and any prerequisites or dependencies. Baseline descriptions average 194 chars; this is below median and lacks specificity.
Parameter descriptions are minimal. 'url' is described adequately with example (102 chars), but 'errorCorrectionLevel' (43 chars) and 'width' (50 chars) lack context. The errorCorrectionLevel description does not explain WHEN an agent would prefer H vs L, or what the trade-offs are (file size vs robustness). Baseline param descriptions average 72 chars; 'width' is 50.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | 2024-11-05+ | v1 |
No error handling guidance. The tool can fail in multiple ways (invalid URL, file system write failure, invalid width) but the definition provides no recovery hints or error classification. Agents are left guessing what to do on failure.
Parameter 'width' is unbounded. The schema declares it as type 'number' with no min/max constraints. An agent could pass width=10000000, causing memory exhaustion or timeout. Baseline numeric parameters have explicit bounds (e.g. page_size 1 - 100).