Ottorev — Review MCP Server

Ottorev — レビュー MCP サーバー

エンジニアリングアシスタントに必要な記憶を提供します。このローカルの stdio MCP サーバーは、SQLite に正確な CAD リビジョンに関連付けて名前、メモ、タグ、判断を記録します。これにより、アシスタントは中断したところから作業を再開し、面が嵌合面であること、公差の指示が厳しいこと、あるいはレビューで根拠となる要件とともに 保留 と結論づけたことを記憶できます。

CAD ファイルを開くことはありません。呼び出し元から渡されたリビジョンを保存し、呼び出し時に照合するため、CAD ソフトウェアも他のサーバーも起動していないノートパソコンでも動作します。

クイックスタート

Node.js 26 以降と npm が必要です。このリポジトリで次を実行します。

npm install
npm run build
REVIEW_MCP_DB_PATH=/absolute/path/to/review.db npm start

任意の MCP クライアントでは、次を実行します。

{
  "mcpServers": {
    "review": {
      "command": "node",
      "args": ["/absolute/path/to/review-mcp-server/dist/src/index.js"],
      "env": { "REVIEW_MCP_DB_PATH": "/absolute/path/to/review.db" }
    }
  }
}

REVIEW_MCP_DB_PATH のデフォルトは ./review-mcp.db です。親ディレクトリは自動的に作成されます。レコードは再起動後も保持されるため、アプリケーションデータとしてデータベースを保護し、バックアップしてください。

ツール

ツール	動作
remember	エンティティセットに関連付けて、名前付きフィーチャー（再度記憶すると置き換え）または匿名メモ（再度記憶すると追記）をタグとともに保存します。どちらの処理が行われたかを呼び出し元が判別できるよう、replaced を返します。
recall	アーティファクト、エンティティ、フリーテキスト、またはタグで検索します。指定された現在のリビジョンと照合し、各レコードに古いというマークを付けます。すべての結果を取得するには、ページネーションに従ってください。
remember_decision	リビジョンについて下された判定とその根拠を保存します。要件チェックごとに1行を記録し、情報源、証拠、状態、エンジニアの判定を指定します。同じ対象について再度記憶すると、既存の記録が置き換えられます。
recall_decisions	判断を新しい順に返し、別のリビジョンに属するものには古いというマークを付けます。entity_id フィルターは、指定されたリビジョンにのみ一致します。
forget	名前付きフィーチャー、エンティティを指定した匿名メモ、または対象を指定した判断を削除します。べき等です。

結果には構造化コンテンツとテキストが含まれます。ツールの実行に失敗すると、MCP の isError が設定されます。 書き込みによってローカルのレコードが変更されます。変更を要求するタイミングはクライアントが制御します。 また、このサーバーはジオメトリサーバーと組み合わせて使えるエンジニアリングレビュー用プロンプトを提供しますが、基本的なレコード操作は単独で実行できます。

アーティファクトと対象のセマンティクス

入力アーティファクトには、revision（sha256: に続く64桁の小文字の16進数）、 format: "step"、および任意の URI と単位が含まれます。

{
  "revision": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "uri": "file:///work/part.step",
  "format": "step",
  "units": "mm"
}

生成元から実際のリビジョンを指定してください。例のダイジェストは説明用です。 URI はロケーターごとにレコードをグループ化します。URI がない場合は、リビジョンが検索キーになります。

uri には URI または通常のファイルシステムパスを指定できます。呼び出し元が通常手元に持っているのはパスだからです。

{ "uri": "/work/part.step" }

どちらの表記でも同じレコードを参照します。パスは、保存または照合の前に file: URI に正規化されます。相対パスはサーバーの作業ディレクトリを基準に解決されます。正規化の際にファイルを開くことはないため、このサーバーが読み取れないアーティファクトについてもレコードを書き込めます。

エンティティフィルターはリビジョンの範囲内で適用されますが、テキストフィルターやタグフィルターはそうではありません。 エンティティ ID が示す形状はリビジョンが異なると異なるため、recall と recall_decisions は、指定されたリビジョン用に書き込まれたレコードに対してのみ entity_id を照合し、完全一致で照合します。face:3 は face:30 に一致しません。名前、メモ、対象、タグはリビジョンをまたいで照合されます。これにより以前のレコードも見つけられ、各結果には stale かどうかが示されます。

返される各レコードには、1つのアーティファクト参照、そのエンティティ ID、および ID スキームが含まれます。エンティティ ID は、そのスキームとリビジョンの外では不透明な値です。

判断レコード

レビューでは形状に名前を付けたり、注釈を付けたりします。レビューが生成するもう1つのものが判断です。これはリビジョンに対する処置と、それを支える根拠です。

根拠項目1つは要件チェック1つに相当し、それ自体で次の問いに答えます。

field	what it carries
requirement	検証できる形で示された、満たすべき要件
source	要件の出所：model-pmi、drawing、shop-spec、supplier-cert、standard、prior-decision、engineer-stated、または assistant-proposed
sourceDetail	読者が確認できる条項、注記番号、または文書
evidence	出所情報を添えて引用した、報告された値
state	satisfied、violated、unresolved、conflicting、または not-applicable
question	unresolved および conflicting の場合は必須：解決に必要な情報
faces	このリビジョンで対象となる形状。項目が部品全体に関する場合も常に存在し、その場合は空
verdict	エンジニアによる accepted / rejected の判断。理由が示されている場合はその理由も含む

unresolved と conflicting は、正式な結果として扱われます。これらを含む判断は、作業の現状を示す完全な記録であり、判断の失敗ではありません。根拠項目自体で問いに答えられない場合、その項目は受け付けられません。たとえば、source がない場合や、unresolved / conflicting でありながら question がない場合です。

形状よりも重要な特性が3つあります。

• 判断はリビジョンに紐付けられます。 リビジョンはキーの一部です。そのため、同じリビジョンの同じ対象は再び判断するのではなく呼び出され、異なるリビジョンに基づく判断は stale: true として返されますが、紐付いているリビジョンは引き続き示されます。
• 面 ID はリビジョン間で引き継がれません。 OCCT ではトポロジカルネーミングは未解決の問題であり、この API はそれを解決済みであるかのようには扱いません。entity_id フィルターは、その ID を生成したリビジョンに対してのみ照合されます。
• 要件に合意したことを示すのは判定です。 verdict を記録することで、アシスタントが提案した項目は、エンジニアが受け入れた、または却下した項目になります。これは、アシスタントが実際にどれだけの権限を得たかを示す記録です。

保存される判断は、呼び出し元自身による説明です。提示された要件と、引用された根拠が記録されます。このサーバーが測定を行うことはないため、呼び出された判断は結論の記録であり、測定値のキャッシュではありません。数値の根拠となるのは Geometry です。

制限事項

Review には、作成者が記録したコンテキストが保存されます。具体的には、成果物のリビジョンに紐づく名前、メモ、タグと、根拠となる要件を伴う判断です。検証済みの測定値、完全かつ変更不可能な監査履歴、正式な承認記録は保存されません。また、ジオメトリの計算、シミュレーションの実行、製造可能性の判定も行いません。古さは呼び出し元が指定したリビジョンを基準に判断します。Review が CAD ファイルを開くことはありません。

スキーマのマイグレーションはありません。データベースは作業ファイルであり、テーブル構造が変更された場合は削除する必要があります。サーバーは変換方法を推測せず、バージョンの不一致を報告します。

開発

Node.js 26+ と just が必要です。Nix flake と .envrc でツールチェーンを利用できます。どちらかを変更した後は direnv allow を実行してください。

レシピ	目的
just setup	依存関係をインストールします。
just dev	stdio 経由で TypeScript を実行します。
just build	dist/ にコンパイルします。
just test	単体テストを実行します。
just lint	oxlint を実行します。
just fmt	Prettier でフォーマットを書き換えます。
just fmt-check	フォーマットを検証します。
just typecheck	tsc --noEmit を実行します。
just check	fmt-check + lint + typecheck + test を実行します。
just clean	データベースを保持したまま、コンパイル済みの出力を削除します。

サーバーログは、改行区切りの pino JSON 形式で stderr に出力されます。MCP_LOG_LEVEL （debug|info|warn|error）、MCP_LOG_FORMAT=human、MCP_TRACE_ID で ログを調整できます。シークレットと思われるフィールドは秘匿されます。

パッケージング

npm pack は最初にビルドを行い、コンパイル済みのランタイムコード、パッケージメタデータ、 この README を含めます。テストとソースマップは除外されます。tarball をインストールし、 互換性のある MCP クライアントで review-mcp 実行ファイルを確認してください。サーバーは 両方のプロトコル世代に対応しています。標準の MCP ホストがネゴシエートする 2025-11-25 ハンドシェイクと、server/discover 経由の 2026-07-28 エンベロープです。

ライセンス

MIT。サードパーティの通知：THIRD_PARTY_NOTICES.md。