$385 to Dublin, and the agent quietly dropped a whole city from the answer. My own tool told it, in the response, and it still said nothing.

Five cities went into one search this morning. Four came back with a price and Lisbon came back with nothing at all. The question was the cheapest round trip from JFK to Dublin, Lisbon, Barcelona, Madrid or Milan, leaving Jan 13 to 15 2027, seven nights, one stop maximum. It went through an MCP server I run, so I have the raw tool result next to the answer. It made one tool call instead of fifteen, which is what the tool description asks for, and I was pleased about that. It came back with Dublin at $385 on Icelandair, Barcelona and Madrid at $519, Milan at $559, and it said the $385 was "decent, not a steal" because Google's tracked range for that route is $345 to $440. All of that is correct. Lisbon has no price in the answer. Not "no flights to Lisbon". Just absent. What happened is that the model picked limit: 12, there were more than 12 rows, and the three Lisbon rows got cut. My server knows this can happen, so the response carries a field that spells it out: "note": "`limit` was 12, which is fewer than the number of date/destination combinations that returned flights, so 3 of them have no row in `results`: 2027-01-13 to LIS, 2027-01-14 to LIS, 2027-01-15 to LIS. Those searches ran and found flights; the answer simply had no room for them. Raise `limit` to see them." That sentence was in the context window. The model read it and did not pass it on. Lisbon was $599, by the way, which would not have changed the recommendation, and that is not the point. So the thing I had wrong: putting the omission in the payload is necessary and does close to nothing on its own. A note is prose, and prose is skippable. If a gap matters, the schema has to make an answer impossible without it. Next thing I am trying is a "missing" array that has to be empty before search_status can be "ok". What have you got that actually made a model surface its own blind spot?