rift

Rift

Install Rift, connect its MCP server, and read a workspace.

Since v0.0.26 · Rust, JavaScript, TypeScript, Markdown, JSON, YAML, TOML, Python

Rift is an agentic development toolkit for reading, discovering, and editing codebases.

Rift provides MCP agents structured reads and edits for various programming languages in the project workspace.

Currently, Rust, Python, JavaScript and TypeScript (including TSX), Markdown, JSON, YAML, and TOML are supported, and more languages will be added in upcoming releases.

Install

curl --proto '=https' --tlsv1.2 -fsSL https://volar.sh/rift/install.sh | bash
irm https://volar.sh/rift/install.ps1 | iex

The installer downloads the latest verified release for your platform and installs it for the current user. To install a specific version, set the RIFT_VERSION environment variable to its release tag.

MCP configuration

An MCP client launches rift mcp in the folder containing the codebase. Register it in the client's MCP configuration - for Claude Code, .mcp.json in the project root:

{
  "mcpServers": {
    "rift": {
      "command": "rift",
      "args": ["mcp"]
    }
  }
}

Reads

Rift reads the source files in the folder where the MCP client launches rift mcp. Later calls include edits made through Rift, your editor, a formatter, or another process.

When you know what the code does but not its name, ask your agent to search for it:

Use Rift to find all information about server startup.

The agent calls search with the query server startup, which returns matching declarations and source lines with their paths.

Retrieve symbol

When you know the declaration name, ask for it directly:

Use Rift to retrieve the ReadService declaration.

The agent calls get_symbol, which returns the declaration and its source excerpt. It can pass a returned path and byte position to nodes when it needs the surrounding syntax structure.

The MCP reference defines request fields and result shapes for client integrations. The index architecture explains how Rift keeps those reads aligned with filesystem changes.

Edits

The change tools edit the workspace. Each resolves its address against the published index, proves its preconditions against the bytes on disk, and only then writes - atomically, behind one application lock, so two concurrent changes collide as a clean refusal rather than as interleaved bytes:

  • replace_symbol rewrites one declaration addressed by symbol; the parser derives the span.
  • insert_symbol lands a new declaration before or after its anchor, or content at a file target; create_missing creates a missing file target first.
  • replace_node replaces one syntax node through a witnessed address from nodes; a stale witness refuses with the expected and observed values.
  • insert_node inserts content before or after a node addressed the same way replace_node is; the body lands verbatim, with none of insert_symbol's blank-line or column handling.
  • patch applies unified-diff hunks, several files in one change; a context mismatch refuses and the tree stays untouched.
  • rename_symbol renames a declaration and every reference the configured language engine resolves.
  • move_file moves one file, and an engine that supports it updates the imports that pointed at the old path.
  • remove_symbol removes one declaration addressed by symbol, checked against the configured language engine's references first; a standing reference refuses unless force applies it anyway.
  • remove_node removes one syntax node through a witnessed address from nodes, checked the same way when the node names a declaration.

A change that cannot land returns a refusal naming the failed precondition, and the tree is untouched. After a change applies, the server re-parses what it touched and reports parser findings on the result. Every failure carries a stable error code and a suggested action.

Update

rift update

The command downloads the latest verified release for your platform and replaces the current executable. While it runs, the command reports each stage on the terminal: the release it found, the download with its byte progress, checksum verification, extraction, and installation.

Server logs

When a tool refuses and the refusal alone doesn't say why, read the server's own diagnostics. The server records them beside the index in .rift/db, and rift server logs prints them oldest first, with or without a running server:

rift server logs

The flags narrow what prints:

  • -f, --follow keeps printing records as the server writes them
  • -n, --tail prints only the newest records
  • --since takes a duration such as 10m
  • --level selects one severity
  • --component selects one component: index, search, engine, change, or logs

Those are the records an agent reads through the rift://logs resource, and the [logs] table bounds how many the server keeps.

CLI

$ rift --help
agentic development toolkit

Usage: rift [COMMAND]

Commands:
  mcp      Serve agents over stdio MCP by proxying this workspace's rift server
  server   Manage this workspace's HTTP MCP server
  update   Replace current Rift binary with latest official release
  install  Generate or remove a coding agent's Rift skill
  steer    Answer one Claude Code `PreToolUse` hook call from stdin
  help     Print this message or the help of the given subcommand(s)

Options:
  -h, --help     Print help
  -V, --version  Print version

$ rift server --help
Manage this workspace's HTTP MCP server

Usage: rift server <COMMAND>

Commands:
  start    Start this workspace's server, detached unless --foreground
  stop     Stop this workspace's server
  restart  Stop this workspace's server, then start a fresh detached one
  status   Report whether this workspace's server is serving
  logs     Print this workspace's recorded server diagnostics, oldest first
  help     Print this message or the help of the given subcommand(s)

Options:
  -h, --help  Print help

$ rift server logs --help
Print this workspace's recorded server diagnostics, oldest first

Usage: rift server logs [OPTIONS]

Options:
  -f, --follow            Keep printing records as the server writes them
  -n, --tail <COUNT>      Print only the newest COUNT records; `all` prints every kept record [default: all]
      --since <DURATION>  Print only records newer than DURATION ago, such as `10m` or `2h`
      --level <LEVEL>     Print only records at this severity, as the store spells it [possible values: trace, debug, info, warn, error]
      --component <NAME>  Print only records one component emitted, as its spans label it: index, search, engine, change, or logs
  -h, --help              Print help

Planned pages

Architecture, Configuration, and the Protocol section carry a Planned badge where they describe the design ahead of implementation. Each release moves parts of those pages into the shipped surface this page describes.