AgentToolProvider MCP probe: no byte-size cap on rmcp's JSON tools/list response before parsing

Open
  • Is something wrong?
#98 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust
Domain
backend, networking

Research direction

Start by checking whether rmcp 3.1.2 or a newer upstream version has a fix for the JSON response path in rmcp::transport::common::reqwest::streamable_http_client. Read operator::resources::mcp_probe::run_probe_session and its module doc comment to understand the existing transport design. Done means deciding how to address or accept the uncapped response read and documenting the resulting scope.

Written by the indexing model from the issue text.

Description

Follow-up from grid#56 review (nerdalert): grid#56 landed bounds on the tool
catalog we persist to status.discoveredTools (name length + entry count),
but not on the raw HTTP response rmcp/reqwest buffer into memory before
parsing it into a tools/list result.

Problem

operator::resources::mcp_probe::run_probe_session calls into rmcp's
Streamable HTTP client (rmcp::transport::streamable_http_client). Its SSE
path honors a configured max_sse_event_size limit, but the plain-JSON
tools/list response path
(response.json::<ServerJsonRpcMessage>() in
rmcp::transport::common::reqwest::streamable_http_client) reads the entire
response body into memory with no size cap in the rmcp version this
workspace depends on (3.1.2).

A fast MCP endpoint returning an implausibly large JSON body could exhaust
operator memory before parsing ever completes, even though the outer probe
timeout (PROBE_TIMEOUT) still bounds elapsed time.

Options

  • Upstream fix: check whether/when rmcp adds a body-size cap for the
    JSON response path (may already be tracked upstream -- worth checking
    their issue tracker before doing anything else here).
  • Bypass rmcp's session API: bound bytes ourselves via a raw reqwest
    streamed read (bytes_stream() + running total check) before handing off
    to JSON parsing. This means not using rmcp::ServiceExt::serve()/
    list_tools() for this call, which undermines this module's "reuse
    rmcp's transport, don't reimplement MCP protocol detection" design intent
    (see the module doc comment).
  • Accept the gap for now: this is a controller-initiated discovery probe
    against operator-declared endpoints, not a request-time data-plane path,
    and the operator process itself has its own resource limits. Revisit if/
    when rmcp closes the gap upstream.

Not blocking grid#56

The count/name-length bounds that landed in grid#56 already narrow the
practical blast radius once a response is read; this issue is specifically
about bounding the read itself.

Dominant language
Rust
Stars
10
Forks
24
Avg merge
1d 11h
Merged PRs (30d)
136

Getting set up

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.

More from praxis-proxy/grid

All issues in praxis-proxy/grid

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.