feature: Support for DXTs

[domdomegg]

Add support for DXTs (or whatever they're going to be named). We discussed this in a call last week, but we were thinking the format might be like this in a server.json:

{
  ...
  "packages": [
    {
      "registry_name": "dxt",
      "name": "https://some-file-serving-place.com/my-dxt/1-0-2.dxt",
      "file_hashes": {
        "sha-256": "fe333e598595000ae021bd27117db32ec69af6987f507ba7a63c90638ff633ce"
      },
      "version": "1.0.2"
    }
  ]
}

We could provide guidance on people on how to host it on GitHub releases etc.

The file hash is necessary so that clients can verify the file hasn't changed since e.g. a downstream repository has stamped it as 'verified' or 'probably free of malware' etc.

[domdomegg]

cc @tadasant @felixrieseberg

[tadasant]

Makes sense to add dxt as an option here, I like that elegant solution to the "what do we do with DXT" problem.

I could also see us moving to a similar approach for container/oci as per Jim's thoughts here.

file_hashes is interesting but is this DXT-specific? Isn't this a concern for basically any package type? I think it's a good idea but maybe worth considering separately from DXT; I like that thought that downstream registries could verify it and it provides a way for folks to zip the data back together even if we're not storing that downstream data in the upstream directly.

[tadasant]

Cross-pointing some thoughts from #249

After thinking about this a little more, I'm actually not sure we'd want to make a significant change here. There are at least two reasons it is valuable to us to be explicit about registry_name=dockerhub rather than doing something generic like package_uri=docker.io/mcp/filesystem:

• By including an explicit whitelist of well known registries, rather than an open-ended URI that could point to any (malicious) registry, we lean on existing registry standards for combatting spam and malicious code (it's one of our design principles). So someone can't go and stand up maliciousregistry.org and start hosting packages they submit all over the MCP Registry and try to inject into MCP clients.
• We still need to come up with some mechanism for validating that the references are correct (here). If we allow arbitrary references (rather than a predefined set of "trusted" registries), this might become an intractable problem

These two thoughts are actually relevant to #260 as well, since we are contemplating allowing an open-ended URL claiming to host a DXT package there... I don't love the security/spam exposure there. Though that DXT problem is even harder than the container/oci one here, since fundamentally there don't pre-exist any DXT registries we can lean on to start.

Not sure yet on a solution... just feels like a pretty big drawback to poke a hole in our otherwise helpful reliance on other registries. Or is there an argument to allow this for DXT and not OCI (e.g. acknowledging it's not ideal, but there is no DXT registry we can lean on in this case so we take the trade off here)?

[domdomegg]

Haha it might get a bit painful copy/pasting things because I think this is actually a very similar/analogous problem to the docker case. But perhaps we could support DXT from a URL, but for the official registry we start by allowlisting only some URLs that we expect have some moderation already e.g. GitHub and GitLab release URLs only.

[joan-anthropic]

👋 Hi! By way of quick intro, I'm supporting @felixrieseberg in our efforts to integrate DXTs into the MCP project. Just catching up on context - it sounds like there are separate threads/perspectives re: what support for DXT looks like in server.json:

1. (this issue) registry includes reference to a remotely-hosted, packaged DXT file
2. (elsewhere, e.g. here) registry server.json supports all of the fields necessary to generate DXT's manifest.json (and eventually supplants it), e.g. author/publisher field

Is the idea here that 1) is complementary to 2), and we'd want to pursue both? Or that this approach might replace 2)?

My impression was that we wanted to focus on 2) - server.json acts as an input to the DXT packaging step (as a stand-in for manifest.json) but that we wouldn't necessarily expect developers to need to package or host their DXT as an input to server.json - am I missing context / motivation? Thanks in advance!

[tadasant]

From a recent conversation that Adam, Felix, and I had: my impression was that the original plan was (2), but after that conversation, we were leaning towards pursuing (1) instead of (2).

IIRC the gist of the rationale was that (2) can be fairly complex / has lots of edge cases no matter how well-defined we get with server.json, and (1) bypasses that complexity / slots in well with DXT becoming "just another possible registry_name and package type"

[joan-anthropic]

Gotcha, thanks! Super helpful. I'm chatting with Felix + relevant stakeholders to align on a new naming for DXTs (something more application-agnostic, e.g. MCP Bundle) but wondering first - once we align on naming, if we can restrict DXT URLs to allowlisted hosts (Github / Gitlab), are there any other blockers we'd anticipate to folding in the DXT manifest spec, CLI tooling, and documentation into the MCP project?

Also, please let me know if there's a better forum for this conversation - thanks again!

[domdomegg]

once we align on naming, if we can restrict DXT URLs to allowlisted hosts (Github / Gitlab), are there any other blockers we'd anticipate to folding in the DXT manifest spec, CLI tooling, and documentation into the MCP project?

I think there are probably two questions here:

1. What are the product requirement blockers to integrate this into registry?

• Where to have the discussion: this issue is the right place :)
• My assessment: deciding on naming + allowlisting a couple hosts would be sufficient, although would invite thoughts from the other registry maintainers and contributors.

2. What are the blockers to have MCP absorb the DXT (or whatever it is renamed to) standard?

• Where to have the discussion: Probably the contributors Discord or GitHub Discussions on the main modelcontextprotocol repo? Or possibly an issue on the DXT repo which you send MCP people over to 🤷.
• My assessment: probably figuring out the open-source governance side of things, which will likely require getting approval from the MCP core maintainers. I actually think the renaming / allowlisting stuff isn't a blocker here.

[connor4312]

file_hashes is interesting but is this DXT-specific? Isn't this a concern for basically any package type?

I think this is DXT specific. Other packages are referenced on registries, and those registries already have the file hashes for their packages and I believe would be consider "trusted" as the points of truth. For a client who sees a package on a registry and runs it with npx/uvx/dnx, there is not an opportunity in those tools to independently verify the hash and setting that as a requirement by including it may be a good chunk of work for clients who now need to interact with the upstream registries explicitly.

What are the product requirement blockers to integrate this into registry?

I think my main concern is that a lot of what's in the DXT package is already in the registry. For example, the argument generation and formatting is already present (with more features) in the registry spec/server.json. As a client, how would I deal with information that's duplicative or conflicting between the registry's manifest and the DXT manifest once I download the package? Or does there even still need to be a "DXT manifest" once data is on the registry?

[joan-anthropic]

cc @toby

[domdomegg]

file_hashes is interesting but is this DXT-specific? Isn't this a concern for basically any package type?

I think this is DXT specific. Other packages are referenced on registries, and those registries already have the file hashes for their packages and I believe would be consider "trusted" as the points of truth.

Agree with this, also I think all the other registries guarantee immutability of a particular version. So a downstream registry like Anthropic can sign off and say 'yup, we've security scanned npm package 'thing-mcp-server@1.2.3' and think it's okay, and then clients can trust that.

But if it's an arbitrary GitHub/GitLab hosted URL because these don't support immutability (although GitHub has a proposal on their roadmap), it means the thing you download from the referenced release URL could change. So Anthropic can't sign off to say 'yep this thing is okay' without specifying an immutable version (which the sha hash enforces).

[joan-anthropic]

👋 Started writing this in a google doc before realizing it makes sense here.

Wanted to summarize different threads re: support for DXTs in MCP registry / server.json to hopefully align + implement something before registry is released in 2 weeks.

DXT integration into MCP registry / server.json

Context:

DXT's manifest.json provides information around installing, configuring, and executing the local MCP server:

• Core metadata: Extension name, version, description, author info
• Server configuration: How to run the MCP server (Node.js, Python, or binary), including entry point and runtime commands
• User configuration: Settings that users can configure through the UI (API keys, directories, etc.)
• Compatibility requirements: Platform support, runtime versions, client app versions
• Assets: Icons, screenshots, documentation URLs
• Tools / prompts and their descriptions

MCP registry's server.json contains registry-focused metadata for MCP server discovery and installation, eg:

• Package manager integration (npm, PyPI, Docker)
• Remote server configurations
• Environment variables and runtime hints
• Basic metadata (name, description, version)

Philosophically (from Adam Jones):

• server.json is the spec for 'I want to describe any MCP server, that could be run in a wide range of ways'
• manifest.json is the spec for 'I want to describe an opinionated way of running an MCP server locally'

Put another way: manifest.json is to DXT, as package.json is to NPM, or pyproject.toml is to PyPi, or Dockerfile is to Docker. server.json is an aggregator on top of all these ways to run MCP servers, that just points at one of these methods.

Option 1: DXT as additional package type

See [feature: Support for DXTs #260](#260)

Add DXT as another package type in server.json, pointing to hosted .dxt files. Manifest.json as-is continues to live in the DXT zip archive.

Example:

{
  "name": "my-mcp-server",
  "description": "Example MCP server",
  "packages": [
    {
      "registry_name": "dxt",
      "name": "https://github.com/user/repo/releases/download/v1.0.2/server.dxt",
      "file_hashes": {
        "sha-256": "fe333e598595000ae021bd27117db32ec69af6987f507ba7a63c90638ff633ce"
      },
      "version": "1.0.2"
    }
  ]
}

Pros:

• Primarily: this feels like the minimal changeset to enable some form of DXT representation in server.json without locking us into a rigid schema that may not serve future goals
• Easiest to reverse in the event we want to pursue consolidation of both formats in the future
• DXT remains a separate, focused specification
• Clear separation of concerns

Cons:

• Still maintains dual-format complexity / requires separate maintenance of manifest.json files
• Limited to allowlisted hosting providers for security
• From Adam: The set of allowlisted providers could be fairly large, as long as they're reputable sources that have some abuse/moderation capabilities. E.g. could include GitHub, GitLab, Google Cloud Storage, S3, Azure Blob Store - which I'd guess would cover 99% of use cases?

Option 2: Unified server.json

See [Felix's early PR](https://github.com/anthropics/dxt/compare/felixr/server-json?expand=1&short_path=0fcf1d5#diff-0fcf1d5263477fd140597fe5648b0a4b375435dac23d36f815b3eda5c0334c05)

Extend server.json to include all DXT-specific fields, eliminating maintenance of manifest.json as a separate artifact. Manifest.json is dynamically generated during the DXT packaging step, using server.json as input.

Server.json is currently missing some fields in order to make ^ a reality.

Critically:

• author/publisher (some alignment around getting this into server.json, see [comment from Tadas](feature: Support for DXTs #260 (comment)))
  • Name
  • Email
  • Url
• server
  • Entry_point
  • server_type

And ideally:

• Metadata
  • display_name - Human-readable name
  • long_description - Extended description
  • homepage - Project homepage URL
  • documentation - Documentation URL
  • support - Support/issues URL
  • license - License identifier
  • keywords - Search keywords
  • icon - Icon path
  • [Open issue here](feature: Support for DXTs #260 (comment)) (also see [this](question on the docker runtime type #249))
  • screenshots - Screenshot paths
• Compatibility indicators
  • compatibility.claude_desktop - Required Claude Desktop version [from Adam: seems fraught, consider striking]
  • compatibility.platforms - Supported OS platforms
  • compatibility.runtimes.python - Required Python version
  • compatibility.runtimes.node - Required Node version
• Tools/prompts
  • tools[] - Available tools with descriptions
  • prompts[] - Pre-defined prompts with arguments
• Server.mcp_config.platform_overrides

Example:

{
  "name": "filesystem-server",
  "description": "Local filesystem operations",
  "version_detail": { "version": "1.0.0" },
  "author": { "name": "Anthropic", "email": "support@anthropic.com" },
  "license": "MIT",
  "entry_point": "server/index.js",
  "server_type": "node",
  "user_config": {
    "allowed_directories": {
      "type": "directory",
      "title": "Allowed Directories",
      "multiple": true,
      "required": false
    }
  },
  "mcp_config": {
    "command": "node",
    "args": ["${__dirname}/server/index.js"],
    "env": { "API_KEY": "${user_config.api_key}" },
    "platform_overrides": {
      "win32": { "command": "node.exe" }
    }
  },
  "compatibility": {
    "claude_desktop": ">=1.0.0",
    "platforms": ["darwin", "win32", "linux"],
    "runtimes": { "node": ">=18.0.0" }
  }
}

Pros:

• Single source of truth eliminates synchronization issues
• Simplified developer experience and tooling
• Natural fit for registry → DXT packaging workflows
• Solves the "which file is authoritative?" problem

Cons:

• Primarily: we have already attempted this exercise and found that there was sufficient divergence in the content + intent of server.json vs. manifest.json to feel good about this as the right solution for now
• Ex: DXTs are primarily designed to run within a single runtime specification - how do we handle manifest.json data across multiple runtimes?
• Burdens server.json complex with metadata irrelevant to remote deployments
• Conflates service discovery with deployment packaging
• Could hinder independent evolution of different concerns
• [Adam Jones] Somewhat confused data model
  • e.g.: "entry_point": "server/index.js", "server_type": "node", doesn't actually make sense without the context of the rest of the DXT bundle, so putting it on the registry is a bit weird? and if a package offers multiple installation methods (e.g. DXT, Docker and npx) it's only relevant to DXT, so it feels weird to be a top-level property

Option 3: manifest.json as metadata on DXT package entry

Extend package entry with DXT-specific metadata while keeping root level focused on service metadata

Example:

{
  "name": "filesystem-server",
  "description": "Local filesystem operations",
  "version_detail": { "version": "1.0.0" },
  "author": { "name": "Anthropic" },
  "license": "MIT",
  
  "packages": [...],
  
  "deployment_profiles": {
    "dxt": {
      "entry_point": "server/index.js",
      "server_type": "node",
      "mcp_config": {
        "command": "node",
        "args": ["${__dirname}/server/index.js"],
        "env": { "API_KEY": "${user_config.api_key}" }
      },
      "user_config": {
        "api_key": {
          "type": "string",
          "title": "API Key",
          "sensitive": true
        }
      }
    }
  }
}

Comment from Adam Jones: I think an adaptation of this is my second favourite option - specifically just adding it as metadata to the 'packages' entry for DXT

Pros:

• Clear separation between service metadata and deployment configuration
• Supports multiple deployment targets from single definition
• Maintains semantic clarity while achieving single-file goal
• Enterprise-friendly with clear security boundaries
• Extensible for future deployment types (Docker, K8s, serverless)

Cons:

• More complex schema than simple unified approach
• Requires tooling updates to understand profile selection
• Maybe over-engineered for current needs?