OpenAI-compatible image generation with MCP support using Cloudflare Workers AI
Three tools with complete schema definitions and descriptions, but inconsistent quality across naming and output documentation. run_model has a well-structured input schema with proper type definitions and descriptions for all parameters, making it clear and LLM-friendly. list_models and describe_model have adequate schemas but minimal parameter documentation. All tools have descriptions, but they vary in actionability. The server lacks documented output schemas for all tools, making it harder for LLMs to plan downstream actions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, which is a missed opportunity for clarity on tool safety properties.
Get detailed information about a specific image generation model. Returns full model configuration including parameters, limits, supported tasks, and capabilities.
List all available image generation models supported by Cloudflare Workers AI. Returns model metadata including capabilities, parameters, and constraints.
Generate or edit images using a specified Cloudflare Workers AI model. Supports text-to-image generation (taskType='generations') and image editing/inpainting (taskType='edits'). Routes to appropriate generation service based on task type.
No output schemas documented for any tool. LLMs cannot plan downstream actions (e.g., extract model IDs from list_models to pass to run_model) without knowing the response structure. Rubric requires documented return types (100% of A+ tools have them). Critical for tool composition.
run_model violates single-responsibility principle. It performs two distinct operations (text-to-image generation and image editing/inpainting) controlled by taskType enum. This allows agents to compose them cleanly and LLMs to reason about each action independently.
Tool naming uses generic verbs ('run', 'list', 'describe') which per the rubric reduce clarity. Baselines show 90% of A+ tools start with action verbs; these are present but imprecise. Suggested: 'generate_image', 'edit_image', 'list_available_models', 'get_model_details'. Generic names like 'run' and 'describe' increase LLM reasoning overhead.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
cf_params parameter (run_model) is loosely typed as object without documented subfields. Rubric requires clear parameter constraints. Acceptable values (steps, seed, guidance, negative_prompt, strength) are listed in the description but not as schema constraints. An LLM cannot validate these without additional reasoning.
list_models filter parameter lacks constraint documentation. Is it case-sensitive? Substring match? Regex? Rubric requires explicit format/pattern constraints in descriptions. Current description is too vague ('Optional filter by model name or provider').
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). run_model modifies state (generates/stores images), requiring idempotent and destructive properties to be inferred by LLM. list_models and describe_model should be marked readOnly. Per 2026-07-28 spec, these annotations improve agent decision-making.
Error handling documentation is missing. Rubric requires error responses to guide LLM recovery ('User not found. Try search_users()...'). No guidance provided on what errors run_model, list_models, or describe_model can return, how to interpret them, or what to try next.
No parameter relationship documentation. run_model taskType='edits' requires 'image' and optionally 'mask', while taskType='generations' ignores them. Rubric states: 'When one parameter's valid values depend on another, document this in both parameter descriptions.' Current description does not formalize these dependencies.
list_models returns 'model metadata' but output structure is undocumented. Cannot determine if responses include: model IDs, capabilities, parameter ranges, supported image sizes, etc. Breaks tool composition (cannot extract model_id to pass to describe_model or run_model without guessing response format).