Loading ToolBench
MCP server for media asset processing with dual-provider image generation (Google Gemini + OpenAI)
The server registers a single tool, 'create_asset', with a comprehensive input schema, clear description, and proper output structure. The tool definition is explicit and visible in server-handlers.ts. Naming follows verb-noun convention (create_asset). The description is detailed (184 chars) and explains what the tool does, when to use it, and that it saves files and returns metadata. Input schema is properly typed with enums for constrained fields (aspectRatio, background, outputFormat). Output schema is documented with CreateAssetResponse type. Error handling includes validation error responses with actionable messages (VALIDATION_ERROR, INTERNAL_ERROR error codes). Tool annotations are present (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). However, several parameters lack descriptions in the schema (outputPath, referenceImages, mask all lack detail on format/constraints). The server uses a pass-through validator to keep hand-written JSON Schemas on the wire while centralizing validation in Zod, which is a reasonable design but means the detailed constraints are not visible in the JSON Schema itself. Risk classification (WRITE) is present but not explicitly surfaced in tool output.
Generate an image with Google Gemini or OpenAI (gpt-image-2), save it within the configured output directory, and return the saved file path plus structured metadata. The model name selects the provider: gpt-image*/dall-e* models route to OpenAI, all others to Gemini.
Several input parameters lack descriptions in the schema (outputPath, referenceImages, mask). The rubric requires every parameter to have a description explaining what it controls, format, and constraints. Without descriptions, LLMs cannot reliably infer parameter purpose.
Parameter descriptions do not include format, range, or validation rules. For example, 'referenceImages' accepts PNG/JPEG/WebP and max 5, but the schema description field is empty. LLMs need explicit constraints in parameter descriptions to avoid invalid inputs.
The pass-through JSON Schema validator design keeps constraint details in Zod validation only, not in the JSON Schema advertised to clients. This means clients cannot discover parameter constraints (e.g., max 5 reference images) from tools/list. The rubric baseline expects 100% of A+ tools to expose constraints in schema for discoverability.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 64 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Error responses return isError boolean and errorCode, but do not consistently provide recovery guidance. The rubric requires errors to tell the LLM what to do next. VALIDATION_ERROR includes a formatted message, but INTERNAL_ERROR is generic ('Image generation failed due to an internal server error') without actionable next steps.
The tool description does not clarify which parameters are optional and when they should be used. For example, mask is 'OpenAI only', backgroundMode is 'OpenAI only', but this is not surfaced in parameter descriptions. Conditional parameter availability must be documented per-parameter.