Add support for on-device packages in MCP Registry

[asklar]

• Introduced on_device registry type for pre-installed servers.
• Added optional manifest and __dirname fields in package objects.
• Updated validation logic to accept on-device packages without remote checks.
• Enhanced documentation and examples for on-device server usage.

Motivation and Context

How Has This Been Tested?

Breaking 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

Additional context

[domdomegg]

I'm supportive of adding an on_device type. Very excited to see this working.

Regarding including the MCPB manifest, I'm a little less convinced. I worry this will lead to more duplication, which then raises the possibility for things to be out of sync between the manifest in the server.json and the manifest in the package itself. This usually opens up cans of worms around security etc. I also am just generally not sure if we want to be adding more things

I think if you want a manifest, it might be best to either:

• link to it as the identifier or similar for on_device type?
• add it in publisher provided or some other _meta for now, and if it gains wide adoption we promote it into the main package schema?

[asklar]

thanks @domdomegg! Starting with the manifest (+ __dirname) in the server's _meta sounds good, we can re-evaluate promoting that based on adoption.

Ideally, package would have its own _meta so that we could add it there instead of at the server level. Any idea why that's not present?

I'll update the PR to put it in server._meta for now.

[rdimitrov]

Ideally, package would have its own _meta so that we could add it there instead of at the server level. Any idea why that's not present?

I'll update the PR to put it in server._meta for now.

I think for now we wanted to keep it on the higher level so we don't bloat the format. For example on our side, we handle package specific meta by having a map of extensions under the _meta vendor which we map like - map[package]:{}