MCP server

Connect an AI agent to BitGraph and let it make proofs of the files it works on. For anyone setting up Claude, Claude Code, ChatGPT, Cursor or VS Code, and for the engineer deciding what an agent is allowed to send.

Two servers

BitGraph speaks the Model Context Protocol in two forms. Both make the same BitGraph on the same sequence; they differ in where the files are.

Hosted endpoint: https://bitgraph.ing/mcp, Streamable HTTP, nothing to install and no key. Four tools: bitgraph_open, bitgraph_commit, bitgraph_check, bitgraph_get_proof. The agent hashes each file where it is and builds the new file itself from a recipe. Up to 40 files per call.
stdio package: npx -y @mikeargento/bitgraph-mcp (0.5.1, MIT), for clients that run on the machine that holds the files. Five tools: bitgraph_record, bitgraph_open, bitgraph_commit, bitgraph_check, bitgraph_get_proof. It reads files locally, folders of any size, and one call makes one BitGraph of everything in it.

MCP endpoint

https://bitgraph.ing/mcp

The same URL serves both audiences: an MCP client gets the protocol, a browser gets this page.

Connect

Every client wants the same thing: the URL, pasted where it keeps remote MCP servers, or the package command where it keeps local ones. Find yours and follow the steps.

Claude

claude.ai, Claude Desktop, and the mobile apps.

Open Customize, then Connectors.
Click +, then Add custom connector.
Paste the URL and click Add. Leave Advanced settings alone, there is no OAuth to configure.
In a conversation, open the + menu at the lower left, choose Connectors, and switch BitGraph on.

Step 4 is the one people miss: adding a connector does not turn it on, each conversation opts in. Free accounts can hold one custom connector. On Team and Enterprise an Owner adds it once under Organization settings, then Connectors, and everyone else clicks Connect.

Claude Code

One command, no menus. The hosted endpoint:

Shell

claude mcp add --transport http bitgraph https://bitgraph.ing/mcp

Or the stdio package, for files and folders on this machine:

Shell

claude mcp add bitgraph -- npx -y @mikeargento/bitgraph-mcp

Run claude mcp list to confirm, or /mcp inside a session. BitGraph should read Connected.

ChatGPT

Needs developer mode, which is a beta feature on Plus, Pro, Business, Enterprise, and Education accounts, on the web.

Open Settings, then Security and login, and turn on Developer mode.
Go to chatgpt.com/plugins and click +.
Name it BitGraph, paste the URL, and choose No authentication. The URL already ends in /mcp, so paste it exactly as it is.
Create the connection. ChatGPT lists the four tools it found, which is your confirmation that it worked.
In a new chat, open the + menu, choose Developer mode, and select BitGraph.

ChatGPT treats opening and committing as write actions and asks you to confirm each one, showing what it is about to send. Every new conversation starts from the same cautious default.

Cursor, VS Code, and everything else

Add the URL as a remote MCP server. Some clients label the transport streamable-http and some label it http; they are the same thing, and BitGraph speaks it. No key, no configuration. Clients that run local servers can use the package command above instead.

Client menus get renamed and moved. If a label above does not match what is in front of you, the URL is the part that matters: find wherever your client keeps remote MCP servers and paste it there.

You are done when

The client lists the tools. Four from the hosted endpoint, five from the package. Ask your agent:
Ask your agent
```
Which tools does BitGraph offer?
```
That answer means the connection is live. Asking costs nothing and writes nothing.
A proof of a file you named comes back and is saved beside it. Name a file, ask for a BitGraph of it. The agent hashes it, opens a slot, builds the new file, commits, and saves the proof next to the original: <name>.bitgraph-fuse.json for a single file, one set proof beside the originals for several. The proof is saved whole and unedited, every field, including environment.attestation.reportB64: a proof missing slotAllocation, environment or the attestation cannot be verified.

What each tool sends

Tool	Sends	Returns	Writes
bitgraph_open	Per file: its name, exact byte size, fingerprint (SHA-256 digest), and its first 16 bytes (up to 64), which decide the placement. Or no files at all: the task form below.	Per file: a `fuse_token`, the placement, the recipe (bytes to append after the original, or a prefix and suffix around it), the slot counter and epoch, and the names for the new file and its Frame. Files opened together share one slot. A file BitGraph’s copy already indexes comes back “on record” and is not opened unless `again` is true.	Allocates a slot: a position, held 120 seconds.
bitgraph_commit	Per entry: the `fuse_token` and the digest of the new file built from its recipe. For a task token, the digest of the task bytes, with `carry: "base64url"`.	One proof and Frame per single file; one set proof with every member’s row for files opened together; and every position the original’s bytes now hold. Nothing is labelled fused unless the proof came back under the named slot and verified.	Commits: binds the digest and consumes the slot.
bitgraph_check	Up to 500 digests.	Per digest: `on_record`, every indexed position (with a set member’s row), and a proof URL.	Nothing. Read-only.
bitgraph_get_proof	A digest, or a BitGraph number in the current epoch; optionally a counter and epoch to select one position.	The proof, every indexed position the same bytes hold, and its floor: placed no earlier than a named Ethereum block.	Nothing. Read-only.
bitgraph_record package only	File and folder paths. The package reads them on this machine; only digests, the committed artifact and slot records leave it.	One BitGraph of everything in the call, each file with its row; files already on record are returned as they are unless `again` is true.	Allocates and commits in one call.

Nothing else travels: only digests, sizes, a file’s first bytes, slot records and recipe bytes, to either server. File contents never do, and originals are never modified.

BitGraph keeps a copy of each proof the service makes, indexed by digest, so a check finds what was made through it. A miss is not a finding: the bytes may hold a BitGraph their holder keeps, so the agent is told to ask for that proof before making another.

How the hosted endpoint makes a BitGraph

The endpoint never receives a file. If an agent can hash a file it can build the virtual new file and hash that, so the two steps are all it takes: hash the originals, open a slot, build each new file exactly as its recipe says, hash it, commit them together. A batch is one position however many files it holds. Only digests, byte sizes, a file’s first bytes, the signed slot record and the recipes cross the network. Agents with code execution, ChatGPT and Claude among them, do this on any files you give them.

For clients that run on your machine, the stdio package does the same in one call from plain file paths, and makes one BitGraph of everything in the call: a folder of any size becomes one set under one slot. Each file is read once for its digest; the new files are never written.

The task pattern

An agent can take a position before it starts a task, so that the task’s record could not have existed before that position’s floor, and its outputs sit after it.

Before the task, call bitgraph_open with no files. It returns a position (slot counter and epoch), the slot’s commitment string, a fuse_token, and the floor block when it is known.
Put the commitment into the task’s record. Inside the output itself when its format can hold text (a comment, a field, a line that stays in the file), otherwise inside the task: the exact prompt or request.
Within 120 seconds, call bitgraph_commit with the fuse_token, the digest of those exact bytes, and carry: "base64url". The bytes are sealed under the position. Keep them unchanged: a verifier recomputes the commitment from the proof and looks for the string inside them.
When the outputs exist, record them. Open a second position with the files and commit them. The task is sealed before the output existed, and the output is recorded after.

The proof establishes placement in the sequence. It does not establish that the task was carried out well, who ran it, or that the output is true.

Notes

Files are never uploaded. Only digests, byte sizes, a file’s first bytes, signed slot records and recipe bytes cross the network, to either server.
Positions are permanent. A consumed slot is never reused, and the anchors that floor it stay published for ten years. The proof comes back to the agent, which keeps it. Agents are instructed to make BitGraphs only of files you asked for, and never to generate content just to record it.
One way. A BitGraph is new bytes built from the original under a slot that existed first, so those bytes could not have been finished before the slot: that is what open and commit make, one file on its own or a batch as one set. Neither server offers digest-only recording; that compatibility operation stays on the HTTP API as POST /api/commit.
One set per call. Everything opened together shares one slot and is committed in one call. A member left out cannot be added afterwards, because the slot is consumed; it needs a new open.
One sequence. Whatever MCP makes takes its position in the same sequence as everything else, floored by the same anchors.
Limits and errors. 40 files per open on the hosted endpoint, 500 digests per check, a 120-second slot, and a restart at 23:59 UTC every day that voids open slots. no-anchor-before-slot means nothing was committed and the slot is still held: commit again in about 15 seconds. slot-unavailable means the slot was consumed, expired or lost to a restart: open again and rebuild the new file from the new recipe.

Where next

Integration guideThe same operation from the CLI, the SDK, or two HTTP calls.
API referenceThe routes the MCP servers call, with every status code.
VerificationHow to check the proof an agent saved, offline.
ContactLicensing, evaluation and questions.