Ottorev — Review MCP Server
The memory an engineering assistant needs. This local stdio MCP server records
names, notes, tags, and decisions against an exact CAD revision in SQLite, so
an assistant can pick up where it left off — remember that a face is the mating
surface, that a tolerance callout is tight, or that a review concluded hold
with the requirements behind it.
It never opens the CAD file: it stores the revision the caller supplies and
compares it on recall, so it works on a laptop with no CAD software and no other
server running.
Quick start
Requires Node.js 26+ and npm. From this repository:
For any MCP client:
REVIEW_MCP_DB_PATH defaults to ./review-mcp.db; parent directories are created
automatically. Records persist across restarts — protect and back up the database
as application data.
Tools
Results provide structured content and text; tool failures set MCP isError.
Writes change local records; the client controls when to request those mutations.
The server also advertises engineering-review prompts that compose with a geometry
server, while the core record operations run on their own.
Artifact and subject semantics
An input artifact contains revision (sha256: plus 64 lowercase hex digits),
format: "step", and optional URI and units:
Supply the actual revision from the producer; the example digest is illustrative.
A URI groups records by locator; without a URI, the revision is the lookup key.
uri accepts either a URI or a plain filesystem path, because a path is what a
caller usually has in hand:
Both spellings address the same records: a path is normalised to a file: URI
before anything is stored or matched. A relative path resolves against the server
working directory. Normalisation never opens the file, so a record can be written
for an artifact this server cannot read.
An entity filter is revision-scoped; a text or tag filter is not. An entity ID
denotes different geometry in a different revision, so recall and
recall_decisions match an entity_id only against records written for the
supplied revision, and match it exactly — face:3 does not match face:30. Names,
notes, subjects, and tags are matched across revisions, which is how an earlier
record is found at all, and every result says whether it is stale.
Each returned record contains one artifact reference, its entity IDs, and the ID
scheme. The entity IDs are opaque outside that scheme and revision.
Decision records
A review names or annotates geometry. A decision is the other thing a review
produces: a disposition about a revision, and the basis it rests on.
One basis item is one requirement-check, and it answers for itself:
unresolved and conflicting are first-class outcomes: a decision that carries
them is a complete record of where the work stands, not a failure to decide. A
basis item is refused when it cannot answer for itself — no source, or a state of
unresolved/conflicting with no question.
Three properties matter more than the shape:
- A decision is bound to a revision. The revision is part of its key, so the
same subject at the same revision is recalled rather than reached again, and a
decision made against a different revision comes back marked
stale: true,
still carrying the revision it belongs to.
- Face IDs do not travel between revisions. Topological naming is unsolved in
OCCT, and this API does not pretend otherwise: an
entity_id filter matches only
the revision that produced the ID.
- Verdicts are what make a requirement agreed. Recording a
verdict turns a
line the assistant proposed into one the engineer accepted or rejected — the
record of how much authority the assistant actually earned.
A stored decision is the caller's own account: the requirement as stated and the
evidence as quoted. This server never measures anything, so a recalled decision is
a record of what was concluded, not a measurement cache — Geometry remains the
authority for numbers.
Limits
Review stores authored context: names, notes, and tags bound to an artifact
revision, and decisions with the requirements they rest on. It does not store
verified measurements, a complete immutable audit history, or authoritative
approval records, and it does not compute geometry, run simulation, or decide
manufacturability. Staleness is judged from a revision the caller supplies; Review
never opens the CAD file.
There are no schema migrations: the database is a working file, and a changed
table shape means deleting it. The server reports the version mismatch rather than
guessing at a transformation.
Development
Requires Node.js 26+ and just. A Nix flake and
.envrc provide the toolchain; run direnv allow after changing either.
Server logs go to stderr as newline-delimited pino JSON. MCP_LOG_LEVEL
(debug|info|warn|error), MCP_LOG_FORMAT=human, and MCP_TRACE_ID tune
them; secret-like fields are redacted.
Packaging
npm pack builds first and includes compiled runtime code, package metadata, and
this README. Tests and source maps are excluded. Install the tarball to check the
review-mcp executable with a compatible MCP client. The server serves both
protocol eras: the 2025-11-25 handshake that stock MCP hosts negotiate, and the
2026-07-28 envelope through server/discover.
License
MIT. Third-party notices: THIRD_PARTY_NOTICES.md.
