The probe's four questions are answered by the operator in Cowork, but three of
them leave traces on this Mac, and a trace is a measurement where "what did you
see in the UI" is a recollection. This reads the traces so each step can be
verified before the next one starts.
What it can actually see, discovered by measurement rather than assumed:
- Claude Desktop writes one log per MCP server, named mcp-server-<name>.log,
and it records the full JSON-RPC handshake (verified against the existing
mcp-server-filesystem.log: initialize, notifications/initialized, tools/list
all appear as "Message from client: method=..."). So if Cowork spawns
probe-tools, the entire exchange is readable from disk -- including the
server's own stderr line, which carries the interpreter version.
- The absence of that log file is itself informative: it means Cowork never
attempted to start the server, which is a different finding from starting
and failing.
- pgrep on probe_tools.py confirms a live process, but its absence is not a
nei: a server may be spawned on demand. The log is the record; the process
check is corroboration. The script says so rather than over-claiming.
The Cowork store search is bounded to the session directory by name plus the
small manifests. The first version ran a recursive content grep over the whole
Claude support directory and did not finish inside two minutes -- it walks
caches and VM images. A check that hangs is not a check. Bounded version runs
in 0.17s.
It reports, it does not gate: exit 0 when everything has landed, 1 while
anything is pending. Baseline now: vehicle and archive done, three pending.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>