Summary
MCP Inspector CLI is useful for verifying Repl-generated MCP tools/resources/prompts, but direct command-line invocation is easy to get wrong when passing both inspector options and target process arguments.
Observed friction
This kind of invocation can accidentally let --tool-arg consume target command tokens such as dotnet:
npx --yes @modelcontextprotocol/inspector --cli \
--method tools/call \
--tool-name ops_deploy_plan \
--tool-arg service=checkout \
--transport stdio \
dotnet run -- mcp serve
A reliable pattern was to add a wrapper script:
#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")"
exec dotnet run -- mcp serve
Then call:
npx --yes @modelcontextprotocol/inspector --cli ./run-mcp.sh \
--method tools/list
npx --yes @modelcontextprotocol/inspector --cli ./run-mcp.sh \
--method tools/call \
--tool-name ops_deploy_plan \
--tool-arg service=checkout
Documentation suggestion
Add a short “Verify with MCP Inspector” section that covers both:
- source/dev mode, using
dotnet run or a wrapper script;
- packaged/compiled mode, using the installed app executable.
Why this matters
This gives coding agents and users a deterministic way to verify the generated MCP surface before configuring an actual client.
Summary
MCP Inspector CLI is useful for verifying Repl-generated MCP tools/resources/prompts, but direct command-line invocation is easy to get wrong when passing both inspector options and target process arguments.
Observed friction
This kind of invocation can accidentally let
--tool-argconsume target command tokens such asdotnet:A reliable pattern was to add a wrapper script:
Then call:
Documentation suggestion
Add a short “Verify with MCP Inspector” section that covers both:
dotnet runor a wrapper script;Why this matters
This gives coding agents and users a deterministic way to verify the generated MCP surface before configuring an actual client.