MCP CLI: run any MCP server from the command line

An MCP server speaks JSON-RPC over stdio or streamable HTTP, which means a shell cannot call it without a client in the loop. declick is that client, compiled away: declick add mcp:<command> connects once, reads the server's tool list, and writes a CLI where every tool is a verb. From then on an agent, a script or a person runs one line from bash and gets JSON back, with --fields and --limit trimming the result before it lands.

transports stdio, streamable HTTPtool detail ~1,031 to 1,299 byteswarm call 59 msnode >=24

Written by Wes Sander, who built declick. Updated 2026-09-04. The byte and millisecond figures come from docs/bench.md and the README in the declick repository, measured 2026-09-03.

How do I compile an MCP server into a CLI?

Pass the server's launch command after mcp: for a stdio server, or its URL for a streamable HTTP server. declick spawns or connects, calls initialize and tools/list, and writes a manifest, a launcher and a SKILL.md. A private server reads a bearer token from <NAME>_TOKEN. declick engines --source mcp:... says which engine a source would land on before anything is written, and declick add --dry-run compiles and lints without writing.

$ declick add "mcp:npx -y @modelcontextprotocol/server-filesystem ." --name fs
$ declick add mcp:https://mcp.context7.com/mcp --name c7
$ declick list

stdio by command, HTTP by URL, then every adapter with its engine, verbs and auth keysexit 0

How do I list an MCP server's tools without an inspector?

declick describe <name> prints every tool as a verb with its purpose and required arguments, under 2,000 characters, from the compiled manifest and with no live connection. declick describe <name> --verb <verb> prints one tool's full argument detail, which measured between 1,031 and 1,299 bytes across nine servers with 2 to 124 tools. declick manifest <name> --schema prints the compiled contract as data, including each tool's input schema, for a script that needs the whole thing. Compared with the raw tools/list response, describe across those nine servers was 58,309 bytes against 236,818.

$ declick describe fs
$ declick describe fs --verb read-file
$ declick manifest fs --verb read-file --schema

the surface, one verb, the verb's schema as JSONexit 0

How do I call an MCP tool from bash?

declick run <name> <verb> [args] [--flags], or the short form <name> <verb> once ~/.declick/bin is on PATH. The result comes back as {"ok":true,"data":...,"meta":{...}}, and the same five exit codes apply as on every other engine: 0 ok, 1 error, 2 not found, 3 blocked, 4 auth needed. A nested payload can be unwrapped to rows with --rows path, filtered with --where k=v, projected with --fields a,b and capped with --limit N. A mutating tool takes --dry-run. A text/event-stream response is returned as an array of parsed events.

$ declick run fs read-file README.md --fields content --max-bytes 2000
$ declick run fs list-directory . --limit 20
$ declick run fs write-file notes.md --content "x" --dry-run

trimmed read, capped list, a write previewed and not sentexit 0

Why is the first call slow, and how do I fix it?

A stdio MCP server is spawned per call, and the spawn is most of what a call costs: a real filesystem server measured 4.8 seconds, almost none of it the tool. declick daemon start keeps those servers alive between runs as a detached local process, one per user. Every declick run against an mcp adapter connects to it first and reuses the running server, and the envelope says meta.daemon: true when it did. A server that takes 600 ms to start answered in 59 ms warm instead of 703 ms cold. A server idle for ten minutes is dropped, and a daemon with no servers exits. HTTP MCP adapters never touch it. The guard, the audit line and the local policy stay on the client side, so the daemon is a cache and never a way around them.

$ declick daemon start
$ declick daemon status
$ declick daemon stop

status returns {running, pid, started, servers:[{adapter, pid, calls, idleMs}]}exit 0

Can it pick up the MCP servers my agent already has?

Yes. declick setup reads the MCP servers configured in the agents it finds on the machine and compiles each one into an adapter, leaving the server configuration in place. It also puts ~/.declick/bin on PATH, adds a rules block to the agent's instruction file, and for Claude Code installs a hook that nudges the model toward the adapter. declick setup --revert undoes every one of those byte for byte, and declick doctor reports how many MCP servers are adapted.

MCP vs CLI, measured Generate a SKILL.md per adapter Read the declick overview