Skip to content

Tool results are unbounded #416

Closed

Description

@Miracle656

Background

return { content: [{ type: 'text', text: JSON.stringify(data, null, 2) }] };

Whatever the upstream returned is serialised in full, pretty-printed, into the
agent's context. A Bazaar node with a large resource list — or a hostile one
returning megabytes — fills the agent's context window in one call, and
pretty-printing inflates it further for no benefit to a machine reader.

An agent that has spent its context on one tool result cannot do the task it was
called for, and the failure looks like the model being bad rather than the tool
being unbounded.

What to build

  • Cap the response size, and say clearly in the result when it was truncated —
    silent truncation is worse than the overflow.
  • Drop the pretty-printing; indentation is for humans.
  • Where a result is a collection, prefer returning a bounded page plus a count,
    with a documented way to ask for more. Coordinate with L214.
  • Cap what is read from the upstream response too, so a hostile body is never
    fully buffered in the first place.

Acceptance criteria

  • Tool results are size-bounded with a configurable limit
  • Truncation is explicit in the response
  • Output is not pretty-printed
  • An oversized upstream body is not buffered in full
  • A test covers a response that exceeds the limit

Drips Wave · Complexity: Intermediate · 150 points


Repo: Divinity-Labs/Lens. The MCP server is src/mcp/server.ts
(BazaarMcpServer) with error codes in src/mcp/codes.ts. It is started by
npm run mcp:server → examples/mcp-server/run.ts, and there is an agent
example at examples/mcp-server/agent.ts. Tests are tests/mcp.test.ts.

Run the tests: npm test. The tests are vitest, not jest. A single file
is npx vitest run tests/mcp.test.ts.

Load test (prices) is already failing on main. Not your PR.

This surface signs with a real mainnet key. examples/mcp-server/run.ts
requires MCP_AGENT_SECRET_KEY_MAINNET and builds a signer for
stellar:pubnet. Anything you change here can move real money, so prefer
failing closed, and never log, echo or test with a real secret key.

Never elide an address, a contract id or a key in code, comments or
fixtures. A previous batch shortened a contract id and five contributors
invented plausible-looking ids to fill the gap. Write it in full or not at all.

An agent is the least able caller to notice a wrong answer. It will reason
over whatever it is handed, confidently. Prefer a structured error over a
best-effort result.


Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

Activity

  1. Izzyabbey2020 commented on Oct 17, 2026

    @Izzyabbey2020
    Contributor

    @Izzyabbey2020 has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hello, I’m interested in working on this issue and would appreciate being assigned to it. Thank you.

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @Izzyabbey2020 to this issue.

  2. Jonathan-ai9 commented on Oct 17, 2026

    @Jonathan-ai9
    Contributor

    @Jonathan-ai9 has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi,I’d like to work on this issue by adding a configurable size limit for tool results and upstream response reads, with explicit truncation metadata and compact JSON output. I’ll implement bounded pagination for collections where appropriate and add Vitest coverage proving oversized results are truncated without buffering the full upstream body.

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @Jonathan-ai9 to this issue.

  3. drips-wave commented on Oct 17, 2026

    @drips-wave

    Congratulations, @Jonathan-ai9! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on October 22, 2026.

    🧑‍💻 @Jonathan-ai9: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

    Warning

    When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

    🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

    🌊 Happy Wave 🌊

  4. Miracle656 commented on Oct 23, 2026

    @Miracle656
    CollaboratorAuthor

    Delivered on main: src/mcp/limits.ts caps the upstream body while streaming (readBodyCapped) and the text handed to the agent (boundSerialized), with collections additionally capped by item count and reported as a page with a total so a truncated result cannot read as a complete one. Bounds come from the MCP_* env via config.ts and are overridable per server. Landed alongside the MCP resources work rather than through #489 — see that PR for details.

  5. drips-wave commented on Oct 23, 2026

    @drips-wave

    This issue has been completed by @Jonathan-ai9 as part of the Stellar Wave Program's 10th Wave 🥳

    😎 @Jonathan-ai9: You earned 150 Points for completing this issue! Once the Wave's rewards are finalized, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

    🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions