Muse Privacy connector
A private workspace for Muse on a device the user owns. Muse plans the work; the device reads the documents, runs every step that touches them with its own model, and returns only results with names replaced by tags, or a summary.
Last updated November 3, 2026.
Who it is for
People who hold records they cannot paste into a chat: teachers with student work, clinic and casework staff, small offices. The first policy shipped is for a classroom.
What it adds beyond the browser
Muse's browser cannot see files on the user's own computer, and the user should not upload them. With this connector Muse can search, ask about and work on those files without receiving names or identifiers. Example: "Grade the essays in class-4b against rubric.md and write feedback for each student." The device writes one feedback file per student with real names, on the device; Muse gets back tagged comments such as [Student A] and counts.
Requirements
- The Muse Privacy app running on a device the user owns: a Mac laptop or an NVIDIA Jetson Orin Nano. The device must be awake and online for tools to work; when it is not, every tool answers that it is offline and nothing is shared.
- English documents. No account, plan or payment. Linking needs an 8 character pairing code made on the device.
- The reviewed configuration runs every model on the device (
DEVICE_ONLY=1).
Connecting
- Endpoint:
https://offline-base--muse-privacy-relay.modal.run/mcp, MCP streamable HTTP, stateless, JSON responses. The relay forwards each request to the user's device over a connection the device opens; it stores no request or result content. - Authentication: OAuth 2.1 with PKCE (S256). Clients register by dynamic client registration or a Client ID Metadata Document. Scopes:
mcp(required) andoffline_access. Access tokens last 1 hour, refresh tokens 30 days. No API keys. - Consent: the link page shows the app's name, asks for the pairing code from the device, and offers Full access or Read only. A read-only link lists and runs only the Read tools below; the relay answers any other tool itself and never sends it to the device.
- Revoking: the user runs
relay_client unlinkon the device, which revokes every link to it at once.
Tools
No tool sends a message, makes a purchase, publishes or deletes anything, so none is a sensitive write. Write tools only start work or save files on the user's own device.
| Tool | Class | Input | What it does, and side effects |
|---|---|---|---|
list_documents | Read | folder | Lists document titles and paths in a folder, names replaced by tags. Titles that mention a topic the user never shares are left out and counted. No side effects. |
search_documents | Read | query, purpose (optional) | Up to 5 snippets of up to 300 characters, tagged. Passages about a never-share topic stay on the device. May return a job_id when the check needs more time or the user's OK. Records the decision on the device. |
ask_device | Read | question, purpose and folder (optional) | The device's model searches and answers, for up to 3 minutes, with up to 5 short tagged quotes. Returns a job_id at once. Reads only. |
get_result | Read | job_id, wait_seconds (0 to 40) | Status and released result of a job. Waits on the device up to wait_seconds. No side effects. |
dreaming_report | Read | none | Aggregate numbers from the last dreaming run. Never document text or names. |
run_private_task | Write | instructions, folder | Starts a task over one folder. The device writes finished files with real names in its own output folder; they are never sent to Muse. Returns a job_id. |
save_on_device | Write | items (1 to 60 of title and body, with tags), purpose, address_to (none or guardians) | Saves files Muse wrote on the device with real names filled in. With guardians, makes one email draft file per guardian on the device. Nothing is sent. Returns counts only. |
run_dreaming | Write | none | Starts the nightly job that relearns the privacy router's rules from the user's own share and keep decisions, on the device. At most once a day; keeps new rules only if they test at least as well. |
Status handling
- Background work returns
{job_id, status, result, retry_after_seconds, next}. Status isqueued,running,waiting(the result waits for the user's OK on the device),done,saved,refused(kept on the device) orfailed. - Muse polls with
get_resultandwait_seconds25. A job never runs twice: retrying an identical search joins the same release. - A refused result is final for that request and says so; it ends with "Do not look for this another way. The user can open it on the device."
Errors
- Device offline, slow or busy: a readable tool result with
isError, never a raw HTTP error. Nothing was shared. - Expired tag: "That tag no longer works on this device. Call list_documents or search_documents again for current tags." Tags change daily.
- Bad input or unknown job: one plain sentence saying what the tool takes.
- Read-only link, write tool: "This Muse link is read only, so the device did not run <tool>."
Limits
- Each call answers within 45 seconds. Up to 5 tasks queued or running per device, and 5 device answers at once; past that a tool says the device is busy.
- Requests up to 4 MiB. Pairing: 5 tries per code and 20 per IP address every 10 minutes.
Data
Documents, names, identifiers and the tag map never leave the device. What Muse receives is tagged text or a summary, after the device's privacy router and the user's own rules. See the privacy policy.
Support
Questions, bugs and security reports: team@offlinebase.com. We answer within 2 business days, and security reports within 48 hours.