Gyazo MCP Server defines 4 tools with complete input schemas and descriptions. Tool naming follows action-verb conventions (search, fetch, upload). Descriptions are present and adequate (62-96 chars), exceeding the 20-char minimum. However, descriptions lack critical context about when to use tools and how they differ (e.g., gyazo_image vs gyazo_latest_image). Parameter descriptions are inconsistent: gyazo_search includes detailed format guidance; others are minimal. Output schemas are not explicitly documented, responses are inferred from code (text + image/JSON content). Error handling is basic (Error objects thrown but not classified for agent recovery). No output schema definitions in code. The server accepts a 'name' parameter in gyazo_latest_image with a const constraint, which is awkward and suggests the tool could be simplified to take no parameters. Overall, the tools are functional but fall short of production polish.
Fetch image content and metadata from Gyazo
Fetch latest uploaded image content and metadata from Gyazo
Full-text search for captures uploaded by users on Gyazo
Upload an image to Gyazo
Output schemas not documented. Tool responses return text (JSON) and image content, but no schema is defined describing the structure of returned fields (image_id, permalink_url, ocr, metadata, etc.). LLMs cannot reliably extract fields or plan downstream calls without explicit output schema documentation.
gyazo_latest_image requires a 'name' parameter with const='gyazo_latest_image'. This is redundant and awkward, the tool name already identifies it. Accept zero parameters instead, or rename to reflect a genuine input requirement.
Parameter descriptions are inconsistent. gyazo_search.query includes detailed examples and formatting guidance ('title:cat', 'app:"Google Chrome"', date ranges). By contrast, gyazo_image.id_or_url and gyazo_upload.imageData lack format guidance. This makes gyazo_upload.imageData especially risky, LLMs may not know that base64 is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Tool descriptions do not disambiguate usage. gyazo_image and gyazo_latest_image both fetch images, but descriptions do not explain: (1) when to use latest_image vs searching, (2) whether id_or_url can be a permalink or only a raw ID, (3) what metadata is returned. This forces LLMs to guess or try both.
Error handling is minimal. Errors are thrown as generic Error objects ('Tool execution failed: {message}') with no recovery guidance. LLMs cannot distinguish retryable errors (timeout, rate limit) from user-fixable errors (invalid image ID) from fatal errors (auth failure). Per pattern:recovery-guide, errors should guide the next action.
No dry-run or confirmation for destructive operations. gyazo_upload modifies state by uploading images, but there is no way for an agent to preview or confirm before committing. Per pattern:confirmation-request, write operations should support a safe preview.