jCodeMunch with Cursor

Run init

uvx jcodemunch-mcp init --policy

init finds Cursor and adds jCodeMunch to ~/.cursor/mcp.json, once for every project. Run it from your project folder: --policy is what adds the Cursor rules, and init asks first. The rules are per project, so run it again in each new one. The first start downloads the package and can take a few seconds; after that it starts from cache.

The rule file is what tells the agent

A connected server is not the same as a used one. Left alone, the agent keeps reaching for whole-file reads. init --policy writes .cursor/rules/jcodemunch.mdc with alwaysApply: true, so the rule is in context on every turn, subagents included, and it tells the agent to ask the index for the function it needs instead of opening the file.

The manual entry

If you’d rather write it yourself:

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "jcodemunch": {
      "command": "uvx",
      "args": ["jcodemunch-mcp"]
    }
  }
}

Fewer approval prompts

Cursor asks before it uses an MCP tool. In Auto-review mode, tools on your allowlist run without asking. A new install starts with a small front door, and its dispatch tools are marked as writers because they can reach anything. To allow the read tools one by one, set "tool_surface": "full" in ~/.code-index/config.jsonc. Then the tools that only read the index are marked read-only and indexing is marked as a write, so you can allow the readers and keep the prompt for the rest. On a team, an Enterprise admin can set the allowlist for the server.

Check it’s working

Ask the agent where a function is used. You should see a jCodeMunch tool call, not a file read. If you see neither, the troubleshooting notes are in CLIENTS.md.

Using it at work? Personal and other non-commercial use is free. Work use at a for-profit company, or for client or paid work, needs a license, paid once: see the prices.