archetech / archon / 29534279341

90%

main: 90%

Pull #734

github

feat: implement the MCP resources capability (#725)

#721 shipped an embedded resource block from archon_get_asset_file without the
resources capability the spec says such a server SHOULD implement, leaving the
DID in that block decorative: accurate, but nothing could resolve it.

The server now serves asset DIDs as resources. An asset DID is already a URI,
so it is the resource URI verbatim -- the same one the tool emits. A test
registers both surfaces on one server and feeds the tool's own URI back into
resources/read, which is what shipping the block without the read path left
unproven.

resources/list is empty by design and the template opts out via the SDK's
explicit `list: undefined`. Enumerating every asset would hand the wallet's
contents to any connected client, read or not; reads are by a DID the caller
already holds and disclose nothing that resolving it would not.
resources/templates/list still advertises did:cid:{id}, so the path stays
discoverable. What a filtered list should expose is left open.

getFile is tried first rather than branching on the asset kind: an image asset
stores { file, image }, so it covers both, and binary assets are what a client
holding one of these URIs actually has. That is one resolve for the common
case; the JSON fallback pays a second.

requireKeymaster moves to runtime.ts -- resources are wallet-backed and must
fail the same way tools do when there is no passphrase.

This does not yet switch large files to resource_link, which is the payoff the
read path unblocks: get_asset_file inlines base64 into the model's context
today, and a 1 MB file is ~350k tokens. That needs a size threshold and is
worth its own change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2944 of 3492 branches covered (84.31%)

Branch coverage included in aggregate %.

14 of 16 new or added lines in 3 files covered. (87.5%)

6131 of 6557 relevant lines covered (93.5%)

835.97 hits per line