Module read 

The JSON resources/read and prompts/get answer with.

Why these documents live here and not in the IR

GetPromptResult and ResourceContents are pure data with no serialisation of their own, exactly like ToolResult. Assembly is an application concern because it depends on which revision the session negotiated — a fact the domain layer is not allowed to know — and a to_json on the IR type would have to take the revision as an argument anyway, which puts it back where it started.

Why a prompt’s content goes through the tool codec

A prompts/get message carries a ContentBlock, and that union is spelled differently per revision — resource_link arrives in 2025-06-18, audio in 2025-03-26. Rather than answer “how is a content block spelled at this revision” a second time, this wraps the block in the one-block ToolResult the tool path already lowers and reads the block back out of the answer.

That looks roundabout and is not. The alternative is a second copy of the per-revision codecs answering the same question, and the two would agree until the next revision added a field to one of them and not the other.

Functions

prompt_getter

Adapts a prompt getter into the PromptHandler a server stores.

prompt_messages

The GetPromptResult for result, with content blocks spelled for version.

read_contents

The ReadResourceResult for contents.

resource_reader

Adapts a resource reader into the ResourceHandler a server stores.