modelcontextprotocol / modelcontextprotocol/registry

Official guidance of parsing stdio package to mcp.json

Open
#650 5 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
7.3k
Forks
994
Avg merge
4d 12h
Merged PRs (30d)
19

Description

I am working on MCP Registry support in GitHub Copilot for JetBrains IDEs.
We wonder whether there is an official guidance about how to parse stdio package to mcp.json?

Using Azure MCP Server as example. The package section would be like this:

// Pattern#1: no runtimeArguments
"packages": [
  {
    "registry_type": "npm",
    "registry_base_url": "https://registry.npmjs.org",
    "identifier": "@azure/mcp",
    "version": "0.6.0",
    "transport": {
      "type": "stdio"
    },
    "package_arguments": [
      {
        "type": "positional",
        "value": "server"
      },
      {
        "type": "positional",
        "value": "start"
      }
    ]
  }
]

The pasring result in mcp.json would be like below:

"azure/azure-mcp": {
  "type": "stdio",
  "command": "npx",
  "args": [
    "-y",
    "@azure/mcp@latest",
    "server",
    "start"
  ]
}

However, the usage of runtimeArguments is not quite clear.
Publisher may have different pattern for the MCP server.

runtime_arguments with -y:

// Pattern#2: partial runtimeArguments
"packages": [
  {
    "registry_type": "npm",
    "registry_base_url": "https://registry.npmjs.org",
    "identifier": "@azure/mcp",
    "version": "0.6.0",
    "transport": {
      "type": "stdio"
    },
    "runtime_arguments": [
      {
        "is_required": true,
        "format": "string",
        "value": "-y",
        "type": "positional",
        "name": "-y",
        "value_hint": "noninteractive_mode"
      }
    ],
    "package_arguments": [
      {
        "type": "positional",
        "value": "server"
      },
      {
        "type": "positional",
        "value": "start"
      }
    ]
  }
]

runtime_arguments with -y + package_name@version:

// Pattern#3: full runtimeArguments
"packages": [
  {
    "registry_type": "npm",
    "registry_base_url": "https://registry.npmjs.org",
    "identifier": "@azure/mcp",
    "version": "0.6.0",
    "transport": {
      "type": "stdio"
    },
    "runtime_arguments": [
      {
        "is_required": true,
        "format": "string",
        "value": "-y",
        "type": "positional",
        "name": "-y",
        "value_hint": "noninteractive_mode"
      },
      {
        "type": "positional",
        "value": "@azure/mcp@0.6.0"
      }
    ],
    "package_arguments": [
      {
        "type": "positional",
        "value": "server"
      },
      {
        "type": "positional",
        "value": "start"
      }
    ]
  }
]

For the above 3 patterns, which one or ones are recommended? WIth the clear pattern, we clients of MCP Registry could do the correct pasring.

In addtion, some stdio mcp server (especially oci) may have complicated arguments:

"github": {
    "command": "docker",
    "args": [
        "run",
        "-i",
        "--rm",
        "--port",
        "3001",
        "--name",
        "xyz",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
    ]
}

How is the recommended package section in registry, and how is the parsing logic?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by reviewing the registry package schema and the three runtime_arguments patterns described in the issue, then compare them with the Docker stdio example. Done means the repository documents an agreed package shape and parsing rule for these cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, json
Domain
backend-api-design, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.