Loading ToolBench
MCP server for generating beautiful code screenshots directly from Claude
The Code Screenshot MCP server demonstrates solid fundamentals with clear tool names, comprehensive parameter documentation, and proper schema structure. All four tools use action-verb naming (generate_, screenshot_, batch_) and have meaningful descriptions (105-168 chars, within the 10-1024 baseline). Input schemas are well-formed with type definitions and descriptions for all parameters. However, the server has several significant gaps: (1) output schemas are completely undocumented, callers cannot see what fields to expect from responses; (2) no error handling guidance, errors return bare text without recovery hints; (3) parameter descriptions lack actionable constraints (e.g., no mention of file path validation, line number bounds, or error cases); (4) no mention of idempotency or side effects for tools that read file systems; (5) missing dependency hints (e.g., 'screenshot_from_file requires filePath to exist'). The server falls into the 'Fair (C/B-)' range rather than 'Good (B+)', it has the right structure but lacks the polish and depth that production tools need.
Generate screenshots for multiple files at once. Useful for documenting multiple code files quickly.
Generate a beautiful screenshot of code with syntax highlighting and themes
Screenshot code directly from a file path, with optional line range selection. Auto-detects language from file extension.
Generate a screenshot of git diff output. Shows changes in your working directory or staged changes.
No output schemas documented. Callers have no visibility into response structure (e.g., file path format, base64 encoding, image dimensions, metadata fields). Pattern requires documented return types for all tools.
Error handling provides no recovery guidance. Errors return plain text ('❌ Error generating screenshot: ...') with no hint about what LLM should do next (retry? try different params? check preconditions?). Pattern requires actionable error messages.
Parameter descriptions lack actionable constraints. 'filePath' does not specify valid paths, forbidden characters, or max length. 'code' does not mention size limits or complexity constraints. 'startLine/endLine' lack bounds (1-indexed? max value?). Descriptions should include constraints inline.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
No idempotency guarantees. Tools read local files and git state. Generator.ts uses browser instances (Playwright), unclear if repeated calls with identical inputs produce identical outputs or if there are side effects (temp files, browser caches, Playwright instance reuse). Pattern requires idempotency or explicit caveats.
batch_screenshot provides no per-item error handling. If 10 of 50 files fail, unclear whether response returns partial results (9 succeeded, 1 failed with reason) or complete failure. Pattern requires per-item success/failure for batch ops.
Missing dependency hints and preconditions. screenshot_from_file assumes filePath exists; screenshot_git_diff assumes a git repo; generate_code_screenshot assumes Playwright can render. No descriptions mention these prerequisites or how to recover if they fail.