Claude Code MCP Behavior Analysis

Claude Code MCP Behavior Analysis

Results from 15 tests against a minimal Cord MCP server. Tested: Claude Code 2.1.37, 2026-02-18.

**Note:** These tests were run against the v0.3 API which used separate `spawn`/`fork` primitives and `blocked_by`. The protocol has since been unified into `create` with `needs` (v0.4). The behavioral observations — self-decomposition, authority handling, error recovery — still apply.

Summary

#	Test	Pass	Notes
1	read_tree	YES	Called unprompted when asked about state
2	Self-decomposition (spawn)	YES	Created 5 nodes with correct blocked_by deps
3	Fork vs spawn choice	YES	Correctly chose fork for context-heavy, spawn for stateless
4	ask (human elicitation)	YES	Used all params: target, question, options, default, timeout
5	Goal chain injection	YES	Read tree for context, produced substantive output
6	Authority violation (stop sibling)	YES	Got rejected, escalated via ask parent instead
7	Authority (stop own child)	YES	Succeeded immediately
8	Modify pending node	YES	Changed goal and prompt
9	Answer elicitation	YES	Read tree first, then answered with exact value
10	Complex decomposition (deps)	YES	6 nodes, 3 parallel → analysis → draft → review
11	Result reference awareness	YES	Read results from completed node, explained data flow
12	Pause + resume	YES	Both calls in sequence
13	Error handling (modify active)	INTERESTING	Tried modify, failed, tried pause+modify, failed, then stop+respawn
14	Stdout as structured JSON	YES	Clean JSON, no markdown wrapping, no tool calls needed
15	Ask parent (agent-to-agent)	YES	Correct target, good question framing

**15/15 passed.** No failures. One notably interesting behavior (test 13).

---

Key Findings

1. Tool discovery is reliable

Claude calls `read_tree()` as its first action in almost every test (12 of 15). It understands the tree structure from JSON and reasons about it correctly. It never needed to be told which tools exist — MCP tool descriptions were sufficient.

2. Self-decomposition works naturally

When told to decompose, Claude:

• Creates sensible subtask breakdowns (3-6 nodes)
• Uses blocked_by correctly for dependencies
• Writes detailed prompts for each child node
• Reads the tree after creating nodes to verify

It does NOT need special prompting to decompose. The instruction "break this into subtasks" + access to `spawn()` is enough.

3. Fork vs spawn distinction is understood

When given a scenario with both context-heavy and stateless subtasks, Claude correctly chose:

• fork for the analysis that needs accumulated research context
• spawn for the price-fetching task that just needs tickers

It explained the reasoning using the exact mental model from the spec (contractor vs team member, restart cost, context inheritance).

4. Authority model wor