Skip to main content

Command Palette

Search for a command to run...

We Moved Our MCP Server to Remote HTTP — Here's Why

The standalone npm package served us well, but remote MCP is simpler, faster to set up, and works everywhere.

Published
4 min read
We Moved Our MCP Server to Remote HTTP — Here's Why

When we first launched our MCP integration back in January, the only practical option was a local stdio server — an npm package that ran on your machine and bridged Claude Desktop to our API. It worked, but it came with friction: you needed Node.js installed, npx in your PATH, and a JSON config file pointing to the right command. If something broke, debugging meant checking process logs, PATH variables, and config syntax all at once.

Since then, every major AI tool has added support for remote MCP servers over HTTP. Claude Desktop, Cursor, Windsurf, VS Code, Zed, and Claude Code all support connecting to a remote MCP endpoint with a URL and headers — no local process, no npm, no Node.js dependency.

So we've moved to remote-first and deprecated the standalone @rynko/mcp-server npm package.

What Changed

Our MCP server now runs as part of Rynko's backend infrastructure, exposed at two endpoints:

  • Render MCP (templates and document generation): https://api.rynko.dev/api/mcp-documents

  • Flow MCP (AI output validation): https://api.rynko.dev/api/flow/mcp

Both use Streamable HTTP transport — JSON-RPC 2.0 over HTTP with optional Server-Sent Events for real-time notifications. This is the same transport that Claude Desktop, Cursor, and other tools use natively.

The old npm package used stdio transport: it spawned a local Node.js process that communicated with your AI tool via stdin/stdout. This meant every user needed Node.js 18+, the package had to be downloaded and kept up to date, and any server-side improvements required a new npm release.

With remote HTTP, none of that applies. You point your AI tool at a URL, add an auth header, and you're connected. Updates happen server-side — no package to update.

Setup Is Now 30 Seconds

Here's what the config looks like for each tool:

Cursor

{
  "mcpServers": {
    "rynko": {
      "url": "https://api.rynko.dev/api/mcp-documents",
      "headers": {
        "Authorization": "Bearer pat_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

VS Code

{
  "servers": {
    "rynko": {
      "type": "http",
      "url": "https://api.rynko.dev/api/mcp-documents",
      "headers": {
        "Authorization": "Bearer pat_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Claude Code

claude mcp add --transport http rynko https://api.rynko.dev/api/mcp-documents \
  --header "Authorization: Bearer pat_xxxxxxxxxxxxxxxx"

Claude Desktop

Claude Desktop has a few options. The simplest is using Connectors with OAuth — go to SettingsConnectors, add a custom connector with the URL, and sign in with your Rynko account. No token management needed.

If you prefer using a PAT, use the mcp-remote proxy:

{
  "mcpServers": {
    "rynko": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://api.rynko.dev/api/mcp-documents",
        "--header",
        "Authorization:${RYNKO_PAT}"
      ],
      "env": {
        "RYNKO_PAT": "Bearer pat_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Full setup instructions for all six tools are in our Render MCP guide and Flow MCP guide.

Flow MCP: Why Remote Was Essential

When we built Rynko Flow — our AI output validation gateway — we needed dynamic tool registration. Each validation gate in your workspace generates a dedicated validate_{slug} tool with a schema derived from the gate's configuration. When you create, update, or delete a gate, the MCP server pushes a notifications/tools/list_changed event so connected agents see the updated tool list without reconnecting.

This kind of server-initiated push notification is only possible with remote transport. A stdio server can't push events to the client — it can only respond to requests. We would have needed to implement polling or some other workaround, and the developer experience would have been worse.

Going remote-first meant Flow MCP worked naturally from day one, with real-time tool discovery and no compromises.

What Happens to the npm Package

The @rynko/mcp-server package on npm still works, but we've marked it as deprecated. It only supports Render tools (template management and document generation) — Flow tools were never added to it because they require server-side event support.

If you're currently using the npm package, switching to the remote server takes about a minute: replace the command/args/env config with a url/headers config pointing to https://api.rynko.dev/api/mcp-documents. Your PAT token works the same way — just pass it as a Bearer token in the Authorization header.

What We Gained

Moving to remote MCP simplified things on both sides:

For users: No Node.js dependency, no npm package to install or update, no PATH issues, no local process to debug. Just a URL and a token.

For us: One deployment target instead of coordinating npm releases with backend changes. Server-side improvements are available to everyone immediately. And we can use features like SSE for real-time notifications that stdio doesn't support.

The MCP ecosystem is still young, but the direction is clear — remote HTTP transport is becoming the standard. We're glad we made the move early.


Resources:

More from this blog

B

Building Rynko

18 posts