The adapter is where the flattening actually costs something. One flat object arrives from the model, and something server-side has to re-split it into a route, a query string, headers and a body. None of those destinations exist in the JSON the model produced. What carries that information instead is the description text on each property, so the tutorial's stated goal of not hiding the real contract [2] amounts to a claim about documentation strings rather than a property of the schema's types.
Count the surface of the update example. Three plus one plus one plus four is nine fields on one object [14]. Four of them are the floor for a valid call: the three path identifiers the route cannot be built without [10], plus one body property, because the body is required and declares `minProperties: 1` [15]. The rest are optional.
`Idempotency-Key` is the field where a mechanical mapping goes wrong. The spec marks it `required: false` [6], and a generator that respects that produces a tool a model can call correctly forever without ever setting it. Then a tool call times out, the harness retries, and the second PATCH is a second write. Deduplication only works when the retry carries the same value as the first attempt. That makes key generation a property of the logical operation rather than of the outbound HTTP request, and the adapter is usually the only component that can tell those apart. Minting a fresh UUID per request still satisfies the schema, even though it defeats deduplication entirely.
For this mapping to transfer to your API, a few properties of the example have to hold. The endpoint needs to name one resource and one action, or the naming guidance has nothing to work with; the tutorial's own alternatives, `update_task_status`, `assign_task`, `reschedule_task`, only separate cleanly because the underlying operations do [9]. Path identifiers have to be independently meaningful, which is the argument for keeping three fields instead of one [10]. Constrained values have to be constrained in the spec, like the four-value `status` enum [8], because the enum is the only thing stopping the model from inventing a status string that round-trips as a 400. Endpoints that take a verb in the body satisfy none of this, and flattening them yields one tool that can do anything, leaving the model effectively schema-less.
One limit on the source. The excerpt ends mid-schema, at the `required` array of the ticket-list example [17]. Path, query and body are worked through in detail. The header mapping, where both the Bearer token and the retry key live, sits on the other side of the cut, so the hardest third of the problem it sets up is not in the part I can read.
