* feat(cli): lift config-file headers/timeouts/OAuth into serverSettings (#1482) The CLI resolved file-sourced servers via resolveServerConfigs(), which returns bare MCPServerConfig and dropped disk-level headers, timeouts, and OAuth — CLI connections from a --catalog/--config file silently ignored them. The TUI already lifted these via mcpConfigToServerEntries(). Extract the TUI's catalog/config -> per-server-settings resolution into a shared core module (core/mcp/node/servers.ts: loadServerEntries + selectServerEntry) and route both CLI and TUI through it, so the two share one file->settings path. --header still overrides the file's headers for the run while preserving the file's timeouts/OAuth. - core: add loadServerEntries/selectServerEntry/headersToServerSettings - tui: tui-servers.ts re-exports the shared core helpers (no logic dup) - cli: resolve via loadServerEntries + selectServerEntry; drop the CLI-only conflict check and bare-config path - tests: core servers.test.ts (settings lifting, header merge/override, stdio overrides, seed/error/conflict, selection); CLI integration tests asserting a config header is sent over HTTP and --header overrides it - docs: CLI README note on file settings being applied Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(core): address #1500 review — dedup overrides, drop dead wrapper, clearer error, spec refresh - Remove the now-unused resolveLaunchServerConfigs() wrapper (both CLI and TUI route through loadServerEntries now); migrate its default-catalog launch tests to compose withDefaultCatalogPath + resolveServerConfigs. - Deduplicate applyStdioOverrides against config.ts applyOverrides: export the latter (now trims cwd) and reuse it in servers.ts. - selectServerEntry's unknown-name error is source-agnostic ("not found" not "not found in config file") since entries may be a single ad-hoc default, where "config file" would mislead. - Refresh specification/ docs (v2_cli_tui_launcher.md, v2_catalog_launch_config.md): CLI/TUI resolution now via loadServerEntries/selectServerEntry; mark gap G1 resolved (#1482); withDefaultConfigPath → withDefaultCatalogPath. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(cli): extend smoke:cli to cover #1482 lift→serverSettings Adds end-to-end smoke coverage for the config-file headers/timeouts/OAuth lift introduced in #1482: - unknown --server now errors source-agnostically ("not found") - multi-server catalog selection via --server (and the omit-it error) - --header merge does not break the stdio connect path - HTTP transport: a config-file `headers` object is lifted onto the wire, and a CLI --header overrides it (verified against an in-process test server's recorded requests via a non-blocking spawn) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4.8 KiB
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.