Your bundle, live in Claude.

MCP is the open protocol Claude Desktop, Claude Code, and editors like Cursor use to talk to local tools. okf-mcp is a thin façade over the same OkfBundleTools the CLI and the Agent Framework layer use — one bundle per server, ten tools, read and write. Everything runs through the library, so path-safety, producer validation, and permissive loading come for free.

okf-mcp doesn't wire an attestation runtime, so the eleventh, execution-capable okf_run_computation tool (see docs/agents.md) isn't exposed here — only the read-only okf_get_computation above.

The prerequisite is the .NET SDK 10.0 or later. Install okf-mcp as a .NET global tool:

$ dotnet tool install -g OKF4net.Mcp   # installs the okf-mcp command

That's the whole install — one command, okf-mcp, on your PATH. Each server serves exactly one bundle; run one entry per bundle you want a client to reach.

1. Install okf-mcp (above) and note the absolute path to your bundle.
2. Open the config. Claude Desktop → Settings → Developer → Edit Config opens claude_desktop_config.json.
3. Add an okf server under mcpServers:

   {
     "mcpServers": {
       "okf": {
         "command": "okf-mcp",
         "args": ["C:\\Users\\you\\my-bundle"]
       }
     }
   }

4. Restart Claude Desktop. The okf tools appear in the tools menu — ask it to "browse the okf bundle" to confirm.

Prefer an environment variable to a positional path? Drop args and use "env": { "OKF_BUNDLE_ROOT": "/path/to/my-bundle" } instead — the two are interchangeable.

From your terminal, register the server. The -- separates Claude Code's own flags from the command it runs:

$ claude mcp add okf -- okf-mcp /path/to/my-bundle

That serves the bundle read-only. Save it to your user scope so it's available everywhere, and — only if you want the model to be able to write to the bundle — opt in with -e:

$ claude mcp add --scope user okf -e OKF_MCP_WRITABLE=1 -- okf-mcp /path/to/my-bundle

claude mcp list shows the registered servers; inside a session, /mcp lists the okf tools it exposes.

On Claude Code, the OKF plugin wraps the steps above into one install: it starts okf-mcp for you (no hand-edited config), teaches Claude OKF conventions through a bundled okf skill, and adds two slash commands — /okf-init (checks the okf-mcp install, then finds or scaffolds your bundle) and /okf-validate (conformance check, anytime).

$ /plugin marketplace add jchable/okf4net-claude-plugin
$ /plugin install okf@okf4net

Requires okf-mcp 0.5.0 or later — /okf-init checks this and offers the install if it's missing. Restart Claude Code once after installing so the plugin's skill and MCP config load.

Any client that speaks MCP over stdio can run okf-mcp, and the config shape is the same everywhere. In Cursor, add it to ~/.cursor/mcp.json (global) or .cursor/mcp.json (one project):

{
  "mcpServers": {
    "okf": {
      "command": "okf-mcp",
      "args": ["/path/to/my-bundle"],
      "env": { "OKF_MCP_WRITABLE": "1" }
    }
  }
}

The essentials for any client are the same three: run okf-mcp, pass the bundle path as the first argument (or set OKF_BUNDLE_ROOT), and let it talk MCP over stdio.

Neither given? okf-mcp walks up from the current working directory looking for a marked bundle — a root index.md whose frontmatter declares okf_version — testing each level's directory, then its knowledge/ child. Discovery is deliberately strict: an unmarked directory is never mistaken for a bundle, so a writable server can't start against an arbitrary docs folder by accident. Claude Desktop spawns servers with an unrelated working directory, so discovery doesn't help there — keep the positional argument or OKF_BUNDLE_ROOT in claude_desktop_config.json.

Once connected, just describe the task; the model picks the tool. A few everyday moves:

After a batch of writes, ask it to "regenerate the indexes" (okf_regenerate_indexes) so the index.md listings stay current.

okf-mcp registers only the read tools unless you ask for more — the three writers (okf_write_concept, okf_append_log, okf_regenerate_indexes) are left out entirely. Set OKF_MCP_WRITABLE=1 to add them, which you want for a working bundle the model maintains, and do not want for a shared reference bundle it should only consult.

The reason the safe setting is the free one: bundle content is untrusted — it comes from files another agent or a human contributor may have written — so a prompt injection smuggled into a concept body can only cause a persistent change if a write tool is reachable in the first place.

Changed in a recent version. Earlier releases registered the write tools unless OKF_MCP_READONLY=1 was set. That variable is still accepted and still forces read-only — it wins if both are set — so an existing config keeps working unchanged.

{
  "mcpServers": {
    "okf-docs": {
      "command": "okf-mcp",
      "args": ["/path/to/reference-bundle"]
    }
  }
}

Each tool is an OkfBundleTools operation — the same code behind the CLI and the Agent Framework layer — wrapped as an MCP tool. So a concept id that would escape the bundle is rejected, a write is validated against the §11 producer rules before it touches disk, and a malformed file never aborts a load. Logs go to stderr; stdout carries only the protocol.

→ agents.md — the same tools for the Microsoft Agent Framework · library.md — the API underneath

• Author the bundle first. Write one concept, validate it, then hand it to a client. → getting-started.md
• Do the same from code. Load bundles, walk the graph, generate indexes from C#. → library.md
• Or from the shell. The okf CLI runs the same operations without a client. → cli.md

→ docs.md — back to the docs index