MCP integration

• fukura_classify — classify a raw command + stderr into an EKP ontology.
• fukura_search — full-text search over the local .fukura/ repo.
• fukura_record — persist a new note with an optional ontology.
• fukura_preflight — given a command about to run, return the most relevant past fixes and per-fingerprint success rate.
• fukura_record_attempt — record the outcome of a solution attempt (success / failure / abandoned) to feed the effectiveness loop.

Fukura ships a subcommand that merges itself into the Claude Code MCP config (either ~/.claude.json or a project-scope .mcp.json) without clobbering other entries.

# User scope
fuku claude-code register

# Project scope (writes .mcp.json in the current repo)
fuku claude-code register --scope project

# Verify
fuku claude-code status

# Remove
fuku claude-code unregister

The merge-patch is idempotent: repeated registration is a no-op. Every other MCP server and every top-level key is preserved.

Cursor reads MCP servers from its settings JSON. Open Cursor Settings → Features → Model Context Protocol and paste:

{
  "mcpServers": {
    "fukura": {
      "command": "fuku",
      "args": ["mcp"]
    }
  }
}

Alternatively, edit ~/Library/Application Support/Cursor/User/globalStorage/mcp.json (macOS) or the equivalent path on your OS. Restart Cursor. The five tools appear under the MCP menu; Composer can invoke them automatically.

Continue.dev picks up MCP servers from its config.yaml in the project root or ~/.continue/config.yaml:

mcpServers:
  - name: fukura
    command: fuku
    args: ["mcp"]

After saving, reload Continue. The tools are surfaced both to inline chat and to agent-style flows.

Zed’s Assistant exposes MCP via ~/.config/zed/settings.json. Under "context_servers" add:

{
  "context_servers": {
    "fukura": {
      "command": {
        "path": "fuku",
        "args": ["mcp"]
      }
    }
  }
}

Zed restarts the context server on config change; no reload needed.

Any language that can spawn a subprocess and speak line-delimited JSON can drive fuku mcp directly. Minimum viable handshake:

# Start the server
$ fuku mcp

# Send initialize
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2024-11-05",
  "capabilities":{},
  "clientInfo":{"name":"my-agent","version":"0.1.0"}
}}

# Server replies with its capabilities

# List tools
{"jsonrpc":"2.0","id":2,"method":"tools/list"}

# Call a tool
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
  "name":"fukura_preflight",
  "arguments":{"command":"cargo build"}
}}

Every request / response is a single line of JSON terminated with \\n. No HTTP, no auth token — fukura trusts its parent process, same as every other stdio MCP server.

JSON-RPC 2.0 over stdio. Fukura implements the standard initialize / tools/list / tools/call handshake and nothing else — no custom transport, no proprietary extensions. Any MCP-compliant client that speaks stdio will work; the table above is the short list we have verified.

If your client uses MCP-over-HTTP rather than stdio, wrap fuku mcp with a small adapter (e.g. a supervisor that forwards stdin/stdout to a WebSocket). The fukura side has no opinions about transport.

Agents generate orders of magnitude more failing tool calls than humans do. Without a shared memory layer those failures are invisible across vendors; each agent re-solves the same error. MCP gives fukura a neutral seat at the table — every capable agent can read and write the same EKP corpus.

See also the effectiveness loop: every MCP tool call feeds (fingerprint, outcome) pairs back into the ranking, so the suggestions improve with use.