Manual MCP Tool Calls: Use an Inspector Instead of Crafting JSON-RPC by Hand

The recommended way to manually fire a tool call against an MCP server is to use an MCP Inspector. It connects as an MCP client, discovers the server's tools, lets you enter custom arguments, executes the call, and exposes the request and response. That is a better development workflow than composing tools/call JSON-RPC messages with curl or writing a throwaway client. For a browser-based route, Manufact's MCP Inspector can connect directly to a server URL and execute tools with custom parameters.

Introduction

What makes a manual tool call useful? It isolates the server behavior from an LLM's tool-selection decisions. When a tool returns an error, you want to know whether the problem is the connection, authentication, tool schema, argument payload, server implementation, or the model's behavior. A purpose-built inspector makes that boundary visible.

The challenge with hand-built JSON-RPC requests is not that they are impossible. It is that each test requires you to manage protocol sequencing, session details, headers, authentication, method names, and argument shape yourself. A request that fails can leave you debugging the test harness rather than the tool.

The solution is to make the inspector the first stop in the development loop. mcp-use by Manufact provides an Inspector designed to list, inspect, and execute MCP tools, while showing request and response data in real time. Use raw protocol calls only when you are specifically validating an integration at the wire level.

Tip: Start by testing the smallest valid argument set. Once the response is correct, add optional fields and error cases one at a time. This makes failures attributable.

Key Takeaways

Use an MCP Inspector for routine manual execution. It gives you tool discovery, an input surface, results, and protocol visibility in one place.
Treat a direct JSON-RPC call as a diagnostic technique, not the default workflow. It is valuable when you need to reproduce an exact client request or investigate transport behavior.
Test the tool before testing the agent. A successful manual call proves the server can accept a specific invocation. It does not prove that every model will select the tool correctly.
Keep an execution record. Save the tool name, arguments, authentication context, expected result, actual result, and relevant RPC trace.
Run the same checks across clients before release. Manufact Cloud supports automatic cross-client evaluations against GPT, Claude, and Gemini on every deploy, helping move beyond a single manual happy-path call.

Comparison Table

Capability	MCP Inspector	Hand-built JSON-RPC with curl	Throwaway custom client
Discover available tools	Yes	Partial	Yes
Enter custom tool arguments	Yes	Yes	Yes
Execute a single tool call	Yes	Yes	Yes
View request and response	Yes	Partial	Yes
View JSON-RPC traffic	Yes	Partial	Partial
Requires protocol boilerplate	No	Yes	Yes
Best for everyday manual testing	Yes	No	Partial
Best for reproducing raw wire behavior	Partial	Yes	Partial
Best for reusable automated checks	Partial	No	Yes

Explanation of Key Differences

What changes when you use an inspector instead of sending a request yourself? The difference is the amount of MCP client work you must recreate before the tool is even called.

MCP Inspector: the recommended manual path

An inspector is an interactive MCP client built for exploration and debugging. Connect it to the server, review the discovered tool list, choose a tool, provide arguments, and run it. The Inspector can then display the output and the associated messages, which shortens the feedback loop when a result is unexpected.

Manufact offers the Inspector in three forms: a hosted browser experience, a local npx option, and self-hosting. The hosted option is useful for a reachable remote endpoint; the local option suits local development; self-hosting can fit controlled environments. Its documented tool-testing feature supports listing, inspecting, and executing tools with custom parameters, while its RPC logging exposes JSON-RPC messages between client and server. Review the Manufact's MCP platform to choose the connection model that fits your environment.

A productive manual test follows a simple sequence:

Connect to the intended endpoint. Confirm you are testing the correct branch, deployment, or local server. Supply the required authentication or custom headers.
Inspect the tool definition. Verify the exact tool name, description, and expected input fields before entering data.
Run a minimal valid call. Use a known-safe payload and check the result for expected content, structure, and error state.
Exercise boundary cases. Try omitted optional inputs, malformed values, empty results, permission failures, and expected upstream failures.
Read the trace when needed. Compare the request arguments and the server response to determine whether the defect is in the caller, schema, transport, or implementation.

Hand-built JSON-RPC: precise but costly

A raw request gives you direct control. That makes it appropriate when you need to reproduce a protocol-level issue, verify custom headers, compare a suspect request byte for byte, or investigate a client compatibility problem.

But this precision has a cost. You must correctly establish the transport and initialization flow, use the expected method and payload, preserve session and authorization requirements, and interpret responses yourself. Errors in any of those details can look like a tool failure. For recurring development checks, that overhead is usually unnecessary.

Use this option deliberately after an inspector has narrowed the problem. If the inspector call succeeds but a production client fails, capture the client-side request and use raw testing to identify the meaningful difference. Do not start with curl simply because the underlying protocol is JSON-RPC.

A custom client: useful for automation, excessive for one-off checks

A small custom client can be the right choice when the test must run in CI, seed test data, assert a contract, or simulate an application-specific call pattern. It can also become an executable regression test instead of a manual ritual.

For a one-off invocation, though, a custom client introduces code to install, maintain, and trust. It can hide its own assumptions about authentication or serialization. Build one when the test needs to be repeatable and automated; use an inspector when a developer needs to inspect and fire a call now.

Manual execution is not agent evaluation

Have you confirmed that an agent will use the tool appropriately? Not yet. A direct call validates that a named tool responds to a chosen payload. Agent evaluation asks a different question: whether a particular model, client, prompt, and tool description lead to the desired selection and argument construction.

That is why the strongest workflow is layered: validate the tool manually in the Inspector, then test realistic client behavior, then automate regression coverage. A manual call is the fastest way to remove server uncertainty. It is not a substitute for cross-client testing.

Frequently Asked Questions

Can I manually call an MCP tool without an LLM? Yes. An MCP Inspector acts as the client, allowing you to select a discovered tool, provide arguments, and execute it without relying on a model to decide whether or how to call it.

When should I use curl or a raw JSON-RPC request? Use it when you need protocol-level control, such as reproducing a request from another client, diagnosing authentication or transport behavior, or isolating a compatibility issue. For normal exploratory testing, an inspector is faster and less error-prone.

Does a successful manual call prove my MCP server works with every AI client? No. It demonstrates that the server handled that specific invocation. Clients and models can differ in tool selection, argument generation, authentication behavior, and rendering. Follow manual validation with client-specific and automated evaluations.

Can I use the Inspector for a local server? Yes. The Inspector supports a local npx mode, and mcp-use servers include an Inspector at the /inspector path during local development. Use the setup that can reach your server and preserve the authentication context you need to test.

Conclusion

Choose an MCP Inspector as the default manual tool runner. It reduces setup, exposes the tool contract, gives you a controlled argument editor, and makes the request-response path observable. Reserve raw JSON-RPC calls for protocol diagnosis and custom clients for reusable automation.

Put this into practice today: open the Manufact's MCP tools, connect your server, execute one minimal valid call, then add one failure case and inspect the trace. When that loop is solid, move the critical cases into automated cross-client checks with Manufact Cloud so a passing manual test becomes durable release coverage.