Find AI songs in 24 languages, start a custom song on SongUp AI, and find browser audio tools.
Scored across 3 tools
Each tool has a clearly distinct purpose: finding audio tools, finding pre-made songs, and preparing a custom song maker link. The descriptions explicitly clarify boundaries, such as pre-made library tracks vs. user-created songs, so there is no overlap.
The names are all snake_case, but they mix verb_noun (find_audio_tool, find_songs) with a non-standard pattern (start_custom_song). The first also redundantly includes 'tool', making the convention less predictable.
With only 3 tools, the set feels thin for a platform offering audio processing and song generation. It is borderline, as the tools cover key discovery functions but leave little room for direct actions.
The surface covers discovery of audio tools and songs, plus a custom song link, but lacks direct operations like actually processing audio, creating songs, or managing user content. Notable gaps exist for a server with AI audio capabilities.
Finds the SongUp AI browser audio tool for a task the user describes, such as splitting a song into vocals and music, removing vocals for karaoke, making a mashup of two songs, removing background noise, mastering a track, finding chords, converting audio to MIDI, auto-tune or editing audio. Returns the matching tools with what each one does and a link to open it on songupai.com, where the user uploads their audio. This tool does not process audio itself.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What the user wants to do with their audio, in a few words (e.g. "separate vocals", "mashup maker", "audio editor"). |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| task | Yes | |
| tools | Yes | |
| matched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish it as a safe, read-only, idempotent, non-open-world lookup, so the bar is lower. The description still adds meaningful behavior beyond that: it returns matching tools with descriptions plus an opening link, and it explicitly disclaims that it performs no audio processing — the key trait an agent needs to avoid expecting an action result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by the return behavior and the no-processing disclaimer. The long example enumeration is slightly heavy but each item plausibly improves matching for this discovery tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, yet the description still usefully summarizes what comes back (matching tools, what each does, a link) and where the user continues the workflow. Combined with 100% schema coverage and clear safety annotations, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'task' parameter is already documented with examples, so the schema carries the load. The description's task list overlaps the schema examples and adds thematic breadth but no new syntax, format, or constraint guidance, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Finds the SongUp AI browser audio tool') and enumerates concrete task categories (stem splitting, karaoke, mashup, noise removal, mastering, chord detection, MIDI conversion, auto-tune), making the scope unmistakable. This is clearly distinguishable from siblings like find_songs and start_custom_song, which concern songs rather than AI audio tooling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear trigger context — use it when the user 'describes' an audio task — and adds an explicit when-not caveat: 'This tool does not process audio itself,' directing actual work to songupai.com. It does not explicitly route to sibling tools, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds ready-made AI songs from the SongUp AI library and returns each one with a direct link to its audio (MP3). Use it when the user wants to hear AI songs or example songs in a language, genre, mood or for an occasion (for example "an Arabic love song", "Hindi lo-fi", "upbeat birthday pop"). Songs are pre-made library tracks, not made from the user's own words; for a song from their own idea use start_custom_song.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many songs to show (default 5). | |
| query | No | Optional genre, mood or occasion to match, in a few words (e.g. "romantic", "lo-fi", "birthday", "rap"). | |
| language | No | Language the songs are sung in, or "Instrumental" for songs without vocals. Defaults to English. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| query | Yes | |
| songs | Yes | |
| language | Yes | |
| createUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the return (each song comes with a direct MP3 link) and the nature of the results (pre-made library tracks, not custom), which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by clear usage guidance and a clarifying contrast with a sibling tool. Every sentence earns its place, and no information is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional parameters, an output schema, and full annotation coverage, the description is complete. It covers purpose, usage, return format, and the key distinction from custom song generation, leaving nothing essential for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already well documented in the schema with descriptions and examples. The description provides matching examples (language, genre, mood, occasion) but adds no new semantic detail beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (finds) and resource (ready-made AI songs from the SongUp AI library) and notes the return format (direct MP3 link). It clearly distinguishes this tool from start_custom_song, but does not differentiate from the other sibling find_audio_tool, leaving a small ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Use it when the user wants to hear AI songs or example songs…') and when-not guidance ('not made from the user's own words; for a song from their own idea use start_custom_song'). However, it omits any reference to the sibling find_audio_tool, so the alternative routing is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepares a link that opens the SongUp AI song maker on songupai.com with the user's song idea already filled in, so they can turn it into a full song with vocals there. Use it when the user wants a song made from their own idea, story, names or lyrics (birthday, anniversary, love song, etc.). Nothing is created or charged by this tool; the song is made on songupai.com, which needs a free account.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | What the song is about, in the user's words: occasion, names, story, mood and style. Up to 500 characters. | |
| language | No | Language to sing in, if the user said one. |
| Name | Required | Description |
|---|---|---|
| idea | Yes | |
| kind | Yes | |
| language | Yes | |
| createUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds genuinely new context: 'Nothing is created or charged by this tool' and the destination 'needs a free account,' which matters for an agent setting user expectations. It stops short of describing the returned link's lifecycle or expiry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what it does, when to use it, and the crucial no-cost/external-account caveat. The key distinction (it prepares a link, it doesn't make the song) is front-loaded rather than buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the link's exact shape need not be re-explained, and annotations cover the safety profile. The description closes the remaining gaps an agent would care about — no charge, external site, free account required. Only the fate of the generated link (persistence, expiry) is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'idea' and 'language' are already documented in the schema, and the enum of 24 languages is fully enumerated there. The description only alludes to the idea parameter via 'the user's song idea already filled in' and says nothing about language handling. Baseline 3 is appropriate when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it 'prepares a link that opens the SongUp AI song maker on songupai.com with the user's song idea already filled in.' The purpose is unambiguous and clearly a creation-path tool rather than a lookup. It does not explicitly name the siblings (find_songs, find_audio_tool) to differentiate itself, so it lands short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it when the user wants a song made from their own idea, story, names or lyrics (birthday, anniversary, love song, etc.)' gives concrete trigger conditions with examples. It lacks an explicit exclusion or a named alternative for cases like finding an existing song, so the guidance is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_audio_toolfind_songsstart_custom_songAI music studio: song generation with vocals, covers, stems, voice conversion, mastering, editing.
Make a finished AI song with real vocals from a brief, or search and stream StarSinger's AI catalog
Audio AI tools: text-to-speech, voice cloning, music generation, stem separation, transcription.
AI image, video and audio tools: generate, edit, face swap, upscale, remove backgrounds, make video.
Add one secure layer between your agents and this server.
