Loading ToolBench
vibe-mcp has three tools with basic descriptions and schemas, but significant gaps prevent higher scores. All three tools have input schemas visible in src/index.ts with type definitions and parameter descriptions. However, tool names lack clarity (start_vibe_session vs generate_music; stop_vibe_session is clear), descriptions are brief (under 200 chars, acceptable baseline), and critical output schemas are completely undocumented. The session state management is visible but not exposed in tool outputs. Error handling is minimal, no recovery guidance, no error categorization, no actionable error messages. Security is weak: API keys are injected via environment variables (good), but no permission gates or audit trails exist. Tool composition is reasonable (three focused tools), but the lack of output schema documentation breaks chaining, an LLM cannot know what fields to extract from responses.
Generates more music in the current vibe session based on new code context or genre specifications. Only works if a session is already active.
Starts a new music generation session based on the current code context. The user might say they want to vibe or to create a soundtrack. The user can also specify a programming language for the code or a music genre preference.
Stops the current active vibe session and stops all audio playback.
Tool naming lacks action clarity. 'start_vibe_session' is acceptable, but 'generate_more' is vague, does it append to an existing track, replace it, or queue separately? Compare against baseline verb patterns: get_, create_, update_, delete_, search_, list_, send_. Consider 'append_to_vibe' or 'extend_current_vibe' for the second tool.
Output schemas are completely undocumented. The code shows tools return a 'prompt' field (line ~170: 'return { prompt }') for music generation tools, and presumably boolean/status for stop_vibe_session, but no type information is provided to the LLM. LLMs cannot know what fields to extract or how to chain tools without documented output schemas. Critical for composition.
No error handling or recovery guidance. The code logs errors to console (e.g., line ~169: 'console.error("Error in background music generation:", error)') but returns nothing to the LLM to guide recovery. If generation fails, the agent has no next step. Implement pattern:recovery-guide, errors must say 'Call X to recover' or 'This is retryable.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Missing parameter descriptions for 'mode' parameter. The 'mode' parameter exists in input schemas for start_vibe_session and generate_more (described as 'The optional mode to generate music in (e.g., \'instrumental\', \'lyrical\')'), but no explanation of why a user would choose one over the other, what the default is if omitted, or whether the mode persists across calls.
Tools expose implementation details (API key fallback logic, DiffRhythm/StableAudio generator selection) that should be opaque. Users say 'generate music for this code,' not 'use Stability AI in instrumental mode or PiAPI Udio in lyrical mode.' Tool descriptions omit prerequisites like 'API keys must be configured' and fallback behavior.
No pagination or result limits documented. If audio generation returns a URL, the description does not state the expected format (HTTP URL? File path?) or what happens if generation times out (timeout is likely >30s given async background execution). Tools that call external APIs must have explicit timeouts and retry guidance.