| name | mcpc |
| description | Use the mcpc CLI to work with MCP (Model Context Protocol) servers from the shell - connect to a server as a persistent session, then list and call tools, read resources, get prompts, and run async tasks. Use --json for scripting and code mode. Reach for this whenever interacting with MCP servers, calling MCP tools, or accessing MCP resources programmatically. |
| allowed-tools | Bash(mcpc:*), Read, Grep |
mcpc: MCP command-line client
mcpc maps every MCP operation to a shell command. For agents this is often more
efficient than function calling: discover the right tool on demand, then generate
shell commands (ideally with --json) instead of carrying tool definitions in context.
Mental model
- Connect once to a server — this creates a persistent, named
@session. A
background bridge process keeps the connection (and its state) alive.
- Run commands against the
@session: list/call tools, read resources, get
prompts, run async tasks. There is no one-shot mcpc <url> tools-list — connect first.
- Default output is human-readable; add
--json for machine-readable, MCP-spec
shaped output that composes with jq and shell pipelines (code mode).
Everything is self-documenting — when unsure, ask the CLI:
mcpc --help
mcpc help connect
mcpc @apify tools-call foo --help
First steps
mcpc
mcpc connect mcp.apify.com @apify
mcpc @apify
mcpc @apify tools-list
mcpc @apify tools-call <tool> q:="hi"
Connecting
Server formats accepted by connect:
mcp.example.com — remote HTTP server (https:// is added automatically)
localhost:8080 or 127.0.0.1:8080 — local HTTP server (http:// is the default for localhost and 127.0.0.1)
~/.vscode/mcp.json:filesystem — a single entry from a config file (file:entry)
~/.vscode/mcp.json — connect every entry in a config file
- (no server) — auto-discover standard configs and connect all of them
mcpc connect mcp.apify.com @apify
mcpc connect mcp.apify.com
mcpc connect ./.vscode/mcp.json:fs @fs
mcpc connect
@session is optional — omit it to auto-generate a name from the server
(mcp.apify.com → @apify). A matching session (same server + auth) is reused.
- Stdio (command-based) entries launch a local process on connect — only connect
to configs you trust. Bulk connects skip stdio entries unless you pass
--stdio.
- The MCP protocol version is negotiated automatically. Pass
--protocol-version <version> (e.g. --protocol-version 2025-11-25) to pin
one exact version — the connection fails if the server does not support it.
login / logout only accept an MCP server URL (a bare host or full
http(s):// URL) — not config files or auto-discovery.
Sessions
mcpc
mcpc @apify
mcpc restart @apify
mcpc close @apify
Session states:
- 🟢 live — ready to use
- 🟡 connecting / reconnecting — transient; retry in a moment
- 🟡 disconnected — bridge alive but the server has gone quiet; retry to reconnect
- 🟡 crashed — bridge process died; auto-restarts on next use
- 🔴 unauthorized — auth failed; run
mcpc login <server> then mcpc restart @session
- 🔴 expired — server dropped the session; run
mcpc restart @session
Discovering and inspecting tools
mcpc @apify tools-list
mcpc @apify tools-list --full
mcpc @apify tools-get <tool>
mcpc @apify tools-call <tool> --help
mcpc grep "search"
mcpc @apify grep "actor" --resources
Prefer progressive discovery: grep to find the right tool, then tools-get for its
schema. This keeps token use low instead of dumping every tool definition.
For scripts and CI, pin a tool's schema to catch breaking changes early:
mcpc --json @apify tools-get <tool> > expected.json
mcpc @apify tools-call <tool> --schema expected.json <args>
Calling tools (passing arguments)
Arguments go after the tool name. Three interchangeable styles:
mcpc @apify tools-call search query:="hello world" limit:=10 enabled:=true
mcpc @apify tools-call search config:='{"nested":"value"}' items:='[1,2,3]'
mcpc @apify tools-call search id:='"123"'
mcpc @apify tools-call search '{"query":"hello","limit":10}'
echo '{"query":"hello"}' | mcpc @apify tools-call search
JSON output (code mode)
Add --json for machine-readable output: results on stdout, errors on stderr,
shaped strictly per the MCP spec.
mcpc --json @apify tools-list | jq -r '.[].name'
mcpc --json @apify tools-call search query:="test" | jq -r '.content[0].text'
mcpc --json @apify tools-call search-actors keywords:="scraper" \
| jq -r '.content[0].text | fromjson | .items[0].id' \
| xargs -I{} mcpc --json @apify tools-call get-actor actorId:="{}"
mcpc --json with no command returns { "sessions": [...], "profiles": [...] }.
Resources and prompts
mcpc @apify resources-list
mcpc @apify resources-read "file:///path/to/file"
mcpc @apify resources-templates-list
mcpc @apify resources-subscribe <uri> <file>
mcpc @apify resources-unsubscribe <uri>
mcpc @apify prompts-list
mcpc @apify prompts-get <name> arg1:=value1
Async tasks (long-running tools)
mcpc @apify tools-call <tool> --task <args>
mcpc @apify tools-call <tool> --detach <args>
mcpc @apify tasks-list
mcpc @apify tasks-get <taskId>
mcpc @apify tasks-result <taskId>
mcpc @apify tasks-cancel <taskId>
Task commands need a server on MCP protocol 2025-11-25 that advertises the tasks
capability (tools-list flags it per tool as [task:optional|required|forbidden]).
Otherwise --task/--detach and the tasks-* commands fail with an error — they
never silently fall back to a synchronous call, so --detach output always has a
taskId or a non-zero exit code. On 2026-07-28 servers tasks are an extension mcpc
does not support yet.
Authentication
mcpc login mcp.apify.com
mcpc login mcp.apify.com --profile work
mcpc connect mcp.apify.com @apify --profile work
mcpc logout mcp.apify.com
mcpc connect mcp.apify.com @s -H "Authorization: Bearer $TOKEN"
mcpc @s tools-list
mcpc login mcp.example.com --grant client-credentials --client-id my-svc --client-secret s3cr3t
mcpc login mcp.example.com --grant id-jag --idp https://acme.okta.com \
--idp-client-id idp-client --client-id mcp-client --client-secret s3cr3t
With no auth flags, mcpc uses the default profile if one exists, otherwise it
connects anonymously. Use --no-profile to force an anonymous connection, or
--profile <name> to require a specific one.
Proxy for AI isolation
Expose an authenticated session as a local MCP server, so sandboxed AI code can use it
without ever seeing your real credentials:
mcpc connect mcp.apify.com @ai-proxy --profile ai-access --proxy 8080
mcpc connect localhost:8080 @sandboxed
mcpc @sandboxed tools-list
A proxy does not make an untrusted server safe — stdio servers still touch your system,
and HTTP servers still hold your credentials. Only connect to servers you trust.
Server-published skills (experimental)
Distinct from this guide: some MCP servers publish their own agent skills
(draft MCP extension, SEP-2640). Read them with:
mcpc @apify skills-list
mcpc @apify skills-get <name> --raw
(mcpc help --skill documents mcpc itself; skills-list / skills-get fetch skills from the server.)
Global flags worth knowing
--json
--verbose
--profile <name>
--timeout <seconds>
--max-chars <n>
--insecure
(--no-profile, --stdio, --proxy, and -H are options of connect, not global flags.)
mcpc also has experimental --x402 auto-payment for paid MCP tools — see mcpc help x402.
Debugging
mcpc --verbose @apify tools-call <tool>
mcpc @apify logs
mcpc @apify ping
mcpc @apify server-discover
mcpc @apify logging-set-level debug
mcpc clean
Exit codes
0 — success
1 — client error (invalid arguments, unknown command); grep also exits 1 on no matches
2 — server error (tool failed, resource not found)
3 — network error
4 — authentication error