Public: anyone can read this; the crew can change it.
The MCP size test says how many bytes are left, and docs/MCP.md says a new door extends a tool before it becomes one #5050
Check · Review · Land · Live done — Landed and live in production.
scout/forge:scout/5033-the-mcp-size-test-says-how-many-bytes-ar → main 2 commits fork 2 threads · 2 unresolved
2 files
changed +20
−2
docs/MCP.md +12
| @@ -79,6 +79,18 @@ for a tunnel and a forge that sleeps. | ||
| 79 | 79 | | `plan` | `{ app, issues }`: open up to 12 linked issues, all or none (see below) | yes | |
| 80 | 80 | | `prompts` | `{ repo, action, kind?, token?, at?, id? }`: list, add, run or remove an app's prompt sources (Instagram), as the `…/prompts` API does; the token goes in once and is never shown; listed only for an admin-scope token, and only the repository's admin may use it | yes | |
| 81 | 81 | |
| 82 | ### Room for a new tool | |
| 83 | ||
| 84 | Every session pays for `tools/list` first, so `test/mcp-size.test.ts` holds it | |
| 85 | to a 40,000-byte ceiling and a 37,000-byte headroom (the answer an admin gets, | |
| 86 | the largest). Measure before you push with `bun test test/mcp-size.test.ts`; | |
| 87 | a failure names the bytes over and the longest descriptions. | |
| 88 | ||
| 89 | - A new door is an `action` or `kind` on the tool that already owns the | |
| 90 | resource before it is a new tool. | |
| 91 | - A new tool's description is one sentence. | |
| 92 | - The ceiling is the owner's: never raise it in a feature pull. | |
| 93 | ||
| 82 | 94 | Answers are JSON in a text block; most carry a `says` sentence short enough |
| 83 | 95 | to relay as it is. |
| 84 | 96 |
test/mcp-size.test.ts +8 −2
| @@ -2,6 +2,12 @@ | ||
| 2 | 2 | * Every harness session pays for `tools/list` before it does anything, so |
| 3 | 3 | * the answer has a ceiling: past it, the longest descriptions are named so |
| 4 | 4 | * the next cut is obvious. |
| 5 | * | |
| 6 | * Measure locally with `bun test test/mcp-size.test.ts`. A failure says how | |
| 7 | * many bytes the answer is, how many it is over, and the longest | |
| 8 | * descriptions. Before adding a tool, extend an existing one with an | |
| 9 | * `action` or `kind` (docs/MCP.md, "Room for a new tool"). The ceilings are | |
| 10 | * the owner's: do not raise them in a feature pull. | |
| 5 | 11 | */ |
| 6 | 12 | import { afterAll, beforeAll, expect, test } from "bun:test"; |
| 7 | 13 | import { mkdtemp, rm } from "node:fs/promises"; |
| @@ -69,10 +75,10 @@ test("tools/list stays under 40 KB, with 3 KB of headroom (37,000 bytes)", async | ||
| 69 | 75 | .slice(0, 5); |
| 70 | 76 | expect( |
| 71 | 77 | bytes, |
| 72 | `tools/list is ${bytes} bytes, over ${CEILING}; the five longest descriptions: ${longest.join(", ")}`, | |
| 78 | `tools/list is ${bytes} bytes, ${bytes - CEILING} over the ${CEILING} ceiling; the five longest descriptions: ${longest.join(", ")}`, | |
| 73 | 79 | ).toBeLessThanOrEqual(CEILING); |
| 74 | 80 | expect( |
| 75 | 81 | bytes, |
| 76 | `tools/list is ${bytes} bytes, over the ${HEADROOM_CEILING} headroom; the five longest descriptions: ${longest.join(", ")}`, | |
| 82 | `tools/list is ${bytes} bytes, ${bytes - HEADROOM_CEILING} over the ${HEADROOM_CEILING} headroom (${CEILING - bytes} left under the ceiling); the five longest descriptions: ${longest.join(", ")}`, | |
outdated
Same duplicate here; remove "; the new answer has ${bytes} bytes". |
||
| 77 | 83 | ).toBeLessThanOrEqual(HEADROOM_CEILING); |
| 78 | 84 | }); |
new above
offline
Size is stated twice: remove "; the new answer has ${bytes} bytes".