Skip to main content
Glama

nanoodle

by io.github.nanoodlecom

sing

One idea fans out to three LLMs — lyrics, a matching style, and a negative prompt of what to avoid — then a music model sings it. First-click is a Fushimi Inari 3:17am torch song: the rusted snack … text:Song Instructions -> text:Bands -> text:Style System Prompt -> llm -> join×2 -> llm -> join -> llm -> music; returns audio (mureka-v9.5/generate-song) saved to disk (file path in result). Runs on NanoGPT — $0.58 deposit per call, paid in Nano (XNO) — settles at actual model cost + 20%, change returned; no account needed; last run $0.0497, ~1m 56s.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
BandsNoText; default: "Bands liked:\nPortishead, Massive Attack, Tricky"; optional
_payment_idNoPayment id from this tool's previous payment-required response. Phase 3 only: after /x402/watch closes with status paid, call again with the same arguments plus this id to open the RESULTS stream. Do not pass it while payment is still pending — monitor the watch SSE first.
System_promptNoSystem prompt; default: "You are an award-winning songwriter. Write only the lyrics — no title, no commentary, no explanations.\nPrinciples:\n- ..."; optional
System_prompt_2NoSystem prompt; default: "Negate the style — what would go poorly, the worst you can imagine. No preamble or postamble."; optional
Song_InstructionsNoText; default: "Write a late-night 90s trip-hop torch song set under the last lit vermillion torii at Fushimi Inari, 3:17am. A rusted..."; optional
Style_System_PromptNoText; default: "You invent a musical style that fits the given lyrics. Reply with only the style, richly descriptive — no commentary...."; optional

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • changedInput schema / properties / Bands / description
      Previous value: -"Text; default: \"Bands liked:\\nSoundgarden, XX\"; optional"New value: +"Text; default: \"Bands liked:\\nPortishead, Massive Attack, Tricky\"; optional"
    • changedInput schema / properties / Song_Instructions / description
      Previous value: -"Text; default: \"Write a wistful 90s trip-hop track about the singularity.\"; optional"New value: +"Text; default: \"Write a late-night 90s trip-hop torch song set under the last lit vermillion torii at Fushimi Inari, 3:17am. A rusted...\"; optional"
    • changedInput schema / properties / System_prompt_2 / description
      Previous value: -"System prompt; default: \"Negate the style - what would go poorly,  the worst you can imagine. No preamble or postamble.\"; optional"New value: +"System prompt; default: \"Negate the style — what would go poorly, the worst you can imagine. No preamble or postamble.\"; optional"
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full behavioral burden. It discloses the multi-LLM pipeline, output format (audio file path), payment model ($0.58 deposit in Nano, actual cost +20%), no-account requirement, and typical runtime/cost. This is strong transparency, though it omits the explicit two-phase payment flow that the schema hints at via _payment_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and meandering, mixing a useful pipeline diagram with a long illustrative default prompt ('First-click is a Fushimi Inari 3:17am torch song: the rusted snack …') and cost details. It is not surgically structured; the example and trivia dilute the operational guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no output schema, the description conveys the workflow, output location, cost, runtime, and payment requirements. It is largely complete, though the precise payment-phase mechanics are only visible in the _payment_id parameter description rather than the top-level description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds some context by mapping Song Instructions, Bands, and Style System Prompt into the workflow, but it does not add much detail beyond what each parameter's schema description already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: it takes an idea, fans it out to three LLMs for lyrics, style, and negative prompt, then uses a music model to sing it. It names the output (audio saved to disk) and is easily distinguished from sibling image-generation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied: generate a song from an idea, with a specific default Fushimi Inari torch song. However, there is no explicit statement of when to use this tool versus alternatives, and no exclusions or conditions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All nanoodle toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation3/5

Most tools target clearly different media or output types, but several image-generation tools are near-variants (alishan-fog-dawn vs. night-market-postcard; combine-images vs. edit-a-photo). The descriptions are specific enough to recover, but the name-level distinction is weak.

Naming Consistency3/5

All names share lowercase kebab-case, but the semantic pattern is mixed: some are verb phrases (combine-images, render-a-mockup), some are nouns (favicon, character-sprites), and some are opaque demo titles (alishan-fog-dawn, fibo-studio-still, deslop). Readable overall, but not predictable.

Tool Count4/5

At 14 tools the count is reasonable for a creative-media demo server and each major modality has at least one representative. Several tools are close variants of one another, so the set feels slightly padded rather than tightly scoped.

Completeness3/5

The set covers image, video, audio, text, avatar, sprite, and mockup generation, which is broad coverage. However, there is no generic text-to-image or arbitrary photo-editing tool, only themed demos, so general creative requests would hit gaps.

Resources