# A lighter MCP server, measured — 26 October 2026
After the 5 runs per stack (`src/content/benchmark.json`, bench runs 3–7), mmo.core's MCP server was made to answer
less (mmo.core `2a4dd1a5`): short `initialize` instructions instead of the whole coding guide, `resources/read
#` for one section of a page, JSON on one line, a shorter `list_packages`; and the project template's
`AGENTS.md` pointed at section reads (mmo.admin `0fb7ecc`). Then 3 more MMOFramework runs by the same protocol
(bench runs 8–10, a starting point made again with the new template). Not recorded in `benchmark.json`.
## What it changed
| | runs 3–7 (before) | runs 8–10 (after) |
|---|---|---|
| tokens, median | 7.16 M | 8.16 M |
| turns, median | 56 | 59 |
| minutes, median | 5.6 | 5.9 |
| cost, median | $3.26 | $3.77 |
| done and tested | 5 of 5 | 3 of 3 |
| the first request's context | 35.6 k | 35.4 k |
| what the MCP server answered, per run | 32.6 k tokens | 39.3 k tokens |
| `search_documentation` calls, per run | 5.2 (10.4 k tokens) | 9.3 (19.2 k tokens) |
**No saving.** Three runs vary as much as five did (5.9 to 8.5 M tokens), and nothing moved beyond that:
- **The instructions were not what an agent carries.** 16 KB of instructions cut to 1.6 KB moved the first request
by 240 tokens: Claude Code does not put a server's `instructions` in the agent's context whole. The estimate of
"4 000 tokens carried by every request" was wrong.
- **A section read was used where the template named one** (mmo.pdo's worked example, in every run), and not
elsewhere: Pages.md was still read whole in every run, at the uri search gave.
- **Searches are now the largest cost**: an agent told to ask first asks more, and each answer carries up to 3
whole sections (about 2 000 tokens).
## What would
1. **A search answer that costs less**: the best match with its section, the others as excerpts with the uri of
their section (`page#heading`), so that reading more is reading a section.
2. **Fewer turns**, which is where the difference with Laravel and Symfony is (56 against 35 and 41): the agent
still writes scratch scripts to try mmo.pdo and reads a few framework files. Whatever the framework would make
an agent of another stack write from memory is the measure.
## Second try: cheaper searches (bench runs 11–13)
mmo.core then answered a search with one section, not three: the best match carries its section, the others their
`heading` and `sectionUri` (`page#heading`, read alone). At most 20 matches instead of 40, 3 of one page; at equal
rank, the pages of a library the query names (`pdf`: mmo.pdf) and the pages written for a reader before the
reference mmo.doc generates -- "pdf" had filled its 40 places with generated pages, mmo.pdf's overview in none.
Same starting point as runs 8–10.
| | runs 3–7 | runs 8–10 | runs 11–13 |
|---|---|---|---|
| tokens, median | 7.16 M | 8.16 M | 6.38 M |
| turns, median | 56 | 59 | 53 |
| minutes, median | 5.6 | 5.9 | 6.0 |
| cost, median | $3.26 | $3.77 | $3.08 |
| done and tested | 5 of 5 | 3 of 3 | 3 of 3 |
| a search's answer, mean | 2 000 tokens | 2 060 tokens | 1 170 tokens |
| searches per run | 5.2 | 9.3 | 6.3 |
| what the MCP server answered, per run | 32.6 k | 39.3 k | 31.6 k |
A search costs 40 % less, and section reads are used (11 of the 30 reads; Pages.md's form section in every run).
The runs are 11 % cheaper than the 5 of the benchmark at the median -- within what three runs vary (5.6 to 8.5 M
tokens), so a direction, not a measure. What the server answers did not shrink as much as a search did: agents read
whole pages still (mmo.pdo's Repository.md and both overviews in every run, Pages.md whole after its section).