archetech / archon / 29510750309

90%

push

github

fix: return asset image/file tools as MCP content blocks (#721) (#724)

* fix: return asset image/file tools as MCP content blocks (#721)

archon_get_asset_image and archon_get_asset_file returned base64 inside a
private JSON object, so a spec-compliant client had to know our inline-data
convention to render data the protocol displays natively.

The image tool now returns an image content block, and the file tool an
embedded resource block identified by the asset's DID, each alongside a text
block carrying the metadata (mirrored into structuredContent).

Embedded resource over resource_link: resource_link hands the client a URI to
fetch via resources/read, which this server does not implement, so the link
would dangle. Embedded resources carry the bytes inline and work today. The
spec's "SHOULD implement the resources capability" is left as a follow-up.

Inline data on the input side is unchanged: MCP defines content blocks for
tool results, not arguments.

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

* fix: mirror asset metadata exactly between text block and structuredContent

Review catch: the file tool normalized the resource block's mimeType to
application/octet-stream but built its metadata from the raw file.type, so an
untyped asset advertised a mimeType on the resource block and none in the
metadata. Separately, both tools passed the metadata object to structuredContent
raw while the text block went through JSON.stringify, so absent filename/type
left undefined-valued keys on one side only -- the divergence ok() explicitly
guards against.

contentResult now builds the text block itself and round-trips metadata through
JSON, so the mirror is structural rather than per-caller discipline, and the
normalized mimeType is used for both the block and the metadata.

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

---------

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

2936 of 3481 branches covered (84.34%)

Branch coverage included in aggregate %.

17 of 17 new or added lines in 1 file covered. (100.0%)

6102 of 6526 relevant lines covered (93.5%)

833.98 hits per line