Loading ToolBench
MCP server for StarSinger — make a finished AI song with real vocals from a brief (free daily song or a credit), and search/stream the AI music catalog
StarSinger MCP has well-structured tool definitions with clear descriptions and mostly complete schemas. All 4 tools have descriptions (194 - 400+ chars, above baseline 194 avg). Input schemas use Zod with type constraints and descriptions. However, output schemas are not formally documented, responses are described in prose (describeJob function) rather than as structured JSON Schema. The make_song tool has excellent domain-specific guidance (money, consent, polling), but lacks explicit error recovery hints. Parameter naming is clear (brief, lyrics, genre, voice, publicOk) and follows verb_noun conventions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Error handling returns descriptive messages but does not categorize errors as retryable/user-fixable/fatal.
Make a finished song on StarSinger from a short brief: lyrics are written, the music composed, and it is sung with real vocals in about a minute. Say instrumental for no vocals. 49 languages. Money and consent — read before calling: - The account gets ONE FREE SONG A DAY. A free song is PUBLISHED to the public StarSinger feed and the account's artist profile. Tell the user that first; pass publicOk:true only if they agree. - After the free song, a purchased song credit is used (private until the user publishes it). With no credit left, the result carries a checkout link and price — hand it to the user, never invent a price. - No subscription exists. This call returns a job immediately; poll song_status every ~10 s until status is "done" (usually 60–90 s), then give the user the song url.
The account's most recent StarSinger songs with playable MP3 links.
Status of a make_song job: writing → generating → done (with the song's url and MP3), or cap_reached / needs_public_ok / failed.
What the next make_song will spend on this account: today's free song, a purchased credit, or nothing left (with the checkout link and price).
Output schemas not formally documented. Responses are described in prose (describeJob function) rather than as structured JSON Schema. LLMs cannot reliably parse unstructured text responses or plan downstream tool calls.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). make_song is destructive (spends credits) but lacks destructiveHint. song_status and my_songs are read-only but lack readOnlyHint. Agents cannot infer safety/retry semantics.
Error handling lacks categorization. Errors are returned as prose messages (cap_reached, needs_public_ok, failed) but do not explicitly state whether they are retryable, user-fixable, or fatal. Agents cannot determine next action.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
wallet tool description is vague (60 chars). Does not explain when to call it, what it returns, or how to interpret the response. Agents may not know to call it before make_song.
my_songs limit parameter lacks minimum/maximum constraints in description. Zod schema has max(50) but description does not state the range, forcing LLMs to infer from schema alone.