Loading ToolBench
MCP server for generating, editing, and managing images using OpenAI's image generation APIs (DALL-E)
Critical gaps across all tools. Tool definitions are inferred from module exports (server.ts line 24-28: `server.tool(t.name, t.description, (t.schema as any).shape ?? {}, ...)`) rather than directly visible in source. No parameter descriptions found in provided code. Schemas appear to use Zod but actual shape definitions not shown. Tool names lack clarity (e.g., 'edit-image-conversation' is ambiguous, does it edit images in a conversation or manage conversation state?). Error handling exists (error-mapper.ts) but is not integrated into tool responses. No evidence of output schema documentation or pagination support.
Tool definitions inferred, not directly visible. server.ts registers tools via `server.tool(t.name, t.description, (t.schema as any).shape ?? {}, ...)` but actual tool files (generate-image.ts, edit-image.ts, etc.) not provided. Cannot verify parameter schemas, descriptions, or output types.
No parameter descriptions visible in source. Rubric requires every parameter to have a description explaining what it controls. Without seeing tool files, cannot verify compliance.
Tool name 'edit-image-conversation' is ambiguous. Does it edit images within a conversation context, or manage conversation metadata? Violates verb_noun clarity rule. Should be 'edit_image_in_conversation' or split into separate concerns.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 23 | <=2025-11-25 | v2 |
No output schema documentation visible. Rubric requires documenting return types so LLMs know what fields to expect. Cannot verify if responses include necessary chaining IDs (e.g., conversation_id for follow-up calls).
Error handling exists (error-mapper.ts) but is not integrated into tool response contracts. No evidence of error categorization (retryable vs user-fixable vs fatal) or recovery guidance in tool definitions.