Skip to content

Add _meta to manifest schema and tests - #124

Merged
joan-anthropic merged 3 commits into
modelcontextprotocol:mainfrom
asklar:user/asklar/static_responses_and_extensions
Oct 10, 2025
Merged

Add _meta to manifest schema and tests#124
joan-anthropic merged 3 commits into
modelcontextprotocol:mainfrom
asklar:user/asklar/static_responses_and_extensions

Conversation

@asklar

@asklar asklar commented Oct 10, 2025

Copy link
Copy Markdown
Contributor

Summary

Adds a _meta field to the manifest for platform/client–specific metadata objects (e.g. Windows package_family_name, macOS bundle identifiers, custom client integration info).

Schema, tests, and documentation updated accordingly.

@asklar
asklar marked this pull request as ready for review October 10, 2025 19:08
Comment thread MANIFEST.md Outdated
Comment thread MANIFEST.md Outdated
Comment thread MANIFEST.md Outdated

@MarshallOfSound MarshallOfSound left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving spec changes 👍

Comment thread MANIFEST.md Outdated
Comment thread MANIFEST.md Outdated
@joan-anthropic

Copy link
Copy Markdown
Contributor

adding @domdomegg !

Comment thread MANIFEST.md Outdated

@domdomegg domdomegg left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My overall opinion (am not the owner of mcpb stuff :), just 2 cents):

  • I like the idea of client_extensions. Giving the community an extension point that can be used flexibly seems like a good escape hatch + a way to learn how people are using things and adopt the good stuff. To align with the main MCP spec I might call this _meta, which can still have whatever you want in it basically. There's a bit of a convention of using reverse DNS names, e.g. com.microsoft.windows maybe, but it is freeform.
  • I'm not super convinced by static_responses yet. My guess is the performance benefit is pretty minimal, and it might duplicate a lot of the stuff already in tools or prompts. For richer discovery it feels like it might live better in the registry (we've had some discussions there - see modelcontextprotocol/registry#79 and modelcontextprotocol/registry#82)

@asklar asklar changed the title Add static_responses and client_extensions to manifest schema and tests Add _meta to manifest schema and tests Oct 10, 2025

@domdomegg domdomegg left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@asklar
asklar force-pushed the user/asklar/static_responses_and_extensions branch from 50a8c5a to 443d849 Compare October 10, 2025 23:43
@joan-anthropic
joan-anthropic merged commit d12057e into modelcontextprotocol:main Oct 10, 2025
@asklar
asklar deleted the user/asklar/static_responses_and_extensions branch October 10, 2025 23:46
bryan-anthropic pushed a commit to bryan-anthropic/mcpb that referenced this pull request Oct 28, 2025
…tatic_responses_and_extensions

Add _meta to manifest schema and tests
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.

4 participants