@nodatachat/mcp

The MCP door to NoData, the Information Access Processor.

Give an AI agent real power over your data — without the power to leak it.

One line connects any MCP client (Claude Code, an agent runtime) to NoData's governed‑access layer. Your agent asks "may I reach this?" and only ever sees the columns you granted. Denied columns are never decrypted on the server — there is nothing to leak — and every access leaves a signed, verifiable receipt.

claude mcp add -s user nodata -- npx -y @nodatachat/mcp@latest            # macOS / Linux
claude mcp add -s user nodata -- cmd /c npx -y @nodatachat/mcp@latest     # Windows
npx -y @nodatachat/mcp install-gate                                       # the read gate, the reminder and the status line

-s user makes it available in every folder, not only the one you ran it in; -y …@latest keeps npx from reusing an old cached version. Restart Claude Code after both.

Any other MCP client (Codex, Cursor, VS Code, Windsurf, Cline) runs the same server from its config:

{ "mcpServers": { "nodata": { "command": "npx", "args": ["-y", "@nodatachat/mcp@latest"] } } }

That's it — no flags. Self‑serve: registering opens an instant free sandbox key (no approval wall) and a 12‑word recovery phrase only you hold. No card. 10,000 governed decisions per month free, then $0.25 per 1,000.

The one idea: API access ≠ data access. A successful call is a request for a decision, not a handoff of data. no key = no plaintext, and every decision carries a proof.

Get started in one command

Run the line above with no credential. The server still connects (it never fails the MCP handshake) and exposes two setup tools:

• nodata_get_started — call it first. It explains what you get and the single next step.
• nodata_connect — register once, autoload forever:
  1. nodata_connect (no args) → opens the free signup in your browser (work email + company, ~30s). Your 12‑word recovery phrase is generated in your browser — NoData never sees it. The page shows your org key once.
  2. nodata_connect with api_key: "<that key>" → saved to ~/.nodata/credentials.json (chmod 600).
  3. Restart, or run /mcp → every later start loads your identity with nothing to retype. Registration ≠ login.

Keep the 12‑word phrase somewhere safe — it is the only way back into your org, and NoData cannot reissue it.

One journey, five verbs, two ways in

The whole product is one primitive shown five ways — Classify · Protect · Route · Retrieve · Prove — entered from a table (govern the DB columns an agent reads) or a folder/document (seal into a Capsule). Same journey, same proof.

| Verb | What you do | Tool | |------|-------------|------| | Classify | register a table's policy, then connect your own Supabase as its source | nodata_register_table → nodata_connect_source | | Protect | grant an agent only the columns you name | nodata_grant → ndca- token | | Route | "may this agent reach X?" — plan, no data moves | nodata_decide | | Retrieve | pull only the authorized columns into the prompt | nodata_retrieve / nodata_read | | Prove | a signed receipt on every grant, read and deny | nodata_proofs · /decisions |

Try it — the "wow" in four calls

After nodata_connect, ask your agent in plain language ("grant a support bot first_name and last_name on agent_demo_records, then read it"), or run the raw API with your key (export NDP=ndp_test_…):

# 1 · grant an agent two columns of the built-in demo table (auto-seeds sample rows)
curl -s -X POST https://www.nodatacapsule.com/api/v1/governance/grant \
  -H "Authorization: Bearer $NDP" -H 'content-type: application/json' \
  -d '{"agent":"support-copilot","table":"agent_demo_records","columns":["first_name","last_name"]}'
# → { "grant_token": "ndca-…", "handle": "…" }

# 2 · the agent reads what it's allowed — RELEASED
curl -s -X POST https://www.nodatacapsule.com/api/agents/<handle>/read \
  -H "Authorization: Bearer ndca-…" -H 'content-type: application/json' \
  -d '{"table":"agent_demo_records","columns":["first_name","last_name"],"limit":5}'
# → 200 { "rows": [ { "first_name": "…", "last_name": "…" }, … ] }

# 3 · the agent asks for a column it was NOT granted — WITHHELD
curl -s -X POST https://www.nodatacapsule.com/api/agents/<handle>/read \
  -H "Authorization: Bearer ndca-…" -H 'content-type: application/json' \
  -d '{"table":"agent_demo_records","columns":["email"]}'
# → 403 { "error": "scope_violation", "denied_columns": ["email"] }   ← the key for email is never derived

# 4 · prove it — signed receipts for the allow AND the deny, verifiable without the data:
#     https://www.nodatacapsule.com/decisions

email came back absent, not blanked — there is no decrypt‑all‑then‑filter path. That is "you decide what the AI sees," as math, not a promise.

No terminal? Same idea in the browser, zero install: https://www.nodatacapsule.com/ai-folder — drop a folder, see exactly what an AI would be allowed to read (nothing uploads).

Two modes — the credential decides what the server can do

Agent mode (--grant-token ndca-…) — permission management for language models. Hand an AI agent a grant token; the server exposes only tools hard‑scoped to that grant. The agent may request only the columns its grant allows — denied columns never decrypt server‑side, and every action emits a receipt. Point any MCP client at it and it physically cannot exceed its claims.

claude mcp add nodata -- npx -y @nodatachat/mcp@latest --grant-token ndca-YOUR_GRANT

Admin mode (--api-key ndp_… / sk_live_…) — the owner seat: register tables, issue and revoke grants, and use blind relay (encrypt / decrypt / deliver / evidence) from inside any MCP client.

claude mcp add -s user nodata -- npx -y @nodatachat/mcp@latest --api-key YOUR_API_KEY

Credential precedence: --api-key / --grant-token › NODATA_API_KEY / NODATA_GRANT_TOKEN › the saved ~/.nodata file. An explicit flag or env always wins.

On Windows, native (non‑WSL) npx needs the cmd /c wrapper: claude mcp add -s user nodata -- cmd /c npx -y @nodatachat/mcp@latest …. After changing the credential, restart — the running server keeps its old arguments.

The local workspace — scan, lock, work, release

Any mode except agent mode, no account needed, entirely on your machine. Anything that changes files or policy asks first: the call without confirm: true shows exactly what would happen and changes nothing.

| Say | Tool | What happens | |-----|------|--------------| | "scan this folder" | nodata_scan_folder | The whole result — counts by type, folder and file — plus a full content‑free HTML report in ~/.nodata/reports (every finding, never a value). | | "what should I do with these?" | nodata_plan | A recommended policy per file after the scan: tier (Restricted / Confidential / Internal) and action (clean copy + lock, lock, clean copy, keep); credentials also get "rotate at the source". Nothing happens until you approve, and you can change any line first. Proposing is not accepting. | | "lock what it found" | nodata_protect | Seals the files with findings to this device's key as <file>.ndc — the same v3 seal and format as nodata protect, so nodata open opens it too. Local receipt with hashes. | | "clean copy of this file" | nodata_redact | A copy with every detected value replaced by [CARD], [ID], [IBAN], [PHONE], [EMAIL]; a personal‑data column (CSV or Excel) is replaced with one stable token per person ([NAME-1] …) and amounts stay whole. Excel stays Excel. Same detectors as the scan. | | "open this .ndc" | nodata_open | Opens it back next to itself, hash‑checked. | | "who can read what?" | nodata_policy | The policy board (admin): every agent and its exact reach. Change it with nodata_grant (preview → approve, a copy of the approval kept in ~/.nodata/approvals) or nodata_revoke (immediate). |

Govern sharing — send, prove, revoke (admin)

The one-sentence version: encrypt locally, send, revoke later, prove what happened. NoData never holds a key that opens your file.

| Say | Tool | What happens | |-----|------|--------------| | "send this file to …" | nodata_send | Encrypts on this machine (post‑quantum hybrid) and returns a /lock/open/<id>#<key> link. The key rides in the #fragment, which never reaches a server; NoData stores ciphertext only. Expiry (≤ 7 days) and max opens. Filed under your org with a signed receipt + proof_url. Preview first. | | "send it to " | nodata_send with to | Over the NoData road instead of a link: sealed here to that computer's key (X25519 sealed box), ciphertext only on the server, only the file's type travels unless share_filename. The recipient's plate decides — delivered, waiting for their approval, or refused — and the decision is on both organisations' proof chains before anything moves. Up to 10 MB. Preview first. | | "let our partner read the files in this folder" | nodata_expose | Access, not copies: a partner's computer may ask for files inside a folder you choose (to: their NoData addresses, days), and this computer answers on the road with the verified clean copy of each file asked for (view: clean, default) — or the original only if you say view: original. The request is sealed (NoData does not learn which file), your plate decides who may ask, and each answer is on both sides' proof chains. list shows answered/refused counts; remove stops it at once. Asks first. | | "what's my address / what arrived / who may reach me" | nodata_inbox | address (a key made on this computer, ~/.nodata/fabric-key.json, only its fingerprint leaves), list (delivered + waiting, sender as their plate discloses it, never content), open (unsealed here into a folder, content not returned), approve / block a waiting sender, policy (open · verified · closed, allow/block lists, require purpose, what senders learn about you). Changes ask first. | | "was it opened?" | nodata_link_status | Opens so far, expiry, burned — one link or every link sent from this machine. | | "revoke it" | nodata_burn | Zeroes the stored ciphertext: nobody can open it again, including a forwarded copy. Signed receipt. Preview first. | | "archive these" | nodata_wrap | Seals files to the public half of your org master key (the 12 words) into your zero‑knowledge capsule. NoData can never open them; your 12 words always can — even if this computer is lost. Signed receipt + proof_url per document. Preview first. |

Terms, agents and the status line

• Terms in the terminal. The data tools wait until the current terms are accepted: nodata_terms shows them (section 7 covers AI agents: NoData answers for what passes through its tools, not for programs an agent writes or files it reaches on its own), and confirm: true accepts. The acceptance is kept in ~/.nodata/consent.json and recorded at NoData against your organisation, key and agent — and copied to your organisation's proof vault. Operational identification only: organisation, agent, version, time, hash. No content.
• Every agent has a name and a colour — claude-code@your-laptop, 🟣 — in every tool result, so several agents stay apart.
• The status line (installed with the read gate): ● NoData at the bottom of Claude Code — green = guarded, yellow = gate off, red = terms not accepted. No segment = not guarded. A status line you already had keeps running beside it, and comes back on uninstall-gate.

This machine as a Capsule node

A computer connected to your organisation joins its Capsule fleet as a node by itself, a few seconds after NoData starts. The admin's approval of that computer is the consent, and NODATA_NO_NODE=1 turns this off. nodata_node shows the node's status, and retries the registration if it failed. It uses the same enrolment and signed heartbeat as the installed Capsule agent.

• Capsule = node: one per machine.
• Agent = workload: Claude Code, Cursor or a bot running on that node.
• Billing = decisions: a node is not a billing unit.

Your organisation can require the read gate on a machine, in ask or block mode, and a minimum NoData version. It sets this on its Capsule page, and NoData applies it at the machine's next check-in. If someone turns the gate off, NoData turns it back on.

While an agent runs, a heartbeat every 5 minutes reports the NoData version, a machine id (a salted hash; the host name never leaves the computer), the agents' names, whether the read gate is on, and the accepted terms version. It never reports content, and the organisation can see and pause the node. The status line shows node ✓ 2m when NoData last verified it.

Run with your secrets — the agent never sees them

nodata_run runs a command on your machine, such as tests, a migration or a deploy script, with the secrets of your NoData vault project. The secrets are passed as environment variables.

• Memory only. The secrets are pulled into memory, through the same /api/secrets/pull the CLI uses, and every released value leaves a proof at NoData. No .env file is written.
• Blanked output. The agent gets the exit code and the output, with every secret value blanked. That includes the base64, hex and URL-encoded forms, and any credential the scanner recognises.
• Every command needs your approval, as written. Claude Code asks you in its own dialog. A client without one gets a preview and a single-use code bound to the exact command.

Save the token once, in your terminal. Never paste it into the chat:

npx @nodatachat/mcp secrets-login --project acme-web   # token from Courier → 🔑 סודות → CLI token
npx @nodatachat/mcp secrets-logout

Honest limit: a command that holds a secret can also leak it, for example by sending it out or printing it in an unknown form. Blanking protects the chat, not a hostile command, and that is why each command is approved as written.

Language — עברית or English, all the way

Choose once; NoData keeps it everywhere it speaks. That covers the read gate's question, the status line and the reminder after a read. It also covers an instruction every agent on this machine receives to answer you in that language for the whole session. Until you choose, the machine's own locale decides.

npx @nodatachat/mcp lang he     # עברית
npx @nodatachat/mcp lang en     # English

The agent also asks once, when you accept the terms (nodata_terms).

The read gate — a scan before the assistant reads

The MCP tools keep values out of the model only when the model uses them; Claude Code can also open a file with its own Read, Grep or Bash. One command puts NoData's scanner in front of those:

npx @nodatachat/mcp install-gate          # ask first (default)
npx @nodatachat/mcp install-gate --block  # refuse instead
npx @nodatachat/mcp uninstall-gate

Before Claude Code reads a data file (csv, xlsx, docx, pdf, .env …), the gate scans it on this machine with the same detectors as nodata_scan_folder. Findings → you are asked (or the read is refused), with the counts and the safer step: nodata_redact for a clean copy, nodata_protect to lock it. Clean copies, sealed files and source code pass without a question. The gate catches a Read, a Grep on a file, and a Bash or PowerShell command that names the file — also inside the script it runs (python -c "…load_workbook('x.xlsx')…"); a program that builds the path at run time is not caught — nodata_protect (ciphertext at rest) is what makes a file unreadable.

After you approve a read, a second hook reminds the assistant, right before it answers, that the file holds personal data and your screen is not private: totals and counts, no names or numbers unless you ask for them.

The installed gate is a copy in ~/.nodata. Every time NoData starts, it updates that copy to the running version and keeps your mode (ask or block), so gate fixes reach you without reinstalling.

Four more rules:

• Commands that print credentials. printenv, echo $API_TOKEN, gh auth token, gcloud auth print-access-token, cat ~/.aws/credentials and similar name no data file, yet put a live key in front of the model. They are held the same way, pointing to nodata_run, which runs a command with the secrets and blanks every value in its output. Every result is also checked afterwards. If a key got through anyway, the assistant is told not to repeat it and you are told where to replace it. A key that was already printed cannot be taken back, so the only fix is to replace it.
• Env files by the scanner's own rule. prod.env and app.env.local are checked like .env, and the question counts the secret-named variables in them.
• Code the last scan flagged. Source code normally passes. A code file your latest scan flagged critical or high (a customer's ID typed into a script) is held like a data file. Change the file or re-scan and it drops off the list.
• NoData's own keys are refused, never asked. No agent can read ~/.nodata/device-key.json, the vault login or the org credential, whichever tool it uses, even with approval. Whoever holds the device key opens every sealed file.

Back the device key up with one command, in a terminal and never in the chat: npx -y @nodatachat/mcp@latest key-backup E: (E: is your USB drive). It copies the key, checks that the copy is identical, and records the backup. NoData holds no copy of this key and cannot recover it, so this backup is the only recovery. NoData keeps reminding you until the backup is done.

At every start NoData checks this machine — version (and whether a newer one exists), organisation connection, terms, language, read gate, key backup, PDF readers — and the agent walks you through whatever is off, one step at a time. Anytime: ask "what is missing?", or run npx -y @nodatachat/mcp@latest doctor in a terminal.

Questions about NoData are answered from one answer bank: the agent passes the question to nodata_get_started and relays only what comes back — what NoData gives, with the tool that does it. Each answer is recorded in ~/.nodata/answers.log (entry ids and bank version, never the question), each line chained to the one before by hash.

Run a command with a project's secrets without a .env on disk: npx -y @nodatachat/mcp@latest secrets-login --project <label> once (the token is typed in the terminal, never in the chat), then npx -y @nodatachat/mcp@latest secrets-run -- npm run dev. The secrets live only in that command's memory. An agent does the same through nodata_run, with your approval per command.

PDFs are read by NoData's own reader. Two free tools make it read more, on this computer only (NoData never sends a document anywhere to read it): Poppler's pdftotext reads every PDF a second time and reads some the built-in reader cannot, and Tesseract reads scanned pages (OCR, in the folder scan). Install them once with winget install oschwartz10612.Poppler and winget install UB-Mannheim.TesseractOCR (tick Hebrew in its installer), then check with npx -y @nodatachat/mcp@latest pdf-tools. NODATA_PDF_TOOLS=off turns them off.

Available tools

Agent mode (--grant-token):

| Tool | What it does | |------|--------------| | nodata_decide | May the agent reach a resource? allow / degrade (reachable subset) / deny + an access‑distance cost + a signed proof. No data. Plan before you read. | | nodata_retrieve | Prompt‑ready authorized context, filtered to allowed columns, with an accounting of what was withheld + a proof. | | nodata_read | Read governed rows within the grant; denied columns never decrypt; every read is receipted. | | nodata_use | Invoke a pre‑registered secret‑blind capability — the Capsule injects the sealed credential server‑side and returns only the result. The secret never reaches the agent. |

Admin mode (--api-key):

| Tool | What it does | |------|--------------| | nodata_register_table | Register one of your tables' policy (which columns are sensitive, which are metadata). Encrypts nothing — the response says what your table still needs. | | nodata_connect_source | Connect your own Supabase project as the data source. Reads the URL, anon key and JWT secret from your local .env.local / .env and sends them straight to NoData — the model never sees them. | | nodata_grant | Issue one agent a claim‑scoped grant — over one table, or several with tables: [...]. Previews the policy change first; with confirm: true it grants, returns a grant_token (shown once) and a proof_url, and keeps a copy of the approval. | | nodata_policy | The policy board — every agent and exactly what it can reach. | | nodata_revoke | Revoke a grant by handle or jti — access stops at once. | | nodata_encrypt / nodata_decrypt | Field‑level AES‑256‑GCM; NoData stores nothing of the plaintext. | | nodata_deliver | Create a burn‑after‑read secure link with OTP. | | nodata_proofs | Your organization's signed proofs — every grant, read and deny — each verifiable by anyone at /api/access/verify. Every org key. Also returns plan: which proof types your plan includes, and which need an upgrade (named, never hidden) — the same list the site's proofs hub shows. | | nodata_evidence | Field‑level encrypt/decrypt/deliver events. Requires the Engine scope. |

Security & privacy model

• Content‑blind. For governed reads, denied columns are never decrypted on the server — the key release is scoped to the grant, not "we promise not to look."
• Every action is a receipt. Reads, grants, revokes and denials mint a signed, hash‑chained decision receipt (Ed25519, publicly verifiable), written before the release it authorizes — if the receipt can't be written, nothing is served.
• Structural isolation. A key is bound to its org; every governance query is scoped to that tenant, so a key cannot aim at another org's data.
• The honest boundary. This governs data the agent reaches through the Capsule. It does not sandbox a process already executing as you on your own machine.

Configuration

| Option | Flag | Env var | Default | |--------|------|---------|---------| | API key (admin) | --api-key | NODATA_API_KEY | — | | Grant token (agent) | --grant-token | NODATA_GRANT_TOKEN | — | | Base URL | --base-url | NODATA_BASE_URL | https://www.nodatacapsule.com |

Get a key free at https://www.nodatacapsule.com/capsule-api/register (issues ndp_test_… instantly). --help and --version are also available.

NoData on npm

• @nodatachat/nodata: the main package, with all protection, scanning and governance capabilities, from the terminal.
• @nodatachat/sdk: integration for developers.
• @nodatachat/mcp (this one): integration for AI agents and MCP clients.

License

FSL-1.1-ALv2 (Functional Source License 1.1, Apache 2.0 future license). Use it for any purpose except a competing product or service. Each release becomes available under the Apache License 2.0 two years after it is published. Versions up to 0.9.0 were published under MIT and remain available under that license. Copyright 2026 Capsule Ltd.