MCPorter: Call MCP Servers from TypeScript, the Terminal, or a Generated CLI

The gap MCPorter fills between an MCP server and your script

An MCP server exposes tools over stdio, Streamable HTTP, or legacy SSE. Using those tools from a chat client is well trodden. Using them from a bash script, a scheduled job, or a TypeScript function is not, because each caller has to speak the protocol, negotiate a revision, and manage the connection lifecycle. MCPorter is aimed at that second group: developers and coding agents that need the same MCP tools from a terminal, a script, or a generated standalone CLI. The README frames the project as a TypeScript runtime and command-line tool for discovering and calling Model Context Protocol servers. The audience is narrow on purpose. If you live inside Claude Code or Cursor, those clients already import their own server lists and you are not the target. If you want a Context7 lookup inside a build step, or a one-off tool call in a shell pipeline, MCPorter is the layer that removes the boilerplate. The repository also ships a schema file, mcporter.schema.json, which suggests config validation is part of the intended workflow rather than an afterthought.

How discovery, config import, and the runtime fit together

MCPorter reads project and user config, then imports MCP servers from Cursor, Claude Code and Desktop, Codex, Windsurf, OpenCode, and VS Code. That import step is the practical centre of the design: you do not retype server definitions you already maintain elsewhere. A minimal config/mcporter.json holds an mcpServers map, and the configuration guide defines precedence and the full schema. Config files accept JSONC, so comments survive, and environment placeholders in the forms ${VAR}, ${VAR:-fallback}, or whole-value $env:VAR. One deliberate rejection stands out: the ${env:VAR} form used by some MCP clients is not supported, and mcporter rejects it with the accepted alternatives instead of sending it literally. That is the right call, since a silently unexpanded placeholder produces a confusing auth failure later. On the runtime side, createRuntime() takes explicit server definitions and gives you connection reuse across several calls, while callOnce() handles a single configured call and cleanup. createServerProxy() maps MCP tool names to callable camelCase properties and wraps results with text, Markdown, JSON, image, and raw-content helpers. For long-lived use there is a keep-alive daemon that pools servers, and the Chrome DevTools path routes through an OpenClaw extension relay with a retained loopback socket and a credential-free URL handed to chrome-devtools-mcp.

Installing mcporter and making a first real call

The README offers a no-install path first, which is the fastest way to check that your Node version and network reach are fine. Run the version check, and you should see the CLI print its version and exit.

npx mcporter --version

For repeated command-line use there are two install routes. The Homebrew tap is the macOS-friendly one; the npm global install works anywhere Node 24 or newer is present, and the README states that Node 24 or newer is required for npm installs.

brew install steipete/tap/mcporter
# or
npm install -g mcporter

The quickstart inspects a public MCP server, then calls one of its tools. The first command prints the server's TypeScript-style tool signatures, which is how you learn argument names before calling anything. The second resolves a library ID without local configuration or credentials.

npx mcporter list https://mcp.context7.com/mcp --brief
npx mcporter call https://mcp.context7.com/mcp.resolve-library-id \
  query="React hooks docs" libraryName=react

For repeated use, put the server in config/mcporter.json so you stop passing URLs. JSONC comments are allowed, and the shape below is the one the README gives.

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

With that file in place, mcporter list reports the configured servers, and human-readable output goes to stdout by default. Switch to JSON output when another program or agent needs a stable result. Each subcommand documents its own flags under mcporter <command> --help.

Where MCPorter stops being the right tool

Interactive elicitation is the clearest boundary. MCPorter negotiates the current 2026-07-28 protocol or a legacy revision per server, and legacy connections advertise client elicitation capabilities. Interactive CLI calls can answer form and URL requests; headless and daemon-managed calls decline them with an actionable hint. If your workflow depends on a server asking the user for a missing parameter mid-call, a daemon-managed or CI invocation will not complete that exchange. That is a design choice, not a bug, but it decides whether MCPorter fits a given server. The Chrome DevTools integration has a similar shape. Routing defaults to prefer, which may fall back only to Chrome's original auto-connect path; require fails closed and off keeps original auto-connect. Teams that need a hard guarantee should read that setting before assuming the relay is in use. There is also a plain scope limit: MCPorter calls MCP servers, it does not implement one. If your problem is exposing your own functions to a model, you want an MCP server framework, not this. And the runtime is TypeScript-first. The README documents a TypeScript runtime and a CLI, so a Python or Go service that wants typed access is looking at the CLI plus JSON output rather than a native client.

MCPorter against calling the MCP server directly

The obvious alternative is a hand-written client against the Model Context Protocol specification. That approach gives you exact control over the transport, the revision you negotiate, and the error surface, and it adds no dependency to your build. The cost is that you reimplement connection setup, cleanup, tool listing, and result unwrapping for every server you touch, and you own the upgrade path when the specification moves. MCPorter's difference is that those pieces are already assembled: createRuntime() for reuse, callOnce() for a single call, createServerProxy() for camelCase tool access with text, Markdown, JSON, image, and raw-content helpers. The other alternative is staying inside an MCP client such as Cursor or Claude Code and never leaving it. That is genuinely simpler when your only consumer is a chat session. The moment the same tool needs to run in a cron job or a test suite, though, the client is the wrong host, and MCPorter's config import means you can reuse the server definitions you already wrote for that client instead of maintaining a second list.

Maintenance, releases, and what the MIT licence means here

The repository is not archived, and the last push was on 2026-08-28. Recent releases run v0.13.6, v0.13.7, and v0.13.8, all within August 2026, and the package.json in the repository declares version 0.13.13, so the published line is moving faster than the release notes captured here. The v0.13.6 entry is labelled Relay-aware daemon startup, which lines up with the daemon and Chrome DevTools documentation. For upgrade cost, the practical exposure is the protocol revision. MCPorter negotiates the current 2026-07-28 revision or a legacy revision per server, and the repository's modern and legacy fixture servers cover both generations, with CI exercising representative fixture paths end-to-end over stdio and Streamable HTTP. That fixture coverage is the thing to watch when a new revision lands, because it is what tells you whether your server still negotiates. The MIT licence permits commercial use, modification, and redistribution; it also means no warranty, and nothing in the README promises support. If you need a support contract, this project does not offer one. Check the LICENSE file for the exact terms rather than treating this summary as legal advice.

Editorial conclusion

Adopt MCPorter if you already run MCP servers and want them reachable from shell scripts, CI jobs, or typed TypeScript without hand-writing a JSON-RPC client for each one. Skip it if you only ever drive MCP tools from inside an existing MCP client, since that client already does the connection work. Before committing, verify the protocol revision your servers negotiate against the 2026-07-28 revision MCPorter advertises, and confirm that headless calls are acceptable, because interactive elicitation requests are declined outside an interactive CLI session.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes