Skip to content

Document non-text content types, binary resources, and elicitation schema options - #472

Open
koic wants to merge 1 commit into
modelcontextprotocol:mainfrom
koic:fill_documentation_gaps
Open

Document non-text content types, binary resources, and elicitation schema options#472
koic wants to merge 1 commit into
modelcontextprotocol:mainfrom
koic:fill_documentation_gaps

Conversation

@koic

@koic koic commented Jul 27, 2026

Copy link
Copy Markdown
Member

Motivation and Context

The SDK tiering system (SEP-1730) requires Tier 1 SDKs to document all non-experimental features with examples. A documentation coverage audit against the canonical feature list found that the README.md only showed type: "text" content everywhere, leaving several implemented features invisible to users:

  • Tool responses with image, audio, and embedded resource content (MCP::Content::Image / Audio / EmbeddedResource)
  • Prompt messages carrying image or embedded resource content
  • Reading binary resources via MCP::Resource::BlobContents
  • Reading resources through a registered resource template URI
  • Elicitation requested_schema flat-object restrictions and client-side validation behavior
  • Elicitation default values (SEP-1034) and enum values with enumNames (SEP-1330)

All of these are existing SDK capabilities; the conformance suite already exercises them. This change documents each with prose and a runnable-style example, closing every documentation gap that does not require new code. Legacy SSE transport remains undocumented because the SDK intentionally does not implement it.

How Has This Been Tested?

Documentation-only change. Every code example was written against the current public API in lib/ (MCP::Content, MCP::Resource::TextContents / BlobContents, MCP::Prompt::Message, create_form_elicitation) and cross-checked with the working implementations in conformance/server.rb, which pass the conformance suite.

Breaking Changes

None. This only adds sections to README.md.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

…hema options

## Motivation and Context

The SDK tiering system (SEP-1730) requires Tier 1 SDKs to document all non-experimental features
with examples. A documentation coverage audit against the canonical feature list found that the README.md
only showed `type: "text"` content everywhere, leaving several implemented features invisible to users:

- Tool responses with image, audio, and embedded resource content (`MCP::Content::Image` / `Audio` / `EmbeddedResource`)
- Prompt messages carrying image or embedded resource content
- Reading binary resources via `MCP::Resource::BlobContents`
- Reading resources through a registered resource template URI
- Elicitation `requested_schema` flat-object restrictions and client-side validation behavior
- Elicitation default values (SEP-1034) and enum values with `enumNames` (SEP-1330)

All of these are existing SDK capabilities; the conformance suite already exercises them.
This change documents each with prose and a runnable-style example, closing every documentation gap
that does not require new code. Legacy SSE transport remains undocumented because the SDK intentionally
does not implement it.

## How Has This Been Tested?

Documentation-only change. Every code example was written against the current public API in lib/
(`MCP::Content`, `MCP::Resource::TextContents` / `BlobContents`, `MCP::Prompt::Message`, `create_form_elicitation`)
and cross-checked with the working implementations in conformance/server.rb, which pass the conformance suite.

## Breaking Changes

None. This only adds sections to README.md.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants