Which version line?
v2 — current (@modelcontextprotocol/inspector@latest)
Which client?
TUI
Inspector version
2.7.0 (git tag) — static code-review finding, not run locally
Node version
N/A — static code review, no live run performed
Operating system (and browser, for the web client)
N/A — static code review
Transport
Not applicable / never connected
MCP server under inspection
N/A — this is a static code-review finding against the 2.7.0 tag source, not a live reproduction against a running MCP server.
Steps to reproduce
Found via static review of the 2.7.0 tag source, not a live run. The concern is structural, in the code itself:
clients/tui/src/App.tsx (~line 1281) and clients/tui/src/components/RequestsTab.tsx (~line 267) each pretty-print a tool call's JSON body by splitting the stringified result into lines and rendering one Ink <Box> per line.- Neither call site truncates or virtualizes the line count.
- A tool that returns a large payload (a file listing, an embedded resource, a large search result — all common MCP patterns) would produce thousands of
<Box> components in a single render pass.
I have not run this against a live server to confirm the exact hang threshold; flagging based on the code path itself.
Expected behavior
Large tool-call payloads render with a bounded number of lines (e.g. capped output plus a "show more" affordance), or a virtualized list, so terminal responsiveness is preserved regardless of payload size.
Actual behavior
The rendering path (App.tsx ~line 1281, RequestsTab.tsx ~line 267) has no line cap or virtualization, so an arbitrarily large payload results in an arbitrarily large number of rendered Ink components, risking a frozen or unresponsive terminal UI.
Suggested fix: cap the number of rendered lines (e.g. first N lines + "show more"), or virtualize the list the way large lists are handled elsewhere in the TUI. Roadmap §4.11 ("truncate large payloads by default") names this class of problem for other views — this looks like an unaddressed instance of it.
Logs, errors, or screenshots
No response
Already prototyped a fix?
No response
Before you submit
Which version line?
v2 — current (
@modelcontextprotocol/inspector@latest)Which client?
TUI
Inspector version
2.7.0 (git tag) — static code-review finding, not run locally
Node version
N/A — static code review, no live run performed
Operating system (and browser, for the web client)
N/A — static code review
Transport
Not applicable / never connected
MCP server under inspection
N/A — this is a static code-review finding against the 2.7.0 tag source, not a live reproduction against a running MCP server.
Steps to reproduce
Found via static review of the 2.7.0 tag source, not a live run. The concern is structural, in the code itself:
clients/tui/src/App.tsx(~line 1281) andclients/tui/src/components/RequestsTab.tsx(~line 267) each pretty-print a tool call's JSON body by splitting the stringified result into lines and rendering one Ink<Box>per line.<Box>components in a single render pass.I have not run this against a live server to confirm the exact hang threshold; flagging based on the code path itself.
Expected behavior
Large tool-call payloads render with a bounded number of lines (e.g. capped output plus a "show more" affordance), or a virtualized list, so terminal responsiveness is preserved regardless of payload size.
Actual behavior
The rendering path (App.tsx ~line 1281, RequestsTab.tsx ~line 267) has no line cap or virtualization, so an arbitrarily large payload results in an arbitrarily large number of rendered Ink components, risking a frozen or unresponsive terminal UI.
Suggested fix: cap the number of rendered lines (e.g. first N lines + "show more"), or virtualize the list the way large lists are handled elsewhere in the TUI. Roadmap §4.11 ("truncate large payloads by default") names this class of problem for other views — this looks like an unaddressed instance of it.
Logs, errors, or screenshots
No response
Already prototyped a fix?
No response
Before you submit