MCP

BitGraph is an MCP server. Any AI agent that speaks the Model Context Protocol can make BitGraphs of files, check whether bytes are on record, and fetch proofs with one URL. It needs nothing more than the ability to hash a file: the file itself never leaves the agent.

MCP endpoint
https://bitgraph.ing/mcp

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

Connect

There is nothing to install and no key to request. Every client below wants the same thing: that URL, pasted where it keeps remote MCP servers. Find yours and follow the three or four steps.

Claude

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

  1. 1.Open Customize, then Connectors.
  2. 2.Click +, then Add custom connector.
  3. 3.Paste the URL and click Add. Leave Advanced settings alone, there is no OAuth to configure.
  4. 4.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.

Shell
claude mcp add --transport http bitgraph https://bitgraph.ing/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.

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

ChatGPT treats opening, committing and recording as write actions and asks you to confirm each one, showing what it is about to send. Checking and fetching proofs are read-only. 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.

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.

Check that it worked

Point your agent at any file you have and ask:

Ask your agent
Is this file on record with BitGraph?

A file that has never been recorded comes back as not on record. One that has comes back with its causal position and a link to its proof page. A file that was dropped on the site comes back with the fused artifact built from it, listed as a fused descendant with its position and placement. Any of these answers means the connection is live. Asking is read-only and writes nothing to the ledger, so it is a safe first move.

Five tools

  • • bitgraph_open · Make a BitGraph, step one. The agent sends a file's name, size, SHA-256 digest and first 16 bytes. An unused slot is allocated at the boundary before the new file exists, and the agent gets back a token and a recipe: the exact bytes the new file adds after the original (trailer/1, for formats that ignore trailing data) or around it (container/2, a tar that carries the original untouched and first).
  • • bitgraph_commit · Step two. The agent builds the new file from the recipe, hashes it, and sends the token and that digest. The boundary commits it under that exact slot with the signed marker, and the agent gets back the proof and the Frame to save next to the original. The new file is virtual: the original plus the Frame rebuilds it.
  • • bitgraph_record · The compatibility recording: digests alone, no new file. It gives bytes that already exist a position and establishes that they existed no later than the commit.
  • • bitgraph_check · Is this file on record? Read-only. It reports on_record, every recording of the exact bytes, and fused_descendants, every fused artifact that names the bytes as its origin, each listed by position with its proof page URL.
  • • bitgraph_get_proof · Fetch a proof and its Ethereum anchor window: BitGraphed between block X and block Y.

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 above are all it takes: hash the original, open a slot, build the new file exactly as the recipe says, hash it, commit. Only digests, byte sizes, a file's first bytes, the signed slot record and the recipe cross the network. Agents with code execution, ChatGPT and Claude among them, do this on any file you give them.

For clients that run on your machine, the stdio package does the same in one call from a plain file path:

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

Notes

  • • Files are never uploaded. Only SHA-256 digests, byte sizes, a file's first bytes, signed slot records and recipe bytes cross the network, to either endpoint.
  • • Recordings are permanent. The ledger has 10-year retention and no deletes. Agents are instructed to record only files you asked to record.
  • • Two operations. A fused file is new bytes built from the original under a slot that existed first, so those bytes could not have been finalized before the slot: that is what open and commit make. A recording gives bytes that already exist a position, and only says they existed no later than the commit: that is what bitgraph_record makes.
  • • One ledger. Whatever MCP makes lands on the same ledger as everything else, and a lookup by the original's digest finds its fused artifacts by position and placement, never ranked.