Der MCP-Server hängt Liederstellen direkt in KI-Agenten ein. Claude, Cursor oder ein eigener Agent können im Gespräch ein Lied schreiben und produzieren lassen, ohne dass jemand eine REST-Anfrage von Hand baut.
Stand: 2026-10-10
Schlüssel werden manuell vergeben. Eine kurze Mail mit Vorhaben, erwartetem Volumen und Sprachen genügt, die Freischaltung dauert in der Regel einen Werktag.
Das Model Context Protocol ist ein offener Standard dafür, wie ein KI-Agent externe Werkzeuge und Daten anspricht. Statt einen API-Client zu schreiben, trägt man den Server einmal in die Konfiguration des Agenten ein. Danach kennt das Modell die verfügbaren Werkzeuge und ruft sie selbst auf, wenn das Gespräch es hergibt.
Unser Server bildet dieselben Fähigkeiten ab wie die REST-API: ein Lied schreiben und produzieren lassen, den Stand abfragen, den Liedtext holen, neu generieren lassen, einen Bezahllink erzeugen. Der Unterschied liegt im Zuschnitt. Die Werkzeugbeschreibungen sind so formuliert, dass ein Modell versteht, wann ein Lied überhaupt sinnvoll ist und welche Angaben es vorher einsammeln sollte.
Die Adresse lautet https://mcp.liederstellen.de/mcp. Es ist derselbe Dienst wie unter /api/, nur mit einer anderen Hülle, und er benutzt dieselben Schlüssel. Wer beides parallel betreibt, sieht dieselben Lieder in beiden Welten.
Abgerechnet wird auch hier nur pro fertiggestelltem Lied, aktuell 29,99 €. Werkzeugaufrufe, die nur lesen oder etwas vorbereiten, kosten nichts.
Es gilt derselbe Weg wie bei der REST-API: Schlüssel werden von Hand vergeben. Schreib an songs@maxkuch.com und nenne kurz, welchen Agenten du anbinden willst, was er tun soll und mit welchem Volumen zu rechnen ist.
Du bekommst einen Testschlüssel (sk_test_) und einen Liveschlüssel (sk_live_). Wer schon einen API-Schlüssel hat, braucht keinen zweiten: derselbe Schlüssel öffnet den MCP-Server.
Für Teams, die den Server mehreren Personen zur Verfügung stellen wollen, vergeben wir auf Wunsch mehrere Schlüssel mit gemeinsamer Abrechnung. Dann lässt sich im Nachhinein sehen, welcher Schlüssel welches Lied erzeugt hat.
Der Server spricht MCP über HTTP mit Server-Sent-Events für die Rückrichtung, also den Transport, den die aktuellen Clients standardmäßig verwenden. Ein lokaler Prozess wird nicht gebraucht, es gibt nichts zu installieren.
Die Authentifizierung läuft über denselben Authorization-Header wie bei der REST-API: Authorization: Bearer sk_live_.... Clients, die nur stdio können, erreichen den Server über mcp-remote als Brücke, siehe die Konfiguration für Claude Desktop weiter unten.
Die Protokollversion verhandeln Client und Server beim Verbindungsaufbau. Wir unterstützen die jeweils aktuelle Fassung und die davor, damit ein Client-Update nie zu einem harten Bruch führt.
curl https://mcp.liederstellen.de/health
In Claude Code genügt ein Befehl. Der Schlüssel sollte aus einer Umgebungsvariable kommen und nicht in der Zwischenablage landen.
claude mcp add --transport http songs \
https://mcp.liederstellen.de/mcp \
--header "Authorization: Bearer $SONG_API_KEY"
Claude Desktop liest seine Serverliste aus claude_desktop_config.json. Der Eintrag brückt über mcp-remote auf den HTTP-Transport.
{
"mcpServers": {
"songs": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.liederstellen.de/mcp",
"--header", "Authorization: Bearer ${SONG_API_KEY}"],
"env": { "SONG_API_KEY": "sk_live_..." }
}
}
}
Cursor, Windsurf, Zed und die meisten anderen Clients nehmen die Server-URL direkt entgegen und erlauben eigene Header. Damit entfällt die Brücke.
{
"mcpServers": {
"songs": {
"url": "https://mcp.liederstellen.de/mcp",
"headers": { "Authorization": "Bearer sk_live_..." }
}
}
}
Nach dem Eintragen sollte der Client sieben Werkzeuge anzeigen. Taucht die Liste nicht auf, liegt es fast immer am Header: ein abgelaufener oder falsch kopierter Schlüssel führt zu einer leeren Werkzeugliste statt zu einer sichtbaren Fehlermeldung.
Der Server stellt sieben Werkzeuge bereit. Schreibende Werkzeuge sind als solche markiert, damit Clients sie bei Bedarf bestätigen lassen können.
| Werkzeug | Art | Beschreibung |
|---|---|---|
| create_song | Schreibt und produziert ein Lied. Kehrt sofort mit einer Lied-ID zurück, die Aufnahme folgt wenige Minuten später. Auf Wunsch blockiert der Aufruf, bis die Vorschau steht. | |
| get_song | Liefert den aktuellen Stand eines Liedes samt Status, Vorschaulink und Bezahlstatus. | |
| list_songs | Listet die zuletzt erzeugten Lieder, optional nach Status gefiltert. Nützlich, wenn der Agent nach einer Pause den Faden wieder aufnimmt. | |
| get_lyrics | Gibt den vollständigen Liedtext als Text zurück. Der Text ist immer frei, auch vor der Bezahlung. | |
| regenerate_song | Erzeugt eine neue Fassung, entweder mit demselben Text und neuer Aufnahme oder komplett neu. Bis zu sechs Mal je Lied, ohne Zusatzkosten. | |
| get_checkout_link | Erzeugt einen Bezahllink für ein Lied und gibt ihn als URL zurück, damit der Agent ihn im Gespräch weiterreichen kann. | |
| list_options | Nennt die gültigen Werte für Anlass, Stimmung, Stimme und Sprache. Agenten sollten das einmal je Sitzung abfragen, statt Werte zu raten. |
Lesende Werkzeuge sind idempotent und dürfen vom Agenten ohne Rückfrage aufgerufen werden. create_song und regenerate_song verändern den Zustand und lösen Produktionskosten aus, deshalb melden sie sich beim Client als schreibend an.
Das wichtigste Werkzeug ist create_song. Sein Schema ist bewusst schmal gehalten: drei Pflichtfelder, der Rest optional mit vernünftigen Vorgaben. Je weniger ein Modell entscheiden muss, desto seltener erfindet es Werte.
{
"name": "create_song",
"description": "Write and produce a personalised song. Returns immediately with a song id; the recording is ready a few minutes later.",
"inputSchema": {
"type": "object",
"required": ["occasion", "recipient_name", "details"],
"properties": {
"occasion": { "type": "string", "enum": ["birthday", "wedding", "anniversary", "farewell", "funeral", "christening", "graduation", "christmas", "declaration", "other"] },
"recipient_name": { "type": "string", "maxLength": 80 },
"relationship": { "type": "string", "maxLength": 80 },
"language": { "type": "string", "default": "de" },
"mood": { "type": "string", "enum": ["happy", "warm", "funny", "romantic", "gentle", "epic", "surprise_me"] },
"style": { "type": "string" },
"voice": { "type": "string", "enum": ["female", "male", "duet", "choir", "childrens", "surprise_me"] },
"details": { "type": "string", "minLength": 40, "maxLength": 4000 },
"wait": { "type": "boolean", "default": false, "description": "Block until the preview is ready, at most 10 minutes." }
}
}
}
Der Hebel ist details. Dort gehören konkrete Dinge hinein: Spitznamen, gemeinsame Erlebnisse, Eigenheiten, laufende Witze. Ein Lied aus drei Adjektiven klingt nach drei Adjektiven. Mindestens vierzig Zeichen sind Pflicht, und die Beschreibung des Werkzeugs sagt dem Modell ausdrücklich, dass es nachfragen soll, statt Details zu erfinden.
Das Feld wait steuert den Umgang mit der Wartezeit. Standard ist false: der Aufruf kehrt sofort zurück, der Agent kann weiterreden und später get_song aufrufen. Mit true blockiert der Aufruf, bis die 45-Sekunden-Vorschau steht, höchstens zehn Minuten. Für Gesprächsagenten ist false fast immer die bessere Wahl.
Ohne Angabe von language singt das Lied in de, der Sprache dieser Domain. Alle gängigen europäischen Sprachen und Japanisch sind möglich, die gültige Liste liefert list_options.
Werkzeuge antworten zweigleisig: ein Textblock für das Modell und, wo sinnvoll, structuredContent für den Client. Der Textblock ist so formuliert, dass das Modell ihn dem Nutzer direkt vorlesen kann, ohne ihn zu übersetzen.
{
"content": [
{ "type": "text", "text": "Song sng_3n8Kd2ZpQv for Anna is written. Lyrics below, the 45 second preview is ready." },
{ "type": "resource", "resource": { "uri": "song://sng_3n8Kd2ZpQv/lyrics", "mimeType": "text/plain" } },
{ "type": "resource", "resource": { "uri": "song://sng_3n8Kd2ZpQv/preview", "mimeType": "audio/mpeg" } }
],
"structuredContent": {
"id": "sng_3n8Kd2ZpQv",
"status": "preview_ready",
"preview_url": "https://cdn.liederstellen.de/preview/sng_3n8Kd2ZpQv.mp3",
"paid": false
},
"isError": false
}
Liedtext und Audio kommen als Ressourcenverweise zurück, nicht als eingebettete Daten. Ein Client, der Audio abspielen kann, löst den Verweis auf. Ein Client, der das nicht kann, ignoriert ihn und behält den Text. So wird nie eine MP3-Datei in das Kontextfenster geschrieben.
Bezahlte Lieder tragen in structuredContent zusätzlich audio_url mit der vollständigen Aufnahme. Der Link ist 24 Stunden gültig und lässt sich jederzeit über get_song erneuern.
Neben Werkzeugen stellt der Server Ressourcen unter dem Schema song:// bereit. Clients, die Ressourcen unterstützen, können sie anzeigen oder an das Modell anhängen, ohne ein Werkzeug aufzurufen.
song://sng_3n8Kd2ZpQv the song object as JSON
song://sng_3n8Kd2ZpQv/lyrics the full lyrics as plain text
song://sng_3n8Kd2ZpQv/preview the first 45 seconds as audio/mpeg
song://sng_3n8Kd2ZpQv/audio the full recording, only after payment
Die Liste der verfügbaren Ressourcen ändert sich während der Sitzung, sobald neue Lieder entstehen. Der Server schickt in diesem Fall eine Änderungsmitteilung, sodass Clients ihre Liste aktualisieren können.
Die Ressource audio existiert erst nach der Bezahlung. Ein Zugriff davor ist kein Fehler im technischen Sinn, sondern liefert einen Hinweis samt Bezahllink zurück.
Für die häufigsten Anlässe liegen fertige Prompts bereit. Sie sammeln die Angaben ein, die ein gutes Lied braucht, und rufen danach create_song auf. In Clients, die Prompts unterstützen, erscheinen sie als Schnellbefehle.
{
"name": "birthday_song",
"description": "Collects the five things a birthday song needs and then creates it.",
"arguments": [
{ "name": "recipient_name", "required": true },
{ "name": "age", "required": false },
{ "name": "details", "required": false }
]
}
Verfügbar sind derzeit birthday_song, wedding_song, farewell_song und christmas_song. Wer eigene Abläufe bevorzugt, ignoriert die Prompts einfach und ruft die Werkzeuge direkt auf.
So sieht der Ablauf in der Praxis aus. Der Agent sammelt Details, ruft das Werkzeug auf, liefert Text und Vorschau und nimmt Korrekturen entgegen.
User: My sister Anna turns 34 on Friday. She climbs, she is always late,
and she calls everyone chef. Make her a song.
Claude: [calls create_song with occasion=birthday, recipient_name=Anna,
relationship=sister, mood=funny, details="climbs every weekend,
always ten minutes late, calls everyone chef"]
Done. Here are the lyrics, and the first 45 seconds are playable
right away. Should the chorus lean more on the climbing or more
on the chef thing?
User: More chef.
Claude: [calls regenerate_song with keep_lyrics=false,
note="put the chef running gag in the chorus"]
New version is running, about five minutes.
Bemerkenswert ist der zweite Schritt: eine Neugenerierung kostet nichts und dauert wieder wenige Minuten. Genau dafür ist die Vorschau da, und Agenten sollten sie aktiv anbieten, statt die erste Fassung als endgültig zu behandeln.
Ein Agent kann keine Zahlung auslösen. Er kann nur einen Bezahllink erzeugen und weiterreichen, bezahlt wird im Browser. Das ist bewusst so gebaut: ein Modell soll keine Kaufentscheidung treffen, die ein Mensch nicht gesehen hat.
get_checkout_link liefert eine URL, die 24 Stunden gültig ist. Nach der Zahlung wechselt das Lied in den Status complete, und beim nächsten get_song liegt die vollständige Aufnahme bereit. Der Agent muss nichts abonnieren, ein späterer Aufruf genügt.
Wer die Bezahlung im eigenen System abwickelt und uns nur abrechnet, bekommt auf Anfrage den Direktweg aus der REST-API freigeschaltet. Dann entfällt der Bezahllink und das Lied wird sofort freigegeben.
Der animierte Kurzfilm zum Lied ist kein Werkzeug dieses Servers. Ein Agent kann ihn weder erstellen noch bezahlen, er kann den Nutzer nur auf die Download-Seite seines Liedes hinweisen. Dort wird der Film kostenlos erstellt (etwa 15 Minuten), die ersten 45 Sekunden laufen als Vorschau, freigeschaltet wird er für 19,99 €.
Jeder Schlüssel trägt Berechtigungen. Standard ist Lesen und Schreiben ohne Abrechnungszugriff, was für die meisten Agenten passt.
| Berechtigung | Kennung | Bedeutung |
|---|---|---|
| songs:read | Lieder abfragen, auflisten, Liedtexte lesen. Ohne diese Berechtigung meldet der Server eine leere Werkzeugliste. | |
| songs:write | Lieder erstellen und neu generieren. Löst Produktionskosten aus. | |
| billing | Bezahllinks erzeugen und Zahlungsstatus lesen. Nur nötig, wenn der Agent Links weiterreichen soll. |
Werkzeuge, für die die Berechtigung fehlt, tauchen in der Werkzeugliste gar nicht erst auf. Das ist angenehmer als eine Fehlermeldung mitten im Gespräch, weil das Modell dann nichts anbietet, was es ohnehin nicht kann.
Fehler kommen als normales Werkzeugergebnis mit isError: true zurück, nicht als Protokollfehler. Der Text ist an das Modell adressiert und sagt, was zu tun ist, damit der Agent im Gespräch sinnvoll reagieren kann.
{
"content": [
{ "type": "text", "text": "The song is not paid for yet, so the full recording cannot be handed over. The checkout link is https://pay.liederstellen.de/c/cs_live_8Hd2Kq..." }
],
"isError": true
}
Echte Protokollfehler gibt es nur bei ungültigem Schlüssel, fehlender Berechtigung oder kaputter Anfrage. Alles, was fachlich schiefgehen kann, also fehlende Angaben, unbezahltes Lied, erreichtes Limit, kommt als Text zurück.
Ausbleibende Produktionen laufen nach 15 Minuten in den Status failed und kosten nichts. Der Agent kann danach einfach erneut aufrufen.
Es gelten dieselben Limits wie in der REST-API: 60 Werkzeugaufrufe pro Minute je Schlüssel, höchstens zehn Produktionen gleichzeitig, bis zu sechs Neugenerierungen je Lied. Für höhere Werte reicht eine Mail.
Ein überschrittenes Limit führt nicht zu einem harten Fehler, sondern zu einem Textergebnis mit dem Hinweis, wann es weitergeht. Agenten sollten dann warten statt sofort erneut aufzurufen.
Lieder bleiben 90 Tage abrufbar. Danach verschwinden sie samt Eingaben, und get_song meldet sie als unbekannt.
Die Angaben aus details gehen ausschließlich in die Produktion des jeweiligen Liedes. Wir trainieren damit keine eigenen Modelle. Ein Lied lässt sich jederzeit vorzeitig löschen, dafür gibt es in der REST-API DELETE /v1/songs/{id}.
Am fertigen Lied erhältst du ein nicht exklusives, ausdrücklich kommerzielles Nutzungsrecht. Zur Frage, ob an einer KI-erzeugten Aufnahme ein eigenes Urheberrecht entsteht, gibt es in vielen Rechtsordnungen noch keine abschließende Klärung. Wer darauf angewiesen ist, sollte das vorher prüfen lassen.
Wenn dein Agent Angaben deiner Kunden an uns weitergibt, bist du dafür der Verantwortliche und wir der Auftragsverarbeiter. Einen Auftragsverarbeitungsvertrag bekommst du auf Anfrage.
Der Server läuft auf derselben Infrastruktur wie die REST-API. Wartungsfenster kündigen wir per Mail an die hinterlegte Adresse an, Änderungen an Werkzeugschemata sind ausschließlich additiv.
Kommt ein neues Werkzeug hinzu, schickt der Server eine Änderungsmitteilung. Clients, die darauf reagieren, sehen es ohne Neustart. Bestehende Werkzeuge behalten ihre Namen und ihre Pflichtfelder.
Fragen, höhere Limits, eigene Prompts oder Werkzeuge für einen speziellen Ablauf: songs@maxkuch.com. Nenne bei technischen Problemen die Lied-ID, dann finden wir den Vorgang sofort.
Wer lieber direkt gegen HTTP arbeitet, findet dieselben Fähigkeiten als REST-Schnittstelle unter /api/. Beide Wege teilen sich Schlüssel, Limits und Abrechnung.
Schlüssel werden manuell vergeben. Eine kurze Mail mit Vorhaben, erwartetem Volumen und Sprachen genügt, die Freischaltung dauert in der Regel einen Werktag.