Skip to content

Add _meta field to resource, content, and result classes#310

Open
koic wants to merge 1 commit intomodelcontextprotocol:mainfrom
koic:add_meta_field_support
Open

Add _meta field to resource, content, and result classes#310
koic wants to merge 1 commit intomodelcontextprotocol:mainfrom
koic:add_meta_field_support

Conversation

@koic
Copy link
Copy Markdown
Member

@koic koic commented Apr 11, 2026

Motivation and Context

MCP 2025-11-25 spec defines a _meta general field on many types, but the Ruby SDK only exposed it on Tool and Prompt. To attach metadata (e.g. MCP Apps CSP hints on resource contents), consumers had to subclass existing classes and override to_h.

Add a meta: keyword argument and _meta serialization to:

  • Resource::Contents, Resource::TextContents, Resource::BlobContents
  • Resource, ResourceTemplate
  • Content::Text, Content::Image, Content::Audio, Content::EmbeddedResource
  • Tool::Response (CallToolResult)
  • Prompt::Result (GetPromptResult)

This aligns the Ruby SDK with the Python and TypeScript SDKs, which both expose _meta on these types.

Resolves #308.

How Has This Been Tested?

Added unit tests for each updated class covering two patterns: _meta present (asserts the value is reflected in to_h[:_meta]) and _meta omitted (asserts no :_meta key in to_h, i.e., .compact behavior). All existing tests continue to pass, and rake rubocop is clean.

Breaking Changes

None. All new meta: parameters are optional keyword arguments defaulting to nil. The to_h output stays backward-compatible because nil values are removed by the existing .compact call, so existing callers require no changes.

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

## Motivation and Context

MCP 2025-11-25 spec defines a `_meta` general field on many types,
but the Ruby SDK only exposed it on `Tool` and `Prompt`.
To attach metadata (e.g. MCP Apps CSP hints on resource contents),
consumers had to subclass existing classes and override `to_h`.

Add a `meta:` keyword argument and `_meta` serialization to:

- `Resource::Contents`, `Resource::TextContents`, `Resource::BlobContents`
- `Resource`, `ResourceTemplate`
- `Content::Text`, `Content::Image`, `Content::Audio`, `Content::EmbeddedResource`
- `Tool::Response` (`CallToolResult`)
- `Prompt::Result` (`GetPromptResult`)

This aligns the Ruby SDK with the Python and TypeScript SDKs, which both expose `_meta` on these types.

Resolves modelcontextprotocol#308.

## How Has This Been Tested?

Added unit tests for each updated class covering two patterns: `_meta` present
(asserts the value is reflected in `to_h[:_meta]`) and `_meta` omitted
(asserts no `:_meta` key in `to_h`, i.e., `.compact` behavior).
All existing tests continue to pass, and `rake rubocop` is clean.

## Breaking Changes

None. All new `meta:` parameters are optional keyword arguments defaulting to `nil`.
The `to_h` output stays backward-compatible because `nil` values are removed by the existing `.compact` call,
so existing callers require no changes.
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.

Native support for MCP app, specifically the _meta tag on the resource contents

2 participants