mcpc connect --proxy [host:]port exposes a session as a local Streamable HTTP MCP server, which makes it a valid target for the conformance suite's server scenarios — a direction we don't test at all today.
Worth noting why this is the only way to reach these: the suite's resources-*, prompts-*, completion-complete, logging-set-level and tools-call-{image,audio,embedded-resource,mixed-content} scenarios are all server-side. The 26 client scenarios (what #332 covers) contain nothing for resources or prompts, so the proxy is the only surface that can exercise them.
What it would actually catch — real pass-through risks, since the proxy forwards rather than originates:
The work is mostly fixtures. Each server scenario demands the server under test implement an exact fixture — resources-read-text wants test://static-text returning one specific string, prompts-get-with-args wants test_prompt_with_arguments returning an exact message. Since the proxy is a pass-through, the upstream behind it has to provide them. Our test servers already share test/e2e/server/fixtures.ts, so the shape is: add the conformance fixture set there, then chain conformance → mcpc --proxy → test server, plus a workflow lane.
Suggested first step: wire dns-rebinding-protection alone. It needs no fixtures, targets the highest-value property, and proves the chained harness works before committing to the full fixture set.
Lower priority than #332 — that covers 22 scenarios over the OAuth code, and the first two wired up there already found a real bug. This one tests forwarding fidelity rather than protocol decisions.
Refs #332
mcpc connect --proxy [host:]portexposes a session as a local Streamable HTTP MCP server, which makes it a valid target for the conformance suite's server scenarios — a direction we don't test at all today.Worth noting why this is the only way to reach these: the suite's
resources-*,prompts-*,completion-complete,logging-set-levelandtools-call-{image,audio,embedded-resource,mixed-content}scenarios are all server-side. The 26 client scenarios (what #332 covers) contain nothing for resources or prompts, so the proxy is the only surface that can exercise them.What it would actually catch — real pass-through risks, since the proxy forwards rather than originates:
dns-rebinding-protection— maps directly onto the proxy's Host/Origin validation, a documented security property that needed hardening once already (Fix tool-call double execution, proxy DNS-rebinding exposure, and exit-code contract violations #303)The work is mostly fixtures. Each server scenario demands the server under test implement an exact fixture —
resources-read-textwantstest://static-textreturning one specific string,prompts-get-with-argswantstest_prompt_with_argumentsreturning an exact message. Since the proxy is a pass-through, the upstream behind it has to provide them. Our test servers already sharetest/e2e/server/fixtures.ts, so the shape is: add the conformance fixture set there, then chainconformance → mcpc --proxy → test server, plus a workflow lane.Suggested first step: wire
dns-rebinding-protectionalone. It needs no fixtures, targets the highest-value property, and proves the chained harness works before committing to the full fixture set.Lower priority than #332 — that covers 22 scenarios over the OAuth code, and the first two wired up there already found a real bug. This one tests forwarding fidelity rather than protocol decisions.
Refs #332