archetech / archon / 29546951075

90%

push

github

feat: implement the MCP resources capability (#725) (#734)

* 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>

* fix: error when asset bytes are unavailable instead of falling back to JSON

Review catch, and a real one. getFile returns null only when the asset is not a
file ass... (continued)

2946 of 3494 branches covered (84.32%)

Branch coverage included in aggregate %.

16 of 18 new or added lines in 3 files covered. (88.89%)

6133 of 6559 relevant lines covered (93.51%)

835.72 hits per line