sequentialthinking: characterization tests for per-item size (no cap today) #5543

Which server?

sequentialthinking (@modelcontextprotocol/server-sequential-thinking)

Protocol era

Modern (2026-07-28)

MCP client

No response

The problem

Characterization proposal — explicitly not a defect claim. The documented caps for sequentialthinking are on the count dimension (thought history length) and on the stderr log formatting. The size dimension is not mentioned in the documentation at all: today a single item of essentially any size is accepted and retained. The three cases below pin that current contract, so that if a per-item cap is ever introduced deliberately, the change is visible in the test suite rather than silent.

Cases

1. A 1,000,000-character thought is accepted and counts once in the history. (Existing coverage reaches a 10,000-character thought for acceptance only; how size shows up in the history was unpinned.)
2. A 5,000-line thought is accepted. The line-count limit at lib.ts:271 applies to the display formatting of the log box, not to acceptance.
3. A 10,000-character branchId is accepted and appears verbatim in the branches array of a later response — the ID passes through validation and retention untruncated (lib.ts:217, 313). This is about the protocol response data; header/display pass-through is a separate surface.

Solution you have in mind (optional)

Proposed tests

For src/sequentialthinking/__tests__/thinking.test.ts, using its existing helpers:

import { describe, it, expect, beforeEach, afterEach } from "vitest";
import { connect, parseOk, thought, type Connected } from "./helpers.js";

describe("sequentialthinking item size (characterization)", () => {
  let conn: Connected;

  beforeEach(async () => {
    conn = await connect();
  });

  afterEach(async () => {
    await conn.close();
  });

  it("accepts a thought of a million characters", async () => {
    const result = parseOk(
      await conn.think(thought({ thought: "a".repeat(1_000_000) })),
    );
    expect(result.thoughtHistoryLength).toBe(1);
  });

  it("accepts a thought of five thousand lines", async () => {
    const result = parseOk(
      await conn.think(thought({ thought: "line\n".repeat(5000) })),
    );
    expect(result.thoughtHistoryLength).toBe(1);
  });

  it("accepts a ten-thousand-character branchId and lists it verbatim", async () => {
    const branchId = "b".repeat(10_000);
    await conn.think(thought({ branchFromThought: 1, branchId }));
    const result = parseOk(
      await conn.think(thought({ thoughtNumber: 2, totalThoughts: 3 })),
    );
    expect(result.branches).toEqual([branchId]);
    expect(result.thoughtHistoryLength).toBe(2);
  });
});

Which MCP feature does it demonstrate? (optional)

No response

Alternatives or workarounds you have tried

Near hits #5433 and #5000 concern the stderr log-box display formatting, which this proposal explicitly distinguishes from protocol-level acceptance — not duplicates. No workaround covers this; the size dimension is not mentioned in the documentation and no per-item cap exists today.

Already built it locally?

Verification

Ran against a byte-identical copy of v2/main @ 6cfff62: 3 passed. Full sequentialthinking suite with them included: 10 files, 142 passed. The tests are labelled characterization in their describe block: they record that no per-item cap exists today, and take no position on whether one should be added — that is the maintainers' call.

Prompt used

"In src/sequentialthinking's thinking tests, add characterization tests for the size dimension, which the docs don't mention (the documented caps are the thought COUNT and the stderr log box): (1) a 1,000,000-character thought is accepted and counts once in the history; (2) a 5,000-line thought is accepted; (3) a 10,000-character branchId is accepted and appears verbatim in the branches array of a later response. Label them as characterization: they pin the current absence of a per-item cap so that adding one later is a deliberate, visible change."

Before you submit

• I searched existing issues and this is not a duplicate.
• This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.