modelcontextprotocol / modelcontextprotocol/inspector

TUI request/response body rendering has no size cap — risk of terminal hang on large payloads

Open
#2,407 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug v2
Dominant language
TypeScript
Stars
10.9k
Forks
1.5k
Avg merge
6h 17m
Merged PRs (30d)
151

Description

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:

  1. 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.
  2. Neither call site truncates or virtualizes the line count.
  3. 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
  • I searched existing issues and this is not a duplicate.
  • This is not a security vulnerability report (those go through the private advisory process).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with clients/tui/src/App.tsx around line 1281 and clients/tui/src/components/RequestsTab.tsx around line 267, tracing how tool-call JSON is split and rendered. Compare the large-list handling elsewhere in the TUI and Roadmap §4.11. Done means large payloads render with bounded output or virtualization while preserving terminal responsiveness.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli, performance
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.