Documentation

MCP server

tbase mcp serves the Model Context Protocol over stdio. Every titlebase command is a tool, so an AI agent on your machine can search, edit, undo and save a plant, and do anything the app can do.

How it works

One tool per command. Tools are generated from the same registry as the CLI. A new command is a new tool, with no extra code.
Parity is tested. A test fails the build if a command is missing from the CLI or MCP, or if either is missing an input.
Typed. Each tool has a JSON Schema for its input, written from the same Rust types the command uses.
Local. The server runs on your machine and reads the plant from disk. titlebase does not upload your plant anywhere.

Claude Code

claude mcp add titlebase -- tbase mcp

Then ask in plain words: "How many warranty deeds in SAMPLE ADDITION 5 name DOE?" The agent calls docs_search and reads the JSON.

Other MCP clients

Any client that launches stdio servers works. Most take a config like this:

{
  "mcpServers": {
    "titlebase": {
      "command": "tbase",
      "args": ["mcp"]
    }
  }
}

Use the full path to tbase if it is not on the client's PATH.

Bind to one plant

With --file, every tool defaults to that plant, so the agent does not need to pass file on each call:

claude mcp add titlebase -- tbase mcp --file ~/plants/sample-county-tx.titlebase

Tools

Tool	CLI	What it does
`file_info`	`tbase file info`	Show a plant file's size, page size, row counts per table and any extra tables.
`docs_get`	`tbase docs get`	Fetch one document by UUID or row id, with its full stored JSON.
`docs_list`	`tbase docs list`	List documents in row id order, or sorted by any indexed column, one summary line each, with keyset paging.
`docs_search`	`tbase docs search`	Search documents by instrument number, type, filed dates, party, grantor, grantee, addition, lot, block, book and page, sorted by any column; all given filters must match. Uses the sidecar index when current, else scans.
`ac_list`	`tbase ac list`	List autocomplete values (additions, surveys, instrument and book types), optionally of one type.
`lv_list`	`tbase lv list`	List land validations (plat validation records by addition), optionally for one addition.
`check_roundtrip`	`tbase check roundtrip`	Prove titlebase can rewrite a plant byte for byte: re-emit every row with titlebase's JSON writers, and optionally write and compare a full copy to a new file.
`docs_create`	`tbase docs create`	Create a document with a new UUID, in the plant's row shape; journaled and undoable, the plant file is untouched until save.
`docs_update`	`tbase docs update`	Edit a document's fields by UUID or row id (set or remove paths); keeps the row's shape and PropertySync style, journaled and undoable.
`docs_delete`	`tbase docs delete`	Delete a document by UUID or row id; journaled and undoable, the plant file is untouched until save.
`ac_create`	`tbase ac create`	Add an autocomplete value of a type; refuses a duplicate of the same type and value. Journaled and undoable.
`ac_update`	`tbase ac update`	Edit an autocomplete value (type, value or any path) by UUID or row id; journaled and undoable.
`ac_delete`	`tbase ac delete`	Delete an autocomplete value by UUID or row id; journaled and undoable.
`lv_create`	`tbase lv create`	Create a land validation for an addition (empty platValidation unless given); journaled and undoable.
`lv_update`	`tbase lv update`	Edit a land validation (addition or any path) by UUID or row id; journaled and undoable.
`lv_delete`	`tbase lv delete`	Delete a land validation by UUID or row id; journaled and undoable.
`changes_list`	`tbase changes list`	List rows created, updated and deleted in the edit journal (per table, with UUIDs, row ids, ops and changed paths) and recent runs.
`changes_revert`	`tbase changes revert`	Revert journaled changes by op, run or row back to how the row was before (undoable with changes_redo).
`changes_undo`	`tbase changes undo`	Undo the newest run, or one op or run by id; an op can be undone only while it is the newest change to its row.
`changes_redo`	`tbase changes redo`	Redo the run undone last, or one op or run by id; refused if the row changed since it was undone.
`changes_export`	`tbase changes export`	Write the journal's changes to a new batch folder: batch.json (PropertySync batch, updates with top-level id), autocompletes, land validations, deletions, changes.titlebase and a manifest.
`file_save`	`tbase file save`	Save: write a clean plant with every journaled edit applied (untouched rows byte-identical), verified by reopening; to --out or --in-place with a backup.
`index_build`	`tbase index build`	Build the plant's sidecar search index at <file>.tbase/index.db (the plant itself is never changed); skips the work when the index is current unless force is set.
`index_status`	`tbase index status`	Show whether the plant's sidecar search index exists and is current, with its size, document count and build time.

Read tools carry the MCP readOnlyHint. Write tools do not, and they apply directly. Inputs and outputs are listed in the CLI reference; the argument names there are the tool's input fields.

Results and errors

Results are the same JSON the CLI prints with --json. Errors come back as a tool error with a code and a message, for example:

{ "error": { "code": "not_found", "message": "not found: document 99999" } }

Writes, safely

Direct. An agent applies a single record edit directly, with no preview step.
Journaled. Every write is one run in the journal beside the plant, recorded under the agent's name (agent:<client>).
Undoable. changes_undo, changes_redo and changes_revert work by operation, run or row.
The plant is safe. The plant file is not touched until file_save, which writes a new file or keeps a backup.
One writer. A second writer gets a locked error naming the holder.
Mass changes plan first. A change across many records shows counts and samples, then applies in one transaction.
Live in the app. When the workbench app has the plant open, agents write through it, so changes show in the grid and in Activity as they land.