Loading ToolBench
RunAPI Luma MCP server for video generation: create tasks, poll results, and check pricing across 1 model from Claude Code, Codex, Cursor, and VS Code.
Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling guidance. get_task has optional parameters with minimal context; check_pricing lacks clarity on defaults and return structure. No tool annotations, no error recovery guidance, and descriptions are generic. Schemas are present but sparse, parameters lack detailed constraints or format specifications. This server falls in the 'poor' range typical of community MCP implementations.
Look up RunAPI pricing for the luma model line.
Fetch the current status and latest result payload for a luma task.
Parameter descriptions lack actionable constraints. 'action' param in both tools described only as 'Asynchronous endpoint' or 'Endpoint name' with no enum, format, or valid value guidance. LLMs cannot infer valid values.
No error recovery guidance. Tools return generic errors (e.g., 'friendlyError(error)') without actionable next steps. LLM cannot determine if error is retryable, user-fixable, or fatal.
Output schemas not documented. Neither tool specifies what fields the response contains. LLMs cannot plan downstream calls or extract required data (e.g., does get_task return task_id, status, result, timestamps?).
Default parameter behavior unclear. get_task's 'action' defaults to 'the line's only asynchronous endpoint' but this is not validated or documented in the schema. If multiple endpoints exist, the default is ambiguous.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only but this is not declared in the schema, forcing LLMs to infer safety from descriptions alone.