mcpc: a universal MCP CLI client with persistent sessions

The problem mcpc solves for MCP users

The README opens with a blunt diagnosis: many AI agents treat MCP tools as prompt-time function calls, repeatedly injecting tool definitions and results into context, which wastes tokens and makes the agent slower and less reliable. That is the origin of the popular claim that MCP is worse than plain CLIs. mcpc answers it by mapping every MCP operation to a shell command, so an agent needs one Bash() tool instead of dozens of wired-up MCP functions.

The intended audience is therefore narrower than "everyone using MCP". It is engineers who inspect MCP servers manually, people who want repeatable MCP workflows as shell scripts, and agent builders whose runtime already has shell access. The README also notes a side benefit: the same mcpc configuration, OAuth profiles and live sessions can be shared across several agents on one machine, so you authenticate once and reuse the credentials everywhere.

How the client, sessions and OAuth fit together

mcpc sits between the caller and the MCP server. The README's diagram is explicit: an AI agent issues Bash(), mcpc receives it, and mcpc speaks MCP to the server, handling sessions, OAuth, tools, resources, prompts, tasks and x402 along the way. The argument for this split is that CLI is a good local interface while MCP stays the remote interface for discovery, authentication, payments and access control.

Sessions are the central abstraction. connect starts a named session such as @test against a server, and that session persists, so later commands address it by name rather than reconnecting. The README states that connections to multiple servers can stay alive in parallel and that this works whether the server protocol is stateful or stateless. A session can be closed or restarted, and the help text warns that restart loses all state.

Servers are reachable over stdio or Streamable HTTP. For stdio, the server is referenced from a config file, for example ./.vscode/mcp.json:filesystem, which means mcpc can drive a locally installed MCP server package without you writing a launcher. Authentication is OAuth 2.1 with CIMD and DCR, and credentials are stored in the OS keychain rather than in a project file. On headless Linux the README says mcpc falls back to a file-based store at ~/.mcpc/credentials.json with mode 0600, unless you install libsecret and gnome-keyring and force the keychain through a dbus session.

Installing mcpc and running a first session

The README gives two install paths. Homebrew on macOS and Linux brings its own Node.js, so no separate runtime step is needed.

brew install apify/tap/mcpc

Otherwise install Node.js or Bun first and use the npm package. The package.json sets engines.node to >=22.12.0, so an older runtime will not do.

npm install -g @apify/mcpc

With the binary on your PATH, the bare command lists active sessions and saved authentication profiles. That is the first thing to run, because it tells you whether any credentials already exist on the machine.

mcpc

For a remote server you log in once, which saves an OAuth profile, then connect a named session and inspect it. The README's quickstart uses mcp.apify.com as the example host.

mcpc login mcp.apify.com
mcpc connect mcp.apify.com @test
mcpc @test
mcpc @test tools-list

The bare session reference prints server info and capabilities, and tools-list enumerates the tools the server exposes. Calling a tool passes arguments as key:=value pairs, as in the README's search-actors example.

mcpc @test tools-call search-actors keywords:="website crawler"

For scripting, add --json. The README shows the same listing in JSON form, which is the mode meant to be piped into jq, xargs and other shell tools.

mcpc --json @test tools-list

Local stdio servers work the same way once a session points at a config file. The README connects a filesystem server out of a .vscode/mcp.json file and then lists its tools.

mcpc connect ./.vscode/mcp.json:filesystem @fs
mcpc @fs tools-list

Where mcpc is the wrong tool

The design assumes shell access. If your agent runtime cannot execute commands, the whole premise collapses, and you are better off with a native MCP client library inside the framework. Adding mcpc in that setting means a second process, a session store and a credential store to manage for no gain.

Sessions are persistent, which is convenient and also a source of confusion. The help text for restart says state is lost, so anything a stateful server accumulated in the session disappears on restart. There is no documented rollback or session snapshot in the README, which matters if you are mid-workflow against a server that mutates state.

Credential handling is another boundary. The README is candid that headless and CI systems fall back to a plain JSON file at ~/.mcpc/credentials.json with mode 0600. File permissions are not the same guarantee as a keychain, and the README does not describe encryption at rest for that fallback. If your threat model rules that out, either set up the libsecret and gnome-keyring path or do not use mcpc on that host.

Finally, the payment feature is explicitly labelled experimental in both the feature list and the x402 command help. Treat it as something to evaluate, not something to depend on for money movement.

How mcpc differs from the MCP SDK clients

The obvious alternative is writing against the official MCP SDKs directly. The difference is where the protocol lives. With an SDK, MCP is embedded in your program: you import the client, hold the connection object, and the agent calls your functions. With mcpc, MCP is externalised into a process that any shell can reach, and the agent calls a command.

The practical consequences follow from that split. An SDK client gives you typed APIs and in-process error handling, and it disappears when your process exits. mcpc gives you sessions that outlive a single command, a shared OAuth profile across agents on the same machine, and a JSON mode that composes with jq and xargs. The README's progressive tool discovery is part of the same idea: instead of loading every tool definition into context up front, an agent can search for relevant tools on the fly, which the README frames as saving tokens and improving accuracy. The grep command searches tools and instructions across all active sessions, which is the human-facing version of the same capability.

You can also run both. Nothing in the README suggests mcpc replaces an SDK in your application; it replaces the need to expose MCP as a set of prompt-time functions to an agent that already has a shell.

Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-10, so it is under current development. The release history shows v0.6.0 on 2026-08-02, v0.5.1 on 2026-07-28 and v0.5.0 on 2026-07-21: a fast cadence on a 0.x version line. That is the main upgrade cost. With a zero major version, minor bumps can carry breaking changes, and the project is early enough that the CLI surface is still moving.

There is a CHANGELOG.md at the repository root, so release notes are the place to check before upgrading rather than guessing from the version number. The package is ESM only ("type": "module") and requires Node.js 22.12.0 or newer, which rules out older LTS runtimes on machines you do not control.

The licence is Apache-2.0, stated in both the README badge and package.json. That is a permissive licence with an explicit patent grant and a NOTICE file, which the repository includes. It is not a copyleft licence, so it does not force you to publish your own code. This is a description of what the licence file says, not legal advice; if you redistribute mcpc or a modified build, read the LICENSE and NOTICE text yourself.

The install path matters for lock-in. Homebrew installs a packaged binary with its own Node.js, while npm installs into your global package tree. Teams that pin tool versions in CI will want the npm route so the version is explicit in a manifest rather than resolved by the tap.

Editorial conclusion

Adopt mcpc if you debug MCP servers by hand, script MCP calls in shell, or want an agent to reach any MCP server through a single Bash() tool with OAuth handled once. Skip it if your agent framework already speaks MCP natively and you do not want a second process in the loop, or if you need a stable payment path, since x402 is marked experimental. Before rolling it out, verify that your Node.js is at least 22.12.0, that credentials land where you expect on headless Linux, and that the proxy covers the servers whose tokens you refuse to expose to generated code.

Frequently asked questions

Official sources

1. apify/mcpc on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases