Loading ToolBench
PicGo MCP has three tools with adequate naming (all start with action verbs: upload_, get_) and basic descriptions. However, there are significant quality gaps: parameter descriptions are minimal or missing, output schemas are not documented, and error handling lacks recovery guidance. Tools are directly registered in code with schemas visible. The upload_image and upload_images tools accept file paths but lack validation constraints, format guidance, or error recovery steps. The get_picgo_config tool returns configuration but the response structure is undocumented. Overall, this server falls into the 'fair' range with noticeable gaps typical of community MCP tools.
Get current PicGo configuration
Upload an image using PicGo and get the URL
Upload multiple images using PicGo and get their URLs
Parameter descriptions are missing or insufficient. 'image_path' and 'image_paths' lack format guidance (absolute vs relative paths), validation rules (file existence, size limits, supported formats), and error recovery hints.
Output schemas are not documented. Tools return unstructured text responses in CallToolResult.content[0].text. LLMs cannot parse expected fields (URL, error status, upload metadata) without seeing the response structure. Baseline: 100% of A+ tools document return types.
Error messages lack recovery guidance. Code throws McpError with generic messages like 'Tool execution failed: ...' and stderr output, but does not tell the LLM what to do next (e.g., 'File not found, check the path is absolute' or 'PicGo not installed, see setup instructions').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
get_picgo_config has minimal description (10 chars: 'Get current PicGo configuration'). No guidance on when to call it, what structure it returns, or how the agent should use the output.
No input validation constraints documented. Parameters should state: (1) absolute vs relative path acceptance, (2) file size limits, (3) supported MIME types (e.g., image/jpeg, image/png), (4) maximum array length for upload_images.
Responses return raw stdout parsing results (e.g., 'File upload success, url: https://...') as unstructured text. Should return structured JSON with typed fields: {type: 'success'|'error'|'already_exists', url?: string, message: string}.
upload_images combines multiple upload calls but returns aggregated results as a single text block. Should return per-item success/failure so the agent knows which uploads succeeded and can retry only failed ones.