Hosted vs self-hosted MCP

Boson runs hosted MCP servers on Cloud Run. You can also run your own — npx @bosonprotocol/agentic-commerce boson-mcp-server works as either an HTTP server or stdio.

Hosted (default)

Use the hosted endpoints for:

• Quickstarts and prototypes.
• Production agents where latency and uptime requirements aren't extreme.
• Anyone who doesn't want to run infrastructure.

Self-hosted HTTP

npx @bosonprotocol/agentic-commerce boson-mcp-server --port 8080 --mode http

Use self-hosting when:

• You want predictable latency (e.g. co-locate with your agent).
• You need custom auth / rate-limit policies in front of the MCP.
• You want to fork the server to add custom tools.

Self-hosted stdio (local agents)

For Claude Desktop, Cline, Cursor, etc., add to the MCP client config:

{
  "mcpServers": {
    "boson": {
      "command": "npx",
      "args": ["@bosonprotocol/agentic-commerce", "boson-mcp-server", "--mode", "stdio"]
    }
  }
}

Stdio is process-local; no network. Best for desktop / IDE integrations.

Picking ConfigId server-side vs per-call

The MCP server doesn't bind to a single configId. Every state-changing tool takes configId as a parameter. One MCP instance can handle staging + production traffic simultaneously.

Common gotchas

• Cold starts on Cloud Run. First request after idle can take a few seconds. Keep the agent warm if your latency budget is tight.
• Versioning. The hosted server tracks the main branch of agentic-commerce. Self-host if you need version-pin guarantees.
• Rate limits. Hosted endpoints have generous but non-infinite rate limits. Self-host if you're doing >100 req/s sustained.

Next

• Three integration paths.
• Tooling → MCP.