---
name: feedback-mcp-lens-intercept-input-agnostic-2026-08-15
description: mcp-lens の intercept は upstream MCP server (benchtop_mcp.py) を子プロセスで抱える限り、 呼び出し client の 入口 (Claude Desktop chat / Cowork remote-devices bridge / 別 MCP client) を 問わず 効く。 A 柱 usage phase の 母集団は 想定より広い
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 4a4b0c7d-219a-44f0-8981-7680bf9843ec
  modified: 2026-08-14T21:54:10.603Z
---

# mcp-lens intercept は 入口非依存

## 規則

mcp-lens (`mcp_lens.py`) が **upstream MCP server (benchtop_mcp.py) を 子プロセスとして 抱えている限り**、 その upstream への 全 tool call は 呼び出し client の 入口を問わず lens.jsonl に record + hash chain に組込まれる。

**Why**: mcp-lens は stdin/stdout stdio transport 層 で JSON-RPC を 中継する design。 「誰が呼んだか」 は 見ておらず、 「upstream child process へ 流れた全 tool/call」 を 記録する。 client 側 (Claude Desktop / Cowork remote-devices bridge / MCP Python client / etc) は 中継者としての mcp-lens に接続しているだけ = 入口の 種類に非依存。

**How to apply**:
- A 柱 usage phase の 「1 週間 real usage data 収集」 の 母集団は **Claude Desktop chat 経由呼び出し に 限らない**。 Cowork session 側から remote-devices bridge 経由で 呼ばれた case (2026-08-15 発火例、 seq 3 list_ports) も 同じく record される。 週次分析の 母集団は より広い前提で 見る。
- 逆に、 「Claude Desktop chat 経由の 使用頻度」 だけ 見たい場合は lens.jsonl の record だけでは 判別できない (追加 field が必要)。 現状の record 設計 (tool + args + ms + error + result_bytes) には 呼び出し元 client 情報が含まれない。 判別が必要になった時点で mcp-lens v0.2 で client_hint 追加候補。
- 別 MCP client を 立ち上げて 同 upstream に 接続すると **race** が起きる (2026-08-15 verify で Claude Desktop instance × 2 個 + fresh spawn 1 個 が 並行動作した case、 hash chain は 独立 log file で 別々に verify)。 fresh spawn で verify する時は 別 log file 指定推奨。

## 発火 incident

2026-08-15 mcp-lens A 柱 起動 arc の 稼働 verify で 判明:
- 藤本さん Claude Desktop で benchtop tool 呼び出し 依頼 → 実際には Cowork session の remote-devices bridge 経由で `list_ports` 発火
- 想定 (Claude Desktop chat 経由でしか record されない) と 異なり、 lens.jsonl に seq 3 として 正常記録 + hash chain 継続
- 「想定より強い結果」 = pause state memory で 「稼働 4 signal verify」 の 想定範囲を 超えた positive finding

## 副次 finding: error record は 2 sub-category

同 verify で 追加判明:
- **`error = "tool_error"`** (`is_error=True` branch、 line 265-266) = upstream tool 内 ValueError 等 の tool-level 検証エラー。 FastMCP が 例外を CallToolResult(is_error=True) に wrap するため、 型情報は 落ちる。
- **`error = "{ExceptionType}: {msg}"`** (Exception catch branch、 line 267-268) = transport 層 failure (connection drop、 protocol violation 等)。 型情報 残る。 実発火頻度は 低い前提。

WEEK_NOTES.md template の 週次 error 分析で この 2 sub-category を 別々に 数える推奨 (混ぜると 稀な transport failure が tool 検証エラー に埋もれる)。

## 関連

- [[project-mcp-lens-a-pillar-launch-pause-2026-08-15]] (発見 session、 稼働 verify context)
- [[feedback-success-signal-decoupled-from-operational-state-2026-08-14]] (「想定より強い結果」 も signal-operational 分離の 逆側、 想定を 事実で 更新する discipline)
- [[feedback-motivation-ground-not-user-pleasing-but-agent-operational-2026-08-15]] (想定と 実測が違った時、 想定を 温存せず 事実側に 寄せる = agent-operational anchoring)