Privacy policy
MCP Music Studio is maintained by Xule Lin. This policy describes the hosted service at music-studio.linxule.com (also available at mcp-music-studio.linxule.workers.dev) and the optional local server. Updated October 4, 2026.
Playing and editing music
The hosted MCP server receives the arguments sent by your MCP client: notation or code, titles, playback settings, and reference or harmony questions. It processes those arguments to provide the requested tool result. Playback does not save your composition in the service's share database. A local installation processes playback locally.
Short pieces may be included in a self-contained browser link. The link contains the composition in an encoded, not encrypted, form. Creating this link does not upload a local composition. Opening it sends the URL and its contents to the hosted service; the URL can also appear in browser history, host conversation records, previews, and infrastructure logs. Anyone you give the link to can decode or play it. Do not put secrets or sensitive information in music code or titles.
Music synthesis, editing and recording run in your browser or MCP host. Audio and MIDI exports are created there and handed to that host or downloaded to your device; the Music Studio server does not receive the exported audio or MIDI. Your MCP host has its own data policies. Using “Send to chat” sends your current edited music to that conversation. The widget can also send playback/error status to the host so the assistant knows whether a pattern worked.
Creating a stored share
The separate create-share-link tool, or an explicit POST /share request, uploads the supplied piece and its playback settings to Cloudflare Workers KV. Anyone holding the resulting link can view and play it without an account. Links are not private storage or authentication, and the service asks search engines not to index player pages.
Stored shares expire 30 days after creation. Creating an identical share again refreshes that period. Older versions of the server also created these shares automatically for long playback inputs; those existing links retain their expiry. Expiry does not remove copies held by recipients, conversations, browser history or caches. There is no account-based share library or self-service deletion control. Contact the maintainer to request removal; do not post a sensitive link in a public issue.
Spoken lines (say)
When a pattern calls say(text), the player requests /tts from the hosted service with that text and the chosen voice in the URL. The service sends the text to Cloudflare Workers AI (the Deepgram Aura model Cloudflare hosts) to synthesize speech, and caches the resulting audio in Cloudflare Workers KV for 30 days under a hash of the text and voice, so the same line is usually not synthesized again (two requests at the same moment, a failed cache write or an expired entry can synthesize it again). The text itself is not stored in the cache key, but it is in the request URL, so it can appear in operational logs and browser history like any other URL. Lines are limited to 240 characters, voices are a fixed list of synthetic voices (no voice cloning), new syntheses are rate-limited per IP address (IPv6 by /64 network) per minute, and they count against a monthly spending budget for speech (with a daily share of it). The budget records only amounts spent per day and month, not text, voices or addresses. The audio is served with a one-year public cache header, so browsers and caches between you and the service may keep a copy. Do not put sensitive information in spoken lines. This happens with the local server too, because the player fetches speech from the hosted service.
Live sessions
A live session is opened only when the AI asks for one (play-live-pattern with session: true). The hosted service then keeps, in a Cloudflare Durable Object under a random session id, a log of that player: the pattern the session opened with, the host's name and version, platform and capabilities as the player reports them when it joins, its runtime reports (for example an error message or "playing"), the cycle and position of taps on the stage, the controls on the player and how you move them, the full text of code you edit and run in the player or that a player tool swaps in (the newest three edits), when you press Pass, and the patterns the AI sends with update-session. The player also checks in with its clock and play state while it is open. Anyone holding the session id can read this log, open the session's current pattern in a browser at /s/<id>, and send the player new code, so treat the id like a share link. The log and the session are deleted two hours after the last activity; the player's check-ins and the AI's reads count as activity. A player that has been stopped and untouched for 30 minutes stops checking in until you press Play or edit again. You can end a session with End session on the player. The player then stops checking in, and the session's log is deleted 10 minutes later. This happens with the local server too, because the player joins the session on the hosted service.
Microphone and motion sensors
A pattern that calls mic() or tilt() asks for the microphone only after you interact with the player (a tap, click or key press), and only while that pattern declares it. Motion readings need the same interaction on browsers that ask permission for them (such as Safari on iPhone); on other browsers they can start when the pattern starts. The microphone signal is analysed in your browser for its loudness, a single number used by the music; it is never recorded, stored or sent to the hosted service or anyone else. Orientation readings stay in the page in the same way. In a live session, the resulting control values (a loudness or tilt between 0 and 1, about twice a second while they move) are logged like any other control. Replacing the pattern with one that does not use mic(), or closing the player, releases the microphone.
Player tools for your browser's assistant
The player offers tools to the page that hosts it: read its current code and play state, replace or swap the code, play, stop and undo. On a shared player page (/play, /p/<id>, /s/<id>), if your browser supports WebMCP, the page passes the same tools to an assistant built into your browser, so you can ask it to change the music. These calls stay between the page, the player and your browser's assistant; the hosted service does not receive them, except that in a live session a swap is logged like an edit (see Live sessions), and a say() line in swapped code is synthesized as described above. What your browser's assistant does with what it reads is governed by that assistant's own terms. A shared page's code was written by whoever made the link, so the tools mark what they return as untrusted content, and the assistant can play or swap code only after Play has been pressed on that page.
Separately, Cloudflare, which hosts the service, adds its own WebMCP script (/.webmcp/bridge.js) to pages on this domain. It offers this service's MCP tools and image content-credential (C2PA) checks to an assistant built into your browser. Calls it makes to this service's tools are handled like any other MCP request described here; the script itself is provided by Cloudflare.
Reference search and browser dependencies
search-music-docs sends your query and selected library to Context7. Results are cached for 24 hours under a hash of the query. The cached result may itself contain parts of the query. Other guide and harmony tools do not use this search service.
The players load scripts, fonts or samples as needed from unpkg, jsDelivr, GitHub/GitHub Pages, and, for the corresponding sample feature, shabda.ndre.gr and cdn.freesound.org. These providers receive normal network request information such as your IP address and user agent. The hosted service runs on Cloudflare. These providers process requests under their own policies, including Cloudflare's privacy policy and GitHub's privacy statement.
Usage information and retention
To understand compatibility and usage, the hosted service records MCP method/tool names, guide topics or the selected documentation library, requested resource identifiers, a coarse client label, for speech the voice, the line length and whether it was already cached (not the words), and for live sessions only that one was opened or refused by a rate limit (not its id or contents). For clients it does not recognize, it also records up to 200 characters of the user-agent header. These analytics do not intentionally include scores, pattern code, search queries or full conversations. Cloudflare Analytics Engine currently retains these events for up to three months.
Cloudflare processes network metadata and operational logs to provide and protect the service. Request URLs, including music embedded in query strings, may appear in those logs. Cloudflare Workers Logs currently retain logs for up to seven days, depending on the plan. Share rate-limit records use the request IP address and expire with a one-hour window. Speech rate limits are counted by Cloudflare's rate-limiting service per IP address (IPv6 by /64 network) over one-minute windows. The service does not use these records for advertising or to train an AI model.
Widgets store a bounded list of playback identifiers and timestamps in browser local storage to avoid replaying music when a host rebuilds the view. They keep at most 300 entries, not the composition itself; these entries remain until evicted or browser/site data is cleared. Your browser, MCP host, Context7 and sample/CDN providers can have separate retention policies.
Contact and choices
You can use the local server, avoid opening hosted browser links, and refrain from using reference search or creating stored shares. Local playback can still load browser dependencies from the providers above. Clear your browser's site data to remove playback-memory entries.
For privacy questions, access or removal requests, contact Xule Lin through the project support channel. If your request includes sensitive material, ask for a private contact channel first instead of posting that material publicly.