rei-meta-mcp

コネクタ群の上に立つメタ層。個々の MCP コネクタを 対象、対象へのアクセス経路を 射 とみなし、その構造を扱う。

Phase 1 の唯一の実用目的は 整合性検査 (coherence check) — 同じ対象を指す複数のソース間で内容が一致しているかを機械的に突き合わせる。

なぜ作ったか

2026-08-19、rei-memory-mcp の実装過程で SEED_KERNEL が 1,677 vs 1,675 で 11 日間ずれたまま気づかれていなかったことが判明した。気づけたのは人間が両方の数字を偶然見比べたからで、機械には検出手段が無かった。

このコネクタの最初の仕事は、これを機械が先に見つけることである。詳細は docs/incident-2026-08-19.md。

Related MCP server: Code-Oracle

提供する tool (3 本)

meta_list_sources(object_name?: str)

登録済みの source を列挙し、各々の到達状態・件数・git HEAD ハッシュ (freshness の手がかり) を返す。

meta_check_coherence(object_name: str, detail: bool = False)

同一対象を指す source の指紋を突き合わせ、以下のいずれかの verdict を返す:

§4 中核ルール: 「到達できなかった」は「一致した」ではない。unreachable と single_source は常に警告として surface される。

detail=True で不一致 ID の実リスト (最大 100 件) を返す。

meta_compose(from_source: str, to_source: str)

Phase 1 は registry 内の output_schema / input_schema 文字列突合のみ。実スキーマ推論は Phase 3 以降。

Phase 1 でやらないこと

• 自動修復 (意図的な除外。どちらが正しいかの判断は人間が行う)

• 検査履歴の永続化 (Phase 2)

• スキーマ推論 (Phase 3)

• 関手・随伴・モナド等の圏論構成 (必要になったときに)

現時点の registered source

config/sources.example.yaml を参照:

Install & 使用

uv pip install -e ".[dev]"
cp config/sources.example.yaml config/sources.yaml   # パスを埋める
uv run pytest                                        # 全 PASS を確認
uv run rei-meta-mcp                                  # stdio で MCP server 起動

registry のパスは環境変数 REI_META_MCP_REGISTRY で上書き可能。

Honest scope

1. 検出のみ、修復は行わない — 判断を人間の外に出さない

2. partial fingerprint の source (mcp_stdio) 間の一致は「不一致がない」ことの確認であって「完全一致」の証明ではない (content_hash レベルで見られない部分がある)

3. 圏論用語は 5 つだけ (対象・射・等化子・合成・恒等射) 荷重を負う。他は避ける

4. 現状 3 source の Phase 1 spike。対象が増えるほど価値が増す構造

5. Phase 2 (履歴・定期実行・通知) と Phase 3 (スキーマ推論・射の一般化) は、Phase 1 が実運用で機能した後に判断

License

AGPL-3.0-or-later.

関連

• docs/incident-2026-08-19.md — 事故の記録

• tests/test_incident_2026_08_19.py — 事故を再現するテスト