TestToolsListByteCeilings is doing its job, but the core preset is close enough to its ceiling that ordinary documentation work now fails it, and the margin is invisible until it is already gone. Reporting this with numbers rather than proposing a fix, since which way to go is your call.
Where it stands on main today
Measured at 06939fce, go test -run TestToolsListByteCeilings ./internal/mcp:
| preset |
bytes |
ceiling |
headroom |
| agent |
29,332 |
29,700 |
368 (1.24%) |
| loc |
21,039 |
21,350 |
311 (1.46%) |
| core |
96,271 |
96,500 |
229 (0.24%) |
| full |
254,460 |
289,808 |
35,348 (12.20%) |
core is five to ten times tighter proportionally than its siblings, and it is the one that grows whenever any tool description gains a sentence.
How it behaves in practice
While working on #647 I hit it three times in one PR, twice turning CI red:
- Documenting the recursive
dir/* exception in the fidelity_globs schema — the first wording measured 96,690 against the 96,500 ceiling and failed. A shared description costs roughly twice its character count, because two tool registrations carry it.
- Documenting the
dir/* rule in the find_files schema — 96,505, failed by 5 bytes.
- Disclosing the new admission limits, which you asked for in review — 96,745, failed by 245. Headroom at that point was 35 bytes, so there was no wording that both said the required thing and fit. I made room by tightening existing prose in the same constant rather than moving the ceiling, and flagged it in the PR as a judgement call.
That last one is the shape worth naming: a review asked for more documentation and the budget made it impossible, and the only way through was editing text nobody had asked me to touch.
Two things that make it sharper than the number suggests
The margin is invisible in a normal run. The per-preset figures come from t.Logf, so they appear only under -v or on failure. A green CI run prints:
ok github.com/zzet/gortex/internal/mcp 6.040s
Nobody learns there are 229 bytes left until someone spends a review round discovering it.
The assertion reads as a ratchet, not a budget. The failure message is "core preset must shrink below its pre-diet baseline (96500)". A ratchet is the right tool for finishing a diet; once the diet is done, a fixed number that only ever gets closer is a trap for the next person who improves a tool description.
Options, in your hands
- Raise the
core ceiling to restore working room, keeping the ratchet intent for the other presets.
- Keep the ceiling and make the headroom visible — for example fail, or emit a warning line, when any preset drops below some percentage. That is the cheap half: it turns "you are 5 bytes over" into "you have 229 bytes, plan accordingly" one PR earlier.
- Decide the budget is correct and that schema prose has reached its intended limit, in which case saying so in the test's message would save the next person the round I spent.
Happy to send whichever you pick; the middle one is a few lines.
TestToolsListByteCeilingsis doing its job, but thecorepreset is close enough to its ceiling that ordinary documentation work now fails it, and the margin is invisible until it is already gone. Reporting this with numbers rather than proposing a fix, since which way to go is your call.Where it stands on
maintodayMeasured at
06939fce,go test -run TestToolsListByteCeilings ./internal/mcp:coreis five to ten times tighter proportionally than its siblings, and it is the one that grows whenever any tool description gains a sentence.How it behaves in practice
While working on #647 I hit it three times in one PR, twice turning CI red:
dir/*exception in thefidelity_globsschema — the first wording measured 96,690 against the 96,500 ceiling and failed. A shared description costs roughly twice its character count, because two tool registrations carry it.dir/*rule in thefind_filesschema — 96,505, failed by 5 bytes.That last one is the shape worth naming: a review asked for more documentation and the budget made it impossible, and the only way through was editing text nobody had asked me to touch.
Two things that make it sharper than the number suggests
The margin is invisible in a normal run. The per-preset figures come from
t.Logf, so they appear only under-vor on failure. A green CI run prints:Nobody learns there are 229 bytes left until someone spends a review round discovering it.
The assertion reads as a ratchet, not a budget. The failure message is "core preset must shrink below its pre-diet baseline (96500)". A ratchet is the right tool for finishing a diet; once the diet is done, a fixed number that only ever gets closer is a trap for the next person who improves a tool description.
Options, in your hands
coreceiling to restore working room, keeping the ratchet intent for the other presets.Happy to send whichever you pick; the middle one is a few lines.