| Filename | Latest commit message | Latest commit date |
|---|---|---|
388ea5a7bd* test(cli,tui): add in-process source coverage gates (#1484) CLI and TUI source had no coverage gate: CLI tests spawned the built binary out-of-process (coverage never saw clients/cli/src) and the TUI had only two smoke tests. Regressions there were invisible to CI. CLI: - Rewrite __tests__/helpers/cli-runner.ts to invoke runCli() in-process (capture process.std*.write, map thrown errors to an exit code), preserving the CliResult shape so all existing tests run unchanged and clients/cli/src is now measured under v8 instrumentation. - cli.ts: program.exitOverride() so a commander usage error throws (catchable in-process) instead of tearing down the worker; --help / --version still exit cleanly. Drop the dead, never-imported main(). - Add a thin out-of-process e2e.test.ts that spawns the built binary for the shebang / process.exit paths the in-process runner can't reach. - Add @vitest/coverage-v8, a per-file gate (90/85/80/50) excluding only src/index.ts (binary bootstrap), and pool: 'forks' for capture isolation. cli.ts lands at ~98% lines / 100% functions. TUI: - Add @vitest/coverage-v8 and an interim per-file gate over the non-React logic (logger.ts, components/tabsConfig.ts, utils/*); the Ink components, App.tsx, and hooks/ are excluded with a documented follow-up (#1501). Add tests covering the included modules (100%). Wiring + docs: - CI runs each client's test:coverage; root test:cli / test:tui (used by validate) and root test:coverage now enforce the gates. - gitignore clients/**/coverage; update AGENTS.md and client READMEs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(cli): clarify in-process runner footguns from PR #1502 review Review notes on the in-process CLI test runner (no behavior change): - Warn in runCli's docblock that --help/--version must NOT go through the in-process runner: exitOverride only re-throws non-zero exits, so exitCode 0 falls through to process.exit(0) and would kill the vitest worker. Those belong in the out-of-process e2e.test.ts layer. - Document that a timeout orphans the uncancellable invokeCli promise (its stdio subprocess stays alive; later writes hit the restored stdout) — a known, acceptable trade-off on the hang-only failure path. - Fix a stale reference to the removed main() (errors now route through index.ts). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(cli): fix remaining stale main() reference in vitest exclusion comment PR #1502 re-review caught a second stale `main()` mention (the first was fixed in 52c23e41). src/index.ts inlines the bootstrap as runCli(process.argv).then(...).catch(handleError) — there is no main(). Comment-only; no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore: compose root test:coverage from per-client scripts Replace the brittle inline cd-chain with a composition of the existing test:cli / test:tui scripts plus a new matching test:web. Behavior is unchanged (web → cli → tui coverage gates) but there's a single source of truth for each client's coverage invocation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| __tests__ | ||
| src | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| tsup.config.ts | ||
| vitest.config.ts | ||
MCP Inspector CLI Client
The CLI mode enables programmatic interaction with MCP servers from the command line. It is ideal for scripting, automation, continuous integration, and establishing an efficient feedback loop with AI coding assistants.
Running the CLI
You can run the CLI client directly via npx:
npx @modelcontextprotocol/inspector --cli node build/index.js
The CLI mode supports operations across tools, resources, and prompts, returning structured JSON output.
Examples
Basic usage
npx @modelcontextprotocol/inspector --cli node build/index.js
With a configuration file
npx @modelcontextprotocol/inspector --cli --config path/to/config.json --server myserver
List available tools
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/list
Call a specific tool
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/call --tool-name mytool --tool-arg key=value --tool-arg another=value2
Call a tool with JSON arguments
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/call --tool-name mytool --tool-arg 'options={"format": "json", "max_tokens": 100}'
List available resources
npx @modelcontextprotocol/inspector --cli node build/index.js --method resources/list
List available prompts
npx @modelcontextprotocol/inspector --cli node build/index.js --method prompts/list
Remote Servers
You can also connect to remote MCP servers using HTTP or SSE transports.
Connect to a remote MCP server (default is SSE)
npx @modelcontextprotocol/inspector --cli https://my-mcp-server.example.com
Connect with Streamable HTTP transport
npx @modelcontextprotocol/inspector --cli https://my-mcp-server.example.com --transport http --method tools/list
Pass custom headers
npx @modelcontextprotocol/inspector --cli https://my-mcp-server.example.com --transport http --method tools/list --header "X-API-Key: your-api-key"
When a server is loaded from a --catalog/--config file, its per-server settings (headers, connection/request timeouts, and OAuth) are applied to the connection — the same resolution the TUI uses. A --header flag overrides the file's headers for that run while leaving the file's timeouts and OAuth in place.
Options
MCP server (which server to connect to)
Options that specify the MCP server (catalog/config file, ad-hoc command/URL, env vars, headers) are shared by the Web, CLI, and TUI and are documented in MCP server configuration: --catalog (writable catalog, seeded if missing; default ~/.mcp-inspector/mcp.json or MCP_CATALOG_PATH), --config (read-only session, errors if absent), --server, -e, --cwd, --header, --transport, --server-url, and the positional [target...]. --catalog and --config are mutually exclusive, and neither combines with an ad-hoc target.
CLI-specific (what to invoke)
| Option | Description |
|---|---|
--method <method> |
MCP method to invoke (e.g. tools/list, tools/call, resources/list, prompts/list). |
--tool-name <name> |
Tool name (for tools/call). |
--tool-arg <key=value> |
Tool argument; repeat for multiple. Use key='{"json":true}' for JSON. |
--uri <uri> |
Resource URI (for resources/read). |
--prompt-name <name> |
Prompt name (for prompts/get). |
--prompt-args <key=value> |
Prompt arguments; repeat for multiple. |
--log-level <level> |
Logging level for logging/setLevel (e.g. debug, info). |
--metadata <key=value> |
General metadata (key=value); applied to all methods. |
--tool-metadata <key=value> |
Tool-specific metadata for tools/call. |
Why use the CLI?
While the Web Client provides a rich visual interface, the CLI is designed for:
- Automation: Ideal for CI/CD pipelines and batch processing.
- AI Coding Assistants: Provides a direct, machine-readable interface (JSON) for tools like Cursor or Claude to verify changes immediately.
- Log Analysis: Easier integration with command-line utilities (like
jq) to process and analyze MCP server output.
Development
Run the test suite (and coverage gate) from clients/cli/:
npm test # build test-servers + binary, then run all tests
npm run test:coverage # same, under the per-file coverage gate
Tests run the CLI in-process (importing runCli()) so src/ is measured
under coverage, with a thin out-of-process spawn layer for the real binary. See
__tests__/README.md for details.