A tool to generate cover images using an external API (Midjourney/TTAPI). Supports image creation, task management, variations, upscaling, and image description via API.
This server exhibits significant quality gaps across naming, descriptions, and schema documentation. While 7 tools are present with basic parameter definitions, most lack production-grade rigor. Tool names are inconsistent in verb usage (list_* and create_* are clear, but describe_image and perform_action are vague). Descriptions exist but are minimal, many under 100 characters and several in Chinese, which limits LLM understanding in English-primary contexts. Parameter descriptions are sparse: 'concept_key' lacks context, 'action_code' does not enumerate valid values, and 'image_path' does not specify supported formats. Output schemas are not documented anywhere in the provided source. Error handling and recovery guidance are absent. Security concerns are unaddressed (file paths in parameters risk traversal; no mention of API key injection). The server relies on file-based task storage (image_gen_mcp/apps/cell_cover/utils/file_handler.py) without clear transaction semantics or atomic guarantees. Overall, the server reads as a proof-of-concept rather than a production-ready agent tool.
创建新的 Midjourney 图像生成任务。
根据上传的图片生成相关提示词。
列出所有可用的创意概念及其键。
列出任务列表。
列出指定创意概念的所有可用变体。
对现有任务执行操作(如 Upscale, Variation, Reroll)。
查看任务的详细信息。
Output schemas not documented. No tool returns a structured schema definition visible in source code. LLMs cannot predict return types, fields, or pagination structure.
Enum constraints missing for constrained parameters. 'action_code' accepts 'upsample1-4, variation1-4, reroll' but no enum is declared; 'mode' accepts 'relax, fast, turbo' (or 'fast' for perform_action) with no enum; 'aspect_ratio', 'style', 'version', 'quality' are free-text. LLMs will hallucinate invalid values.
Descriptions are vague or minimal. 'perform_action' (45 chars) gives no context on what operations succeed, what side effects occur, or recovery paths. 'list_tasks' (13 chars, '列出任务列表') is too short and in Chinese. Descriptions under 50 chars cannot guide LLM selection. Baseline is 194 chars average.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Parameter descriptions are incomplete or missing context. 'action_code' does not enumerate valid codes; 'concept_key' does not explain when to use it or how to discover available keys; 'image_path' does not specify file format, size limits, or URL vs local path handling; 'wait' (boolean, no description) is unclear, does it block? Does it poll?
No error handling or recovery guidance. No tool documents what errors can occur, what causes them, or how to recover. E.g., 'create_image' does not mention rate limits, quota errors, or invalid prompt lengths. Agents have no guidance on retry logic or fallback.
Naming ambiguity: 'perform_action' is vague. Does it execute, queue, schedule, or preview the action? Compare 'upscale_image', 'create_variation', 'reroll_image', each name clarifies the actual operation. 'perform_action' forces LLM guessing.
File path parameter in 'describe_image' (image_path) and local file storage in view_task (task_id as filename) create path traversal risks. No validation or sanitization visible. LLMs can be tricked into reading arbitrary files.
Pagination missing from list tools. 'list_concepts', 'list_variations', and 'list_tasks' accept a 'limit' parameter but do not document offset, cursor, total_count, or next_page behavior. Large result sets will blow context windows.
Dependency on external Midjourney API not mentioned. 'create_image' and 'perform_action' delegate to Midjourney but do not document rate limits, latency, or async behavior. Users/agents do not know if calls are blocking or queued.