Professional AI-powered book series generation with automated publishing, image generation via MCP servers, and Amazon KDP integration
This server has critical definition quality gaps. While 9 tools are declared, most lack proper parameter descriptions and comprehensive schemas. Tools like 'generate_image' and 'generate_character_image' have bare descriptions (e.g., 'Generate an image from a text prompt using DALL-E 3 via MCP') that fail to explain WHEN to use each tool vs. alternatives, WHAT the side effects are, or HOW to use parameters. Parameter schemas show type declarations but descriptions are minimal or absent. The server conflates similar tools (dalle3_generate_image vs midjourney_generate_image, dalle3_get_generation_id vs midjourney_get_generation_id) without clear naming distinction (missing verb prefix clarity). Output schemas are not documented, responses are inferred, not specified. Error handling is absent from descriptions. Tool composition has redundancy: get_available_tools and get_server_info are utility introspection tools, not domain tools, suggesting design confusion. Based on the code snippet provided, schemas are declared but parameter descriptions are sparse or missing entirely. This aligns with typical community-server patterns (median ~45-55), functional but not production-grade.
Analyze consistency across multiple character images
Generate an image using DALL-E 3 with character consistency support
Get the generation ID for a DALL-E 3 image (not supported by API)
Generate a character image with consistency features
Generate an image from a text prompt using DALL-E 3 via MCP
Get list of available tools from the MCP server
Get information about the connected server
Parameter descriptions are missing or trivial. The 'style_options' parameter in generate_character_image is declared as 'object|null' with description 'Style parameters for the image', this does not explain WHAT style parameters are accepted, WHAT formats are valid, or WHEN to use them. LLMs cannot infer the structure.
Output schemas are not documented. No tool declares what fields it returns, their types, or their meanings. Without documented return types, LLMs cannot plan downstream tool calls or extract the right data. This violates the pattern baseline (100% of A+ tools have documented return types).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
Generate an image using Midjourney with character reference (cref) features
Get the character reference for a Midjourney image
Tool descriptions are under 50 characters and lack actionable context. 'Generate an image from a text prompt using DALL-E 3 via MCP' (53 chars) states WHAT but not WHY or WHEN. There is no guidance on when to call generate_image vs generate_character_image vs dalle3_generate_image. LLMs cannot disambiguate between overlapping tools.
Naming lacks verb clarity. 'get_generation_id' is vague, does it retrieve, compute, or extract an ID? For dalle3_get_generation_id, the description says '(not supported by API)', if unsupported, why does the tool exist? This creates confusion. Similarly, 'analyze_character_consistency' is passive; 'compare_character_images' would be clearer.
Redundant and overlapping tools signal design confusion. Three separate tools generate images (generate_image, dalle3_generate_image, midjourney_generate_image), yet it is unclear when to call each. The descriptions do not explain differences in API, cost, quality, or use case. LLMs will struggle to choose the right one.
No error handling guidance. Descriptions do not explain what happens on failure (e.g., 'If the image generation times out, retry with a simpler prompt' or 'If the character reference ID is invalid, call analyze_character_consistency to validate'). Error responses will not guide LLMs toward recovery.
Utility tools (get_available_tools, get_server_info) are marked as READ_ONLY but are not domain-specific. They belong in server capabilities/metadata, not in the tool list. Including them wastes token budget and distracts LLMs from the actual domain (book series generation via character image consistency).
Parameter 'reference_id' in generate_character_image has description 'Reference ID for character consistency', this is circular and does not explain what value to pass, how to obtain it, or what format is expected. Should it be a UUID, a character name, or an image file path?