[Discussion] Built-in load/concurrency test mode for stress-testing MCP servers

Which client?

All / shared core

The problem

There's no way to point the Inspector at a server and generate concurrent/sustained request load to see how it behaves under stress (connection limits, backpressure, timeout tuning). Today that means writing a separate script outside the Inspector entirely, which loses all the connection/auth/transport setup the Inspector already has.

This is more speculative and architectural than a typical parity fix, so flagging it as a discussion rather than a fully-scoped request -- it sits outside the current roadmap's frame.

Solution you have in mind (optional)

A CLI mode that fires N concurrent tool calls (or a configurable rate) for a set duration, reporting a latency/error-rate summary at the end.

Alternatives or workarounds you have tried

No response

Already built it locally?

No response

Before you submit

• I searched existing issues and this is not a duplicate.
• This is a request for the Inspector itself, not for the MCP specification or an SDK.

No files, tests, or entry points are named. Start by reviewing the Inspector's shared-core and CLI architecture to determine where a load mode could fit. Done would require a scoped design for concurrent or rate-based calls, a duration setting, and latency/error-rate reporting.