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, nine tools, read and write. Everything runs through the library, so path-safety, producer validation, and permissive loading come for free.

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

Save it to your user scope so it's available everywhere, and start it read-only by passing an environment variable with -e:

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

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

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_READONLY": "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.

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.

Set OKF_MCP_READONLY=1 and okf-mcp registers only the six read tools — the three writers (okf_write_concept, okf_append_log, okf_regenerate_indexes) are left out entirely. Use it for a shared reference bundle you want the model to consult but never edit.

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

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 §9 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 soon — the same nine 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