Loading ToolBench
Server provides 5 image processing tools with explicit schema registration in src/index.ts. All tools have JSON Schema definitions with parameter types and descriptions present. However, descriptions are minimal (10-20 chars) and parameter descriptions are sparse or missing context. The server uses TypeScript interfaces for internal types but relies on inline JSON Schema specs. Tool naming follows verb_noun convention (resizeImage, convertImage, cropImage, rotateImage, getImageInfo) but descriptions lack depth about when to use each tool versus others, prerequisites, and what state modifications mean. Error handling returns generic success/failure responses without actionable recovery guidance. No output schema documentation visible for response structures. Critical security issue: tools accept arbitrary file paths with minimal validation, risking path traversal attacks.
转换图片格式
裁剪图片
获取图片信息
根据指定尺寸调整图片大小，可以通过设置填充方式来控制图片的裁剪方式
旋转图片
Minimal tool descriptions (10-25 chars) lack context. 'resizeImage' description is '调整图片尺寸' (10 chars); 'convertFormat' is '转换图片格式' (8 chars). Current descriptions are below the p10 threshold and do not explain WHEN to use each tool versus others, or what the tool returns.
No documented output schema. Code shows tools return {result: {success: bool, message: string, output_path?: string}}, but this structure is not declared in capability specs. LLMs cannot plan downstream operations without knowing response structure. Tool responses should document all fields the agent will receive.
Path traversal vulnerability. Tools accept input_path and output_path as arbitrary strings with only fs.access() and fs.mkdir() calls. No canonicalization, no allowlist, no chroot. Attacker could pass '../../../etc/passwd' or symlink attacks. Per pattern:tool-gateway, all agent-provided input must be sanitized against path traversal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Error responses are opaque to LLM recovery. All error handlers return {success: false, message: '...'} with no actionable guidance. Per pattern:recovery-guide, errors should tell LLM what to do next, e.g. 'File not found at /path/to/file. Verify the path exists and is readable.' Current responses give the LLM nothing to act on.
No input validation beyond fs.access(). Parameter constraints like fit enum, format enum, numeric ranges (width, height, angle, quality) are declared in schema but not validated in implementation. sharp library will throw, but error messages are not user/LLM-actionable. Per review:actionable-errors, invalid input should return 'Invalid quality: got 150, must be 1-100'.
Destructive tools (resizeImage, convertFormat, cropImage, rotateImage) lack confirmation or dry-run support. Per pattern:confirmation-request, write operations should support a dry-run mode or confirmation step. Agents can be tricked into overwriting user files.
getImageInfo has no documented response structure. Code calls sharp().metadata() but does not document what fields are returned (width, height, format, space, depth, etc.). LLMs cannot construct meaningful queries without knowing available fields.