Current behavior
Code Mode cloudflare.request() assumes successful API responses are either literal application/json using the traditional Cloudflare { success, result, errors, ... } envelope, or non-JSON text. Current Cloudflare APIs include successful JSON responses that satisfy neither assumption.
Reproducer 1: direct application/json object
A successful Analytics Engine SQL response such as:
{"data":[[1]],"meta":[{"name":"count","type":"UInt64"}],"rows":1}
is parsed as JSON, but because it has no success property the helper throws:
Error: Cloudflare API error: 200
I reproduced this through the real MCP execute path and Worker Loader on Node 22.23.2.
Reproducer 2: vendor JSON (application/scim+json)
A successful SCIM Groups response such as:
{"Resources":[{"id":"g1","displayName":"Admins"}],"totalResults":1}
is treated as raw text because its media type does not contain the literal string application/json. Normal structured access such as response.result.Resources[0] therefore fails.
Scope evidence
A scan of the current Cloudflare OpenAPI schema found at least 210 obvious successful application/json response schemas whose top-level shape is an array, primitive, or object without a success field. Examples include Analytics Engine SQL, Browser Rendering DevTools, Brand Protection, and Cloudforce One endpoints.
The schema also contains 30 application/scim+json response entries across SCIM Groups, Users, Schemas, ResourceTypes, and ServiceProviderConfig, including successful 2xx responses.
Root cause
src/tools/execute.ts recognizes JSON only when responseContentType.includes("application/json"), then treats any parsed payload with falsy/missing data.success as a Cloudflare API failure. Recognizing +json alone would therefore be incomplete: successful JSON APIs that do not use the legacy REST envelope need a deliberate normalization path too.
Expected behavior
Successful JSON-compatible responses should remain usable as structured data through cloudflare.request(). Traditional Cloudflare envelope responses should keep their current normalized behavior, while successful direct JSON objects/arrays/primitives and vendor-JSON payloads should not become false errors or raw strings.
Duplicate / ownership check
I searched open/closed issues and PRs for direct JSON success envelopes, Analytics Engine Cloudflare API error: 200, SCIM, application/scim+json, vendor JSON, and execute response content-type handling and did not find a matching report or active fix.
If this is useful, I can take the implementation once assigned or approved.
AI / agent disclosure
This report was prepared and reproduced with assistance from an autonomous AI coding agent operated by Keeltrace.
Current behavior
Code Mode
cloudflare.request()assumes successful API responses are either literalapplication/jsonusing the traditional Cloudflare{ success, result, errors, ... }envelope, or non-JSON text. Current Cloudflare APIs include successful JSON responses that satisfy neither assumption.Reproducer 1: direct
application/jsonobjectA successful Analytics Engine SQL response such as:
{"data":[[1]],"meta":[{"name":"count","type":"UInt64"}],"rows":1}is parsed as JSON, but because it has no
successproperty the helper throws:I reproduced this through the real MCP
executepath and Worker Loader on Node 22.23.2.Reproducer 2: vendor JSON (
application/scim+json)A successful SCIM Groups response such as:
{"Resources":[{"id":"g1","displayName":"Admins"}],"totalResults":1}is treated as raw text because its media type does not contain the literal string
application/json. Normal structured access such asresponse.result.Resources[0]therefore fails.Scope evidence
A scan of the current Cloudflare OpenAPI schema found at least 210 obvious successful
application/jsonresponse schemas whose top-level shape is an array, primitive, or object without asuccessfield. Examples include Analytics Engine SQL, Browser Rendering DevTools, Brand Protection, and Cloudforce One endpoints.The schema also contains 30
application/scim+jsonresponse entries across SCIM Groups, Users, Schemas, ResourceTypes, and ServiceProviderConfig, including successful 2xx responses.Root cause
src/tools/execute.tsrecognizes JSON only whenresponseContentType.includes("application/json"), then treats any parsed payload with falsy/missingdata.successas a Cloudflare API failure. Recognizing+jsonalone would therefore be incomplete: successful JSON APIs that do not use the legacy REST envelope need a deliberate normalization path too.Expected behavior
Successful JSON-compatible responses should remain usable as structured data through
cloudflare.request(). Traditional Cloudflare envelope responses should keep their current normalized behavior, while successful direct JSON objects/arrays/primitives and vendor-JSON payloads should not become false errors or raw strings.Duplicate / ownership check
I searched open/closed issues and PRs for direct JSON success envelopes, Analytics Engine
Cloudflare API error: 200, SCIM,application/scim+json, vendor JSON, and execute response content-type handling and did not find a matching report or active fix.If this is useful, I can take the implementation once assigned or approved.
AI / agent disclosure
This report was prepared and reproduced with assistance from an autonomous AI coding agent operated by Keeltrace.