request-state-complete accepts tool-error results and completions missing its documented state-ok marker

[YS-OH-CORE]

Scope

While examining the concrete prerequisite problem in #440, I found a separate round-2 false-positive in InputRequiredResultRequestStateScenario. This case uses a non-empty, correctly keyed inputRequests map, so it does not depend on #440's manufactured "undefined" key. Credit for that original issue remains with its reporter.

Inspected main commit: 7169291ec0b68eb370fddcd9947313ab0d5e4156.

• Scenario and round-2 check
• Complete-result helper

The fixture description requires round 2 to validate echoed state and return text containing state-ok. The check only rejects a JSON-RPC error, an absent result, or resultType: "input_required". It never checks the tool-result isError flag or the documented marker.

Executed local probe

I copied this scenario's run body into an isolated TypeScript wrapper, transpiled it with TypeScript 5.8.3, and executed it on Node 22.16.0. sendRpc was a controlled two-response stub; the type guards and mock-elicitation logic matched the pinned helper. Round 1 always returned a non-empty confirm elicitation and requestState: "s-1".

Round-2 response	Observed sep-2322-request-state-complete	Expected under this fixture's stated contract
complete, text state-ok	SUCCESS	SUCCESS
complete, text ordinary completion	SUCCESS	FAILURE: missing fixture marker
complete, isError: true, text state rejected	SUCCESS	FAILURE: tool error
complete, isError: true, text state-ok, but execution failed	SUCCESS	FAILURE: marker must not override tool error
JSON-RPC error	FAILURE	FAILURE
another input-required result	FAILURE	FAILURE
no result	FAILURE	FAILURE

Execution boundary: this is an isolated execution of the copied check body, not an upstream CLI run, HTTP transport test, or real-SDK conformance result. A local candidate adding both result predicates produced the expected outcomes in all seven cases. No upstream patch is asserted tested or ready to merge.

Minimal predicate reproduction

This can also be seen without any SDK dependencies; save as probe.cjs and run node probe.cjs:

const assert = require('node:assert/strict');
// Logic of the pinned helper and successful-result branch, types removed.
const isCompleteResult = r => !!r && r.resultType !== 'input_required';
function currentCheck(r2) {
  const result = r2.result;
  const errors = [];
  if (r2.error) errors.push('JSON-RPC error');
  else if (!result) errors.push('No result');
  else if (!isCompleteResult(result)) errors.push('Not complete');
  return errors.length === 0 ? 'SUCCESS' : 'FAILURE';
}
for (const result of [
  {resultType:'complete', content:[{type:'text', text:'ordinary completion'}]},
  {resultType:'complete', isError:true, content:[{type:'text', text:'state rejected'}]}
]) {
  assert.equal(currentCheck({result}), 'SUCCESS');
  console.log(currentCheck({result}));
}

Both print SUCCESS, despite violating the scenario's documented successful-completion requirement.

Suggested regression scope

Extend the existing MRTR negative-test/fixture path, rather than adding another runner: exercise both kinds of erroneous completion, keep a state-ok success control, and retain the JSON-RPC-error/input-required controls. Keep the same check ID for pass and fail. The marker requirement is fixture-specific, not a new normative MCP requirement for all servers. Checking a marker also cannot prove genuine state validation by itself; the separate tampered-state scenario remains necessary.

This does not show that a broken implementation passes the entire suite. It shows that this one named check can report successful state validation on these completions. Searched existing issues for state-ok and request-state plus isError; no matching report was returned.

Prepared by Youngseok Oh (@YS-OH-CORE) with Zero (ChatGPT); AI-assisted source analysis and local probe. Public synthetic inputs only.

[YS-OH-CORE]

Executed follow-up: actual upstream imports, HTTP and the built CLI

I replaced the isolated-method probe with a run of the real code at 7169291ec0b68eb370fddcd9947313ab0d5e4156, and prepared a narrow candidate in the existing scenario/test/fixture files.

Successful run 35029898838 · Executed verifier · Applyable three-file patch · Results and scope

• Same 12 tests: four unchanged MRTR cases plus eight new HTTP cases. Before changing the check: 8 pass / 4 targeted assertion failures. After: 12 pass. The failures are missing marker, empty content, tool error, and tool error containing the marker. Positive controls include the marker in a second text block; JSON-RPC-error and further-input controls remain failures.
• Official CLI, unchanged bundled everything-server: 3/3 checks pass before and after.
• Official CLI, each of the three reported bad completions: target changes from SUCCESS / exit 0 to FAILURE / exit 1. Round 1 and wire-schema-valid stay successful. These are semantic false positives, not malformed-wire rejections.
• Candidate full npm test: 630 passed, 0 failed, 0 pending, 0 todo. This includes the 12 focused cases. Both builds, typecheck, touched-file ESLint and git diff --check passed.

The patch leaves isCompleteResult unchanged. Tool errors remain complete protocol results, but cannot establish this fixture's successful state validation. The state-ok check is only the diagnostic marker already documented here, not a new general MCP requirement. It does not replace the separate tampered-state test.

Boundary of the first run: actual imports, upstream test setup, loopback HTTP, CLI and wire instrumentation, without a copied scenario or stubbed RPC helper. Node 22.16.0 and the upstream lockfile resolved SDK 1.29.0. That bundled everything-server loads the SDK, but MRTR follows its explicit stateless handler. The complete suite was run on the candidate, not as a full baseline differential.

I downloaded and inspected the original 147746-byte artifact (10420617644), checked all 630 assertion records and CLI outputs, and applied the saved patch to retained originals to confirm byte-identical candidate files. Patch SHA-256: 6b54c4129d72691775a01c911515dee4bc59036262a957e3f9bf61c0bac7faa9.

Added 16 September: separately maintained Go SDK, same patch

The missing separate-SDK check is now executed in run 35035058977, using modelcontextprotocol/go-sdk@fbd36cb7870176bfc3e8e423df697cf110d0f927, Go 1.25.0, its native mcp.NewStreamableHTTPHandler, and the same conformance CLI. The candidate patch is byte-for-byte unchanged.

Go SDK diagnostic	Original check	Patched check
Unmodified request-state	3/3 pass	3/3 pass
Injected missing marker	target SUCCESS, exit 0	target FAILURE, exit 1
Injected tool error, no marker	target SUCCESS, exit 0	target FAILURE, exit 1
Injected tool error retaining marker	target SUCCESS, exit 0	target FAILURE, exit 1
Unmodified multi-round	4/4 pass	4/4 pass
Unmodified tampered-state	2/2 pass	2/2 pass

These are 12 CLI executions. All wire-schema checks and all first-round target prerequisites remain successful. The raw tool result in each target before/after pair is identical. The bad modes are deliberate negative controls in one diagnostic handler, not faults claimed to exist in the unmodified Go SDK. Its library, serialization and HTTP transport remain untouched. The fixture source is restored to its original bytes afterward.

Cross-SDK verifier · Full scope and artifact identity. Artifact 10422569318 was downloaded and checked against its source, 12 raw check files and exact fixture mutations. This is authored cross-implementation execution, not independent human review or a deployed-service test.

Prepared by Youngseok Oh with Zero (ChatGPT), with substantial AI assistance. New contribution code is offered under the project's Apache-2.0 terms; existing notices remain intact. No upstream acceptance or merge is asserted. The candidate uses the existing broken fixture and negative-test file, not another conformance runner. Would this scoped guard and regression set fit the intended fixture contract?