MCP server for PhotoShoot AI operations with support for image generation, editing, batch processing, and variations across multiple AI providers (WaveSpeed, Nano Banana, OpenAI, PhotoShoot API, FAL, Stability)
This MCP server has fundamental definition quality gaps. While 6 tools are defined with basic schemas and descriptions, several critical issues prevent it from reaching production quality: (1) tool names lack clear action verbs (photoshoot_generate vs. generate_photoshoot), (2) parameter descriptions are sparse or missing entirely, (3) output schemas are completely undocumented, (4) error handling provides no recovery guidance, (5) the edit tool's 'edits' parameter is underspecified with unclear nested properties. The schemas that are present use proper JSON Schema format with enums, which is positive, but are insufficient without complete documentation. Average tool score across 6 tools: 42/100.
Batch process multiple images
Edit and enhance photoshoot images using AI
Generate AI photoshoot images using WaveSpeed, Nano Banana, OpenAI, or PhotoShoot API
Get available photoshoot templates and styles
Upscale images to higher resolution
Generate variations of an existing image
Tool names do not follow verb-first convention. 'photoshoot_generate', 'photoshoot_edit', 'photoshoot_template', etc. should be 'generate_photoshoot', 'edit_photoshoot', 'get_templates'. This makes tool selection ambiguous for LLMs, names should lead with the action verb so agents can infer intent from the name alone.
Output schemas are completely undocumented. No tool explicitly declares what fields it returns, what their types are, or how to use the result in downstream calls. This forces LLMs to guess at response structure and prevents proper tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Parameter descriptions are minimal or absent. 'reference' in photoshoot_generate just says 'Reference image URL or base64', but what is a 'reference image' used for? How does it affect the generation? The 'edits' object in photoshoot_edit has nested properties (lighting, background, retouch, enhance) with no descriptions at all, making it impossible for LLMs to know which properties to set and in what format.
No error handling or recovery guidance. Tools do not document what happens on failure (e.g., what if the image URL is unreachable? what if a batch operation partially fails?), what errors are retryable, or what the LLM should do next. Error responses will be opaque to agents.
The 'edits' parameter in photoshoot_edit is an object with optional nested properties but provides no type information or constraints for those properties (lighting, background, retouch, enhance). LLMs cannot determine: (a) are these free-form strings or enums? (b) what values are valid? (c) is 'retouch' a boolean or a string? This will cause malformed requests.
Pagination and result limits are not addressed. Tools like photoshoot_batch and photoshoot_template that return multiple items do not declare max result limits, pagination support, or offset/limit parameters. Large results could exhaust the LLM context window without guidance.
Tool descriptions are generic and lack guidance on when to use each tool. 'Generate AI photoshoot images...' does not explain the difference between generate, variations, and upscale, or when an LLM should choose one over another. Descriptions should answer: What does it do? When should I call this instead of a similar tool?
The 'provider' parameter with 'auto' default is underspecified. What does 'auto' actually do? Does it select based on image complexity, cost, latency, or availability? LLMs cannot predict the behavior when they choose 'auto', making error handling and cost estimation impossible.