Question
Translation can preserve the fact that an operation failed while still losing the machine-readable meaning of that failure. A target may even expose structured error data without preserving the source Problem Details object.
This experiment therefore asks a narrower question than whether MCP supports errors:
Does source error meaning remain deterministically machine-recoverable after OpenAPI→MCP translation?
Invariant
No silent loss + no unsupported gain.
A source semantic must remain deterministically machine-recoverable at the target boundary. Translation may change representation, but it must not silently demote machine-readable semantics into diagnostic prose or manufacture unsupported machine claims.
The profile is representation-neutral. It does not require one particular MCP carrier, and exact source bytes need not survive if the exercised source data model remains machine-addressable.
Frozen profile
The experiment freezes a 12-case corpus around RFC 9457 behaviors that matter to machine consumers. The cases exercise explicit and default problem type identity, occurrence identity, media-type gating, scalar and nested extensions, unknown future extensions, localized human text, separation of observed HTTP status from body status, and negative controls against prose mining and unsupported retryability inference.
One case is intentionally outside the profile because it uses ordinary application/json rather than application/problem+json. The remaining 11 cases are evaluated by the same frozen carrier-neutral adapter and oracle.
Results
The three tested translation architectures reproduced the same bounded semantic-loss class, but not through one identical defect.
Three observed loss mechanisms
FastMCP 3.4.7
On the tested official-package path, a 200 JSON success from the same generated tool remained machine-addressable as structured content. The non-2xx RFC 9457 Problem Details response, however, was parsed and then exposed through diagnostic error text without a machine-addressable Problem Details carrier recognized by the frozen profile.
CNOE openapi-mcp-codegen
The generated API client retained the upstream non-2xx JSON under an internal details field. The generated MCP tool then discarded those details and returned a generic structured error before the MCP result boundary.
This is a distinct OpenAPI→MCP translation architecture, but its generated server uses FastMCP as a runtime dependency. The observed loss was localized in generated translation code before that runtime boundary, so this experiment does not describe the two as completely independent MCP runtime implementations.
nihal1294/openapi-to-mcp
This target emitted richer structured error metadata, yet the source Problem Details semantics exercised by the profile were still not recoverable through the accepted machine carriers.
Structured target errors are not, by themselves, semantic preservation.
Constructive control
A non-normative reference mapping tested whether the observed loss could instead be explained by an inability of the tested MCP carrier capacity to represent the exercised semantics.
The reference carried the Problem Details object as an explicitly typed application/problem+json embedded MCP resource and separately retained observed HTTP transport facts in namespaced metadata. The mapping preserved the distinction between an observed HTTP 502 and a Problem Details body reporting status 503, and it introduced no retryability claim when the source supplied none.
Across an official MCP 2026-07-28 TypeScript client/server stdio protocol path, the same frozen corpus, adapter, and oracle produced 11 PRESERVED, 0 LOSS, 0 INVENTED, and 1 NOT_APPLICABLE.
A text-only demotion of the same Problem Details object remained LOSS, providing a negative control against treating JSON-looking diagnostic text as machine-addressable preservation.
Clean-room reproduction
RC1 repeated the constructive control from a fresh exact-lock dependency materialization and rebuild. The run began without prior node_modules or compiled output, used a new empty npm cache, started fresh fixture, server, and client processes, negotiated MCP 2026-07-28, and again produced 11 PRESERVED, 0 LOSS, 0 INVENTED, and 1 NOT_APPLICABLE.
This strengthens reproducibility of the constructive existence proof. It does not add a fourth translator target and does not establish cross-platform, multi-laboratory, or ecosystem-wide reproducibility.
Strongest supported conclusion
For the frozen profile tested here, semantic loss is not forced by the tested MCP carrier capacity.
The constructive control shows that the same exercised RFC 9457 semantics can cross the tested official MCP protocol boundary while remaining machine-addressable. The losses observed in the three tested translators are therefore not explained by an inability of that tested MCP data model and SDK path to carry those semantics.
What this does not establish
- that all OpenAPI→MCP converters lose RFC 9457 semantics;
- that the three tested translators statistically represent the ecosystem;
- that MCP cannot carry structured errors;
- that an embedded resource is the only conforming preservation strategy;
- that the 12-case corpus completely covers RFC 9457;
- that every inferred retryability claim is semantically invalid;
- that this profile is an accepted MCP, IETF, or industry standard;
- that these experiments alone establish downstream user harm or agent misbehavior.
Reproducible artifact
The frozen release candidate is archived independently of this explanatory website. The GitHub repository contains the executable profile, conformance corpus, oracle, evidence summaries, constructive reference, clean-room provenance, claim ledger, and release verifier.
- Version
- v0.1.0-rc1
- Release commit
- 07bcc4d7b13402c120fb26d28a35f1af5a271f61
- Version DOI
- 10.5281/zenodo.21911147
- All-versions DOI
- 10.5281/zenodo.21911146
- Release ZIP SHA-256
- f1a7dbddbeecb1cee1cdc84f34ff89b99c653267a10cfb51ebc8bfdf4df9b158
- Status
- Experimental release candidate