test(sdk): the server knows its own name, and the tool never hears it

B4 asked whether this side gets server identity for free in tool names.
It does not. create_sdk_mcp_server emits the bare name; mcp__ appears in
0 of the package's 24 files, with create_sdk_mcp_server itself as the
positive control that the query can find. Identity lives on the config
and on Server.name, disjoint from anything the tool list carries.

The prefix does exist -- 178 times, inside the CLI bundled with the SDK.
But that was read off the artifact, not observed in a run, and observing
it would cost the one live query() this repo does not spend. So the
finding is scoped to the seam we can actually hang a recorder on, and
the note says so rather than claiming the wider thing.

Value-proved, not asserted: mutating the SDK to namespace at construction
time turns 3 of the 4 tests red, and the one that stays green is the
population control, which should. The SDK file was restored byte-identical.

Same answer as the MAF sibling, arrived at after 2026-08-09 -- so it is
recorded as a measurement, not as independent convergence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-08-25 08:33:07 +02:00
commit 56164f5f07
2 changed files with 159 additions and 3 deletions

View file

@ -44,10 +44,38 @@ kandidater, ikke som planlagt arbeid:
- (a)/(i) `unquote_scalar`
- `mandate.py`
- A5 — TO halvdeler
- B4 `ToolCallRecorder`
- ~~B4 `ToolCallRecorder`~~ — **BESVART 2026-08-25, se under**
**B4 spør OSS:** gir Claude-SDK-siden serveridentiteten gratis? MAF får verktøynavn UTEN
server-prefiks. **Ikke målt — ikke gjett.** Åpent hos søskenet: MAF S3.4 (F10).
**B4 spurte OSS:** gir Claude-SDK-siden serveridentiteten gratis? MAF får verktøynavn UTEN
server-prefiks. Åpent hos søskenet: MAF S3.4 (F10).
### B4 — svaret er NEI (målt 2026-08-25, offline, mot `claude-agent-sdk` 0.2.139)
`create_sdk_mcp_server` emitterer det **bare** verktøynavnet. Serveridentiteten finnes — på
`McpSdkServerConfig["name"]` og `Server.name` — men den er **disjunkt fra hvert navn
verktøylista bærer**. Strengen `mcp__` forekommer i **0 av 24** Python-filer i pakken
(positiv kontroll: `create_sdk_mcp_server` blir funnet av samme spørring, så spørringen KAN
finne). Konstruksjonssiden namespacer altså ingenting: en `ToolCallRecorder` hengt der ser
`record_call`, ikke `mcp__tool_call_recorder__record_call`, og må få servernavnet fortalt.
Det er **samme pris som søskenet betaler**.
**Ærlig grense — hva målingen IKKE sier.** Den navnerommede formen `mcp__<server>__<tool>`
eksisterer: den bygges inne i CLI-en som følger med SDK-en (`_bundled/claude`, 178 literale
`mcp__`-forekomster, konstruksjonen på formen `` `mcp__${…}__${…}` ``). Det er **lest av
artefaktet, ikke observert i en kjøring hos oss** — å se den emittert krever en live
`query()`, som både D6-kostnadsregelen og suitens offline-invariant forbyr. Funnet er derfor
scopet til den sømmen vi faktisk kan bygge på: den in-process konstruksjonssiden. Prefikset
finnes på et lag vi bevisst ikke kjører, og et lag vi ikke kjører er ikke en søm vi kan feste
en recorder i.
**Pinnet av** `tests/test_sdk_tool_namespace_loadbearing.py` (4 tester). Value-beviset er
kjørt, ikke påstått: SDK-en ble mutert til å namespace ved konstruksjon (`"name":
f"mcp__{name}__{tool_def.name}"`) — **grønn før, 3 av 4 røde etter**, og den ene som forble
grønn er nettopp populasjons-kontrollen, som den skal. SDK-fila ble restaurert byte-identisk
(sha256 verifisert begge veier).
**Datering (D7-rammen):** dette er arbeid ETTER 2026-08-09 og skal **ikke** leses som
uavhengig konvergens selv om svaret er identisk med søskenets.
Rammen rundt køen: å lese søskenets kode er tillatt (`3bdf7f0`), men kopiering skal kun skje
der det tjener løsningen, aldri som snarvei. **Uavhengighets-beviset er DATERT** t.o.m.