A successful tool call can have no response body

A tool wrapper can report a JSON parsing error after the remote operation has succeeded. HTTP 204 means the request was fulfilled and the response has no content. If the wrapper immediately tries to decode that empty body as JSON, its parser can fail even though the HTTP exchange succeeded.

We checked the distinction with a small local HTTP server and Python's standard URL client. A 200 response containing a JSON object returned a response and parsed normally. A 204 response returned a response with zero bytes, then raised JSONDecodeError when we deliberately passed those bytes to the JSON parser. An empty 200 also failed that parser. A 503 response instead raised HTTPError in the URL client. These were development fixtures, not tests of a production assistant or an outside tool service.

Handle the response according to the endpoint's contract. When the documented successful result is 204, preserve that success and skip body decoding. When an endpoint promises a JSON document with a 200 response, an empty body needs investigation. Do not silently convert every empty response into a successful result just because its status begins with 2.

Keep the HTTP result, parsing result, and business result as separate fields. A successful request might mean that an update completed, or only that a job was accepted, depending on the endpoint. A parser exception does not tell you which business action occurred. Save the record or job identifier when the service provides one, then use its documented receipt or status check.

Before connecting a real write tool, exercise four development responses: a valid JSON document, an intentional 204, an unexpected empty 200, and a service error. Confirm that the wrapper preserves each distinction. If an uncertain write needs recovery, reconcile the original action before repeating it. Turning a decoding problem into an automatic retry can repeat work that already finished.