Loading ToolBench
MCP server that expands creative prompts with photorealistic cinematography details, camera sensor profiles, and aesthetic scoring
This MCP server has severe definition quality issues. The single tool 'execute_skill_action' is minimally documented, lacks proper input validation, and the actual implementation is not present in the source code. The mcp_server.py file only prints a JSON status message and does not implement the MCP protocol at all. The tool definition exists only as a reference in the evaluation metadata, not in executable code. The client.py file shows a mock implementation that returns hardcoded responses, which is not a functional MCP server.
Execute photorealistic prompt expansion with aesthetics direction based on camera sensor profile
Tool implementation missing entirely. mcp_server.py does not implement the MCP protocol or handle tool execution. It only prints a static JSON status message. The server cannot actually execute the 'execute_skill_action' tool.
No input schema validation or error handling. The tool accepts raw_creative_idea and camera_sensor_profile, but there is no validation that camera_sensor_profile matches known values like 'HASSELBLAD_MEDIUM_FORMAT_100MP'. Free-form strings invite hallucinated values.
Tool description is vague (44 characters). It says 'Execute photorealistic prompt expansion with aesthetics direction based on camera sensor profile' but does not explain WHEN to use this tool, WHAT prerequisites exist, or what the output structure contains. A production LLM cannot determine when to invoke this tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
Input schema is incomplete. The 'camera_sensor_profile' parameter has a description but no enum constraint listing valid values (HASSELBLAD_MEDIUM_FORMAT_100MP, CANON_RF_MIRRORLESS, etc.). This forces LLMs to guess valid options.
Output schema not documented. The tool returns an object with fields 'director_session_id', 'sensor_profile', 'expanded_cinematic_prompt', 'lighting_and_volumetrics_score_pct', 'photorealism_index_gain_pct', but LLMs cannot see this structure in the source code. No documentation of what these fields mean or how to use them.
No error handling or recovery guidance. If an invalid sensor profile is passed, the tool will fail, but there is no mechanism to tell the LLM what went wrong or what to try next.
Mock implementation in client.py returns hardcoded results. The expand_aesthetics_prompt() method always returns the same response regardless of input. This is not a real tool implementation and cannot be used in production.