e72d4307f3* 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>
109 lines
4.8 KiB
Markdown
109 lines
4.8 KiB
Markdown
# 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`:
|
|
|
|
```bash
|
|
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**
|
|
|
|
```bash
|
|
npx @modelcontextprotocol/inspector --cli node build/index.js
|
|
```
|
|
|
|
**With a configuration file**
|
|
|
|
```bash
|
|
npx @modelcontextprotocol/inspector --cli --config path/to/config.json --server myserver
|
|
```
|
|
|
|
**List available tools**
|
|
|
|
```bash
|
|
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/list
|
|
```
|
|
|
|
**Call a specific tool**
|
|
|
|
```bash
|
|
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**
|
|
|
|
```bash
|
|
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**
|
|
|
|
```bash
|
|
npx @modelcontextprotocol/inspector --cli node build/index.js --method resources/list
|
|
```
|
|
|
|
**List available prompts**
|
|
|
|
```bash
|
|
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)**
|
|
|
|
```bash
|
|
npx @modelcontextprotocol/inspector --cli https://my-mcp-server.example.com
|
|
```
|
|
|
|
**Connect with Streamable HTTP transport**
|
|
|
|
```bash
|
|
npx @modelcontextprotocol/inspector --cli https://my-mcp-server.example.com --transport http --method tools/list
|
|
```
|
|
|
|
**Pass custom headers**
|
|
|
|
```bash
|
|
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](../../docs/mcp-server-configuration.md): `--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.
|