Cursor
Add ContextCache as an MCP server in Cursor so the assistant can read, search, and write to your caches from inside the editor. Cursor uses the same JSON configuration format as other MCP clients.
MCP endpoint
Use this URL when registering ContextCache as an MCP server:
https://contextcache-mcp.dylany.workers.dev/mcpSetup
Requires Node.js 18+
- Open Cursor and go to Settings → MCP (or Cursor Settings → Features → MCP, depending on your version).
- Click Add new MCP server, then select a JSON configuration option (or edit
~/.cursor/mcp.jsondirectly). Merge the configuration below with any existing servers:
{
"mcpServers": {
"contextcache": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://contextcache-mcp.dylany.workers.dev/mcp"
]
}
}
}- Save the configuration and restart Cursor. On first use, your browser opens so you can sign in to ContextCache and approve access.
- Verify tools loaded. Ask Cursor: “List my ContextCache caches using MCP.”
Cursor passes MCP tool calls through the agent in its chat surface. For the most current setup steps, refer to Cursor's own MCP documentation.
Recommended: custom instructions
Paste the text below into your Cursor rules (Settings → Rules) so the assistant bootstraps ContextCache automatically at the start of each conversation. Copy the text or download the file.
# ContextCache MCP — Custom Instructions
You have access to ContextCache, a structured knowledge store, via MCP tools. Follow these instructions whenever the ContextCache MCP server is connected.
## Start of every conversation
At the beginning of each new chat, bootstrap your context automatically:
1. Call `list_caches` to see which caches are available.
2. For each relevant cache (or the one the user specifies), call `get_instructions` to load the cache's system prompt — these are standing rules, identity notes, and priorities that should shape every response.
3. If the conversation topic is clear, run a quick `search` against the cache so you start with relevant knowledge instead of guessing.
Do this proactively — don't wait for the user to ask.
## Available tools
| Tool | Purpose |
|---|---|
| `list_caches` | List all caches you have access to |
| `get_instructions` | Load a cache's system prompt (rules, identity, priorities) |
| `search` | Semantic search over a cache — use for recall |
| `list_chunks` | Browse chunks at root level or within a parent |
| `get_chunk` | Read a chunk's full content, children count, and links |
| `create_chunk` | Add a new chunk (defaults to Inbox if no parent given) |
| `update_chunk` | Edit a chunk's title or content (re-embeds automatically) |
| `delete_chunk` | Remove a chunk (cannot delete the system Inbox) |
| `move_chunk` | Reorganize — move a chunk under a different parent |
| `create_link` | Link two chunks (supports, contradicts, expands, summarises, see also, references) |
| `trigger_job` | Queue a background automation (re_embed, cleanup, auto_link, deduplicate, summarize, cluster) |
| `get_job_status` | Check whether a queued job has finished |
## Workflow guidelines
- **Read before write.** Always check existing state (`search`, `list_chunks`, `get_chunk`) before creating or updating content.
- **Confirm before mutating.** When creating, updating, or deleting chunks, state the target cache and summarize the planned change in one sentence before executing.
- **Verify after mutating.** After any create/update/delete, re-read the affected item and report what changed.
- **Use search liberally.** If a user's question could be answered by cache content, search first rather than relying on your own knowledge.
- **Keep Inbox tidy.** New items land in the Inbox by default. If the user has folders, suggest moving items to the right place.
## Safety
- Never delete or overwrite content unless the user explicitly asks.
- If cache choice is ambiguous, ask one clarifying question.
- Never invent cache IDs or chunk IDs — always use values returned by tools.
- If a tool call fails, return the exact error text and suggest one concrete fix.