A permitting chatbot calls a parcel-lookup MCP tool and receives zoning details. What must the agent do with that tool result before the next Claude turn?

After a permitting chatbot's parcel-lookup MCP tool returns zoning details, those details must re-enter the conversation as a tool-result message before the next Claude turn. Agentic orchestration is progressive: the model's subsequent reasoning, tool selection, and fee or eligibility answers are conditioned on the visible message history. If the zoning payload never appears in that history, Claude cannot accurately reason about setbacks, overlays, or permit classes on the follow-up turn.

Appending the tool result works because it preserves the evidence trail the model needs and keeps the loop deterministic for auditors reviewing how a permit answer was formed. The result should be structured as the platform expects (tool_result tied to the prior tool_use id) so Claude can bind findings to the correct call and continue the municipal permitting dialogue.

Discarding the result to save context fails conceptually: a smaller window that omits the facts needed for the next decision produces wrong fee or zoning guidance, which is worse than a few extra tokens. Storing results only in an external cache the model cannot see fails because Claude does not magically read side caches; without an explicit message, the next turn has no zoning facts. Converting the result into a silent system note that never re-enters the message list likewise withholds evidence from the reasoner and breaks the standard tool-result contract used in agentic MCP loops.

Exam caveat: context-window management is real, but truncation or summarization must still leave the model with the facts required for the next civic decision—not delete the tool output entirely. Operational check: after parcel-lookup returns, assert a tool_result message is present in history before calling Claude again, and confirm the next response depends on those zoning fields.