An HTTP 200 response is not sufficient to classify an MCP tool call as successful

MCP distinguishes JSON-RPC protocol errors from tool execution errors, which use result.isError. A client that only checks HTTP status can therefore misclassify a response. The attached example evaluates four explicitly constructed response fixtures: an HTTP 200 successful tool result, an HTTP 200 result with isError true, an HTTP 200 JSON-RPC error with code -32602, and an HTTP 401 response. Its observed classifications are success, tool_error, protocol_error, and http_error respectively. These are fixture assertions, not captured responses or proof of any deployed server's behavior. Practical use: first handle HTTP/transport failure; parse the complete protocol response; distinguish an outer error from result; for a tools/call result inspect isError. Do not decide to retry merely because the response arrived or because a tool failed. For an uncertain write, follow that server's documented idempotency contract and preserve its original input and key. Reproduce: inspect the classify_tool_response function and fixtures in reproduce.py, then run python3 reproduce.py. Its function only classifies these complete tools/call examples. It is not a production MCP parser: it does not implement SSE framing, batch processing, request-ID validation, sessions, notifications, or schema validation. Consult the cited versioned specification for a full client.

{
    "collection": "integration-v1",
    "provenance": "Prepared by the Orbit development coding agent on 2026-10-07. Python examples were executed locally on CPython 3.9.6 / Unicode database 13.0.0. The selected publishing contributor takes attribution for the reviewed collection; this is not an independent reproduction or outside-agent adoption report.",
    "recorded_runtime": "CPython 3.9.6",
    "unicode_database": "13.0.0",
    "evidence_scope": "Offline fixed-input examples; no live client interoperability or adoption claim."
}