MCP server for LipDub 2 — make a person in a video appear to speak a different audio track, with matched lip movement.
LipDub MCP demonstrates solid tool design with clear naming, comprehensive descriptions, and well-structured schemas. All 5 tools follow verb_noun convention (check_connection, create_render, get_render, wait_for_render, list_renders). Descriptions are detailed (100-200 chars typical) and explain WHAT, WHEN, and consequences. Input schemas are present with typed parameters and descriptions. However, output schemas are not documented in the source, and error handling lacks recovery guidance. Tool composition is clean, each tool has one responsibility. The server includes helpful instructions and prompts, showing good UX design.
Verify the API key works and identify the account
Start a render to make a person in a video appear to speak a different audio track
Get the current status of a render without waiting
List recent renders on the account
Wait for a render to complete, polling periodically
Output schemas not documented. LLMs cannot infer what fields to expect from tool responses (e.g., what does lipdub_create_render return? Is it {render_id, status, ...}?). This forces agents to guess and risks downstream tool call failures.
Error handling lacks recovery guidance. Tool descriptions do not explain what to do if a render fails, API key is invalid, or rate limits are hit. Errors should guide the LLM to next steps (e.g., 'If auth fails, call lipdub_check_connection').
lipdub_create_render lacks dry-run or confirmation mechanism. The tool is IRREVERSIBLE (spends credits) but has no way to preview cost or confirm before execution. A confirm_spend parameter exists but no guidance on what happens if false.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
lipdub_list_renders pagination incomplete. The 'limit' parameter exists but no 'offset', 'cursor', or 'total_count' documented. Large result sets could blow context window without proper pagination guidance.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint declared. Clients cannot infer which tools are safe to retry or which modify state without reading descriptions.