Connect
VS Code

Give the agent in VS Code project memory.

Add the Bilinc adapter to VS Code's MCP configuration and its agent can recall the decisions a project already made before it edits, then keep what each session settled, with every earlier version.

Start free MCP clients guide MCP tools

Set it up.

VS Code runs the Bilinc MCP adapter from the bilinc Python package, which reads the key bilinc login saved.

Install the package and sign in. One package gives you the Python SDK, the bilinc command and the MCP adapter. bilinc login opens your browser and saves the key on this machine.
Terminal
```
pip install -U bilinc
bilinc login
```
Add Bilinc to .vscode/mcp.json. VS Code keeps a workspace's MCP servers in .vscode/mcp.json, under a servers object, and a stdio server names its type. The command and arguments are the ones bilinc mcp install prints; use the absolute Python path it gives you.
.vscode/mcp.json
```
{
  "servers": {
    "bilinc": {
      "type": "stdio",
      "command": "python3",
      "args": ["-m", "bilinc.cloud_mcp"]
    }
  }
}
```
Give the agent the memory contract. Paste the contract below into the instructions your VS Code agent reads, so it recalls before editing and commits outcomes at the end.

Where VS Code keeps its MCP servers is described in VS Code's MCP configuration reference.

What it changes for VS Code.

The agent in VS Code sees the open workspace and the chat. It does not see why the code looks the way it does: which approach the team rejected, what the last refactor deliberately left alone, which flag is safe to remove. With Bilinc it can recall those decisions before it edits, each with its source and its version.

At the end of a task it commits a short outcome with how it was verified. commit_mem keeps provenance with every write, revise replaces a memory deliberately, and every earlier version stays in the history.

The same memory is available from Python, the CLI and every other client you connect to the workspace, so work started in VS Code can be picked up somewhere else.

Things to ask.

Ask in your own words; the agent picks the Bilinc tool that fits.

“Recall Bilinc for decisions about this module before you change it.”
“Snapshot Bilinc before this migration so we can go back.”
“Diff Bilinc against the last snapshot and summarise what changed.”
“Commit a short outcome for this task with how you verified it.”

The memory contract

Paste this into the instructions VS Code reads, so it recalls before it acts and keeps only what is worth keeping.

Instructions for your agent

Before editing, recall Bilinc for relevant project decisions.
After completing the task, commit a short session outcome with verification and caveats.
Never store secrets in memory.

The tools it gets.

The tools of the local adapter, as the tool reference lists them.

The tools of the Bilinc MCP adapter
Tool	What it does
`commit_mem`	Writes durable memory with key, value, memory type, importance, and provenance metadata. Returns an entry version you can reuse for optimistic concurrency.
`recall`	Retrieves prior state with query, profile, and limit. Smart retrieval is the profile argument, not a separate tool.
`revise`	Deliberately replaces a memory you already have. Returns memory_not_found rather than creating, so a correction stays distinguishable from an accidental overwrite.
`forget`	Destructive. Removes a memory from active recall. A reason is required and is written to the audit trail; the deleted value is never returned.
`status`	Reports the authenticated workspace, plan, limits, supported capabilities, and recall profiles. Read-only and never billed.
`snapshot`	Creates or lists project checkpoints. Create is metered; list is free. Neither returns the checkpoint contents.
`diff`	Compares a checkpoint against another checkpoint or current state. Free, and values are redacted unless explicitly requested.
`history`	Read-only and free. Returns one memory’s recorded changes, newest first, with the value before and after each change. Values from before the memory was forgotten are never returned.
`list_memories`	Read-only and free. Returns a page of stored memories ordered by key, with prefix, type, and updated-time filters and a cursor for the next page.
`confirm`	Records that an existing memory is still accurate without resending its value. The value stays as stored, its last-updated time moves to now, and history shows a confirmation. One write operation.
`rollback`	Destructive in execute mode. Preview is free and returns a short-lived confirmation token; execute needs that token and permanently discards everything changed since the checkpoint.

The tool reference

Questions.

Why does VS Code use servers instead of mcpServers?

VS Code's own MCP format keeps servers under a servers object and names each stdio server's type. The command and arguments are the same ones every other client uses.

Does .vscode/mcp.json need an API key?

No. The adapter reads the key that bilinc login saved on your machine, so the file can be committed without secrets. A machine without a saved key needs BILINC_API_KEY in the server's environment.

Which tools does the agent get?

The tools of the local adapter: commit_mem, recall, revise, forget, status, snapshot, diff, history, list_memories, confirm and rollback. The tool reference lists what each one does and what it costs.

How do I undo a bad session?

Take a snapshot before risky work. diff compares it with the current state, and rollback restores it: a free preview first, then an explicit execute. Rollback works on checkpoints, not on single keys.

Is the memory shared with my other clients?

Yes. Every client connected to the same workspace shares its memory, whether it is VS Code, Cursor, Codex or Claude.

Bilinc connects the same way everywhere.

One workspace, every client. The memory guides and comparisons answer the questions underneath.