Support for remote MCP servers (streamable HTTP transport)

[appcypher]

So MCPB is great for distributing local MCP servers. You bundle the code, ship it, host runs it via stdio. Works well.

But not all MCP servers are local. Remote servers are pretty common too and theres no standard way to distribute them right now. Use cases like:

• Servers that need to be long running and outlive sessions
• Cloud hosted MCP server services
• Self-hosted servers on your own infra
• Enterprise deployments behind corporate firewalls

Would be nice to have a standard.

Proposal

Add a transport field and connection config to the manifest. Pretty minimal change:

Basic remote server:

{
  //...
  "server": {
    "transport": "http",
    "mcp_config": {
      "url": "https://api.example.com/mcp/"
    }
  }
}

With auth:

{
  //...
  "server": {
    "transport": "http",
    "mcp_config": {
      "url": "https://api.example.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${user_config.api_token}"
      }
    }
  },
  "user_config": {
    "api_token": {
      "type": "string",
      "title": "API Token",
      "required": true,
      "sensitive": true
    }
  }
}

Bundled HTTP server:

{
  //...
  "server": {
    "type": "node",
    "transport": "http",
    "entry_point": "server/index.js",
    "mcp_config": {
      "command": "node",
      "args": ["${__dirname}/server/index.js", "--port=3000"],
      "url": "http://localhost:3000/mcp",
    }
  },
  "user_config": {
    "client_id": { "type": "string", "required": true }
  }
}

How it breaks down

Basically you get four modes depending on whether theres bundled code and what transport you use:

entry_point	transport	Mode	What happens
Present	stdio (default)	Bundle Stdio	Current MCPB behavior
Present	http	Bundle HTTP	Spawn local server, connect via HTTP
Absent	stdio	Reference Stdio	Run external command
Absent	http	Reference HTTP	Connect to remote URL, no spawning

Context

We're working on an AI agent platform. We use MCPB for tool distribution but our agents can use both local and remote MCP servers. So we ended up implementing this extension ourselves.

From doing this we know:

• Its backward compatible, existing bundles just work
• Schema change is small
• Handles the common auth patterns (API keys, bearer tokens, OAuth)

Would rather have this in the actual spec than maintain our own fork tho. A standard means registries can list remote servers, clients have one way to handle connections, etc.

Related

• Support declaring multiple installation modes #20 - talks about multiple installation modes which is related

Happy to help with the spec if theres interest.