Loading ToolBench
OpenAPI-backed MCP server wrapping the Magic Hour API for creating and editing images, video, and audio
Magic Hour MCP demonstrates solid definition quality with well-structured tool schemas and detailed descriptions. All 7 tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (wait_for_*, fetch_*, ping). Descriptions are substantive (100-300+ chars) and include actionable guidance on proper URL handling. However, there are notable gaps: no output schemas documented, no error recovery guidance beyond URL handling warnings, missing per-parameter constraints (min/max for numeric params), and no enum declarations for constrained values. Tool definitions are explicit and visible in openapi_server.py, enabling confident scoring. The server demonstrates awareness of common LLM pitfalls (URL manipulation, signed token expiration) through explicit description warnings.
Fetch an audio `downloads[n].url` from a completed audio project and return it as inline MCP audio content for compatible clients. Pass the exact full signed URL from `downloads[n].url` without trimming query parameters; `expires_at` is separate metadata, not part of the URL.
Fetch an image `downloads[n].url` from a completed image project and return it as inline MCP image content for compatible clients. Pass the exact full signed URL from `downloads[n].url` without trimming query parameters; `expires_at` is separate metadata, not part of the URL.
Fetch a video `downloads[n].url` from a completed video project and return it as an embedded MCP binary resource for compatible clients. Pass the exact full signed URL from `downloads[n].url` without trimming query parameters; `expires_at` is separate metadata, not part of the URL.
Check that the Magic Hour MCP server is reachable.
Poll an audio project until it completes, errors, is canceled, or times out. Returns the final project JSON and, when complete, attempts to inline audio downloads for Inspector or compatible clients. Returns sanitized download fields. Use `exact_download_urls[n]` or `downloads[n].url` exactly as returned; do not shorten it, remove query parameters, or append expiration metadata.
No documented output schemas for any tool. LLMs cannot plan downstream calls or extract response fields without knowing what structure to expect.
Numeric parameters (poll_interval_seconds, timeout_seconds, max_inline_downloads, max_bytes_per_download, max_bytes) lack min/max constraints. LLMs could pass invalid values like negative timeouts or zero intervals.
No error recovery guidance. Tools describe what they do but not how to handle failure modes (e.g., what to do if polling times out, network failure during fetch, or project errors).
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2025-06-18+ | v2 |
Poll an image project until it completes, errors, is canceled, or times out. Returns the final project JSON and, when complete, attempts to inline image downloads for Inspector or compatible clients. Returns sanitized download fields. Use `exact_download_urls[n]` or `downloads[n].url` exactly as returned; do not shorten it, remove query parameters, or append expiration metadata.
Poll a video project until it completes, errors, is canceled, or times out. Returns sanitized download fields. Use `exact_download_urls[n]` or `downloads[n].url` exactly as returned; do not shorten it, remove query parameters, or append expiration metadata.
Parameter descriptions for include_inline_downloads and max_inline_downloads lack context on when to set these. What triggers inlining? When should max be higher/lower? This creates ambiguity for LLM parameter selection.
No idempotency guidance. Are wait_for_* tools safe to retry? Are fetch_* tools idempotent if called multiple times with the same URL? This matters for agent retry logic.