MCP Inspector: Remote Server Acceptance Checklist

Use MCP Inspector to verify what a server actually lets a client discover and execute before connecting it to an agent. A successful connection isn't enough: check access boundaries, expired credentials, rate limits, and operations that can spend money.

This checklist focuses on accepting a remote MCP server for use, not building a test suite. You'll use the official Inspector to collect evidence for a specific endpoint, identity, and set of tools—and identify the checks that need a separate HTTP client or load-testing tool.

Remote server acceptance checklist

Run these checks against a sandbox tenant or disposable account. Don't test destructive operations or exhaust shared quotas in production.

Treat each result as specific to the tested identity. An administrator's successful session says little about what a restricted user can access.

The official MCP Inspector repository documents the UI, CLI, and supported connection options. Keep its instructions alongside your evidence because Inspector controls can change independently of your server.

Connect without exposing your credentials

Start Inspector with:

npx @modelcontextprotocol/inspector

Open the local URL printed by the command. Use a supported Node.js installation that meets the requirements in the official repository. For repeatable acceptance runs, record the Inspector package version you used rather than silently changing your test client between runs.

Inspector runs local components that connect to servers on your behalf. Keep those components local, retain their authentication protections, and don't publish their ports through a public tunnel merely to share the screen. The repository explains its proxy authentication and configuration.

There are two useful connection paths. Use the one that matches how the agent will actually reach the server.

Remote HTTP connection

This connects Inspector to an already running HTTP endpoint. It fits acceptance testing for hosted servers, gateways, and your own deployed service.

Best for: Verifying the same authentication and network boundary your agent will encounter.

For example, select Streamable HTTP and enter the exact test endpoint URL supplied by the server operator. Don't assume a universal MCP path. Follow Inspector's authorization controls for an OAuth-protected endpoint; don't put bearer tokens in the URL.

Streamable HTTP and the older HTTP+SSE transport aren't interchangeable choices. Match the server's documented transport. The official transport specification defines their behavior; a successful connection through one path doesn't prove another is configured correctly.

Local stdio connection

This launches a local process and exchanges MCP messages over its standard input and output. It fits checking a local adapter before comparing its behavior with a hosted deployment.

Best for: Establishing whether a failure belongs to the server process or the remote deployment boundary.

For a built JavaScript server, run:

npx @modelcontextprotocol/inspector node ./dist/index.js

Replace the executable and arguments with the server's actual launch command. Launching an unfamiliar package executes code on your machine; inspect its source and installation instructions first. A successful stdio session doesn't validate the remote server's OAuth, TLS, gateway policies, or account isolation.

Prove identity and authorization separately

Begin with a fresh connection and no server credentials. For a protected server, determine which operations are intentionally public and which require authentication. Don't assume that public discovery is automatically a defect—or that hidden tool names make execution secure.

Then authenticate as a restricted test user. List tools and call a harmless operation against an object that user owns. Repeat the call with the identifier of a fixture belonging to another test tenant. The server must enforce access on execution, regardless of whether the tool appeared in discovery.

A useful test fixture is two accounts with separate documents:

Account A: document acceptance-a
Account B: document acceptance-b

Authenticated as A:
- Read acceptance-a: allowed
- Read acceptance-b: denied

These are fixture labels, not MCP methods. Substitute your server's real tool name and input schema. Keep both accounts under your control; never probe another customer's identifiers.

For an OAuth-protected remote server, test the flow rather than merely pasting an access token. You want evidence that authorization discovery, browser consent, and the return to Inspector work together. MCP's authorization specification defines the HTTP authorization framework. For implementation details, use the MCP OAuth authorization walkthrough rather than treating this acceptance check as an OAuth implementation guide.

Next, revoke the test authorization or credential through the service's supported controls. Make another protected call, then try a fresh connection. Record whether the client refreshed credentials, requested authorization again, or failed. A browser login cookie and an MCP access token are different things; signing out of a website may not revoke an issued token.

Inspector can expose integration failures in an authentication platform. It can't certify that platform's entire security configuration. Evaluate the deployed flow, not a vendor's claim that it supports MCP.

Inspect the tool contract before executing it

After connecting, list the tools and read the schemas before calling anything. Inspector gives you a way to examine this contract without asking an agent to interpret it first.

For each tool you intend to allow, identify the required arguments, accepted object identifiers, and possible side effects. Watch for generic execution tools that turn a seemingly narrow integration into broad access to SQL, shell commands, or arbitrary HTTP requests.

Choose a read-only operation with a predictable answer. For a document lookup tool, your arguments might look like this:

{
  "document_id": "acceptance-a"
}

This is an illustrative payload, not a standard MCP tool schema. Use it only if your server actually declares that argument.

Run the valid request first. Then try an invalid value that still satisfies the declared input schema, such as a nonexistent document identifier. If Inspector's form blocks schema-invalid input locally, that demonstrates client-side validation—not server-side enforcement.

Inspect the returned content as well as the success indicator. An HTTP success response doesn't necessarily mean the tool operation succeeded. MCP tool results can report execution failure through isError, as defined in the official tools specification. Conversely, a result with isError: false doesn't prove the returned business data is correct.

Check that errors don't reveal secrets, internal connection strings, or another tenant's data. Use a broader MCP security review for controls that Inspector alone can't establish, such as dependency trust and deployment hardening.

Check rate limiting without running a load test

MCP Inspector is useful for observing a rate-limit response. It isn't a substitute for a concurrency or capacity test.

Arrange a deliberately small quota in a sandbox, or obtain an approved request budget from the operator. Then make a bounded sequence of cheap, read-only calls. Record the successful calls, the first rejection, and what happens after the documented waiting period.

Separate two limiting layers:

• The HTTP endpoint or gateway may reject a request with HTTP 429 Too Many Requests.
• The MCP server may accept the protocol request but return a tool execution error because an upstream service has exhausted its quota.

These are different failure paths. Don't require every upstream limit to surface as an HTTP 429, and don't invent a standard MCP rate-limit error code. If an HTTP response includes Retry-After, record it and verify that recovery matches the service's documented behavior. The header's semantics are defined in HTTP Semantics.

A practical acceptance record might say:

Environment: isolated sandbox
Identity: restricted test user
Operation: documented read-only lookup
Request budget: agreed with operator
Observed rejection: HTTP status or tool error
Recovery: first successful call after waiting
Side effects: none expected; verified separately

Don't infer per-user isolation from one identity. A shared quota may allow one tenant to consume another's capacity. Testing that requires controlled multi-identity requests and operator visibility.

For headers or timing details Inspector doesn't expose clearly, use gateway logs or an HTTP client. Correlate the request time and identity with your MCP server logging and observability records. Remove tokens before saving any evidence.

Trace billable actions before connecting an agent

There is no universal remote MCP server price. A deployment may involve hosting charges, a subscription to the server, upstream API usage, or billing tied to tool execution. Inspector can't infer those terms from successful initialization or a tool schema.

Before calling a potentially expensive tool, establish what creates a charge and whose account pays. A search operation may consume credits; a job-submission tool may start work that continues after Inspector disconnects. A timeout doesn't prove the upstream work stopped.

Use a sandbox operation with a visible identifier. Check the provider's dashboard or accounting records afterward, and confirm whether a retry creates another job. Don't assume two identical tools/call requests are deduplicated. Any idempotency mechanism must come from that tool's documented contract.

If you're still selecting a server, AllMCPs helps you find, inspect, and install candidates. Use that discovery step to locate alternatives, then verify each operator's authentication instructions and billing terms directly. A listing isn't evidence that an endpoint passed these checks.

Save a reproducible acceptance record

Before enabling the server in an agent, save a compact record containing the endpoint, transport, test date, Inspector version, test identity role, tool names, sanitized arguments, and expected versus actual results. Include unresolved failures instead of reducing the outcome to “connected successfully.”

Keep credentials out of screenshots, copied request headers, and shared transcripts. Store document contents only when they're necessary to demonstrate the result and approved for that location.

Your next step is to repeat the safe read-only call in the intended agent client, using the same restricted identity. Inspector establishes that a direct MCP interaction works. The agent client may have different token storage, approval settings, or retry behavior, so its integration still needs a small end-to-end check.