How a tool's execution result gets formatted and returned to the model directly affects the quality of the final generated response — a raw, unformatted, or overly verbose result can confuse the model just as much as a poorly retrieved RAG chunk.
Formatting Results for the Model
Raw API response (verbose, lots of irrelevant fields):
{
"order_id": "4521", "internal_warehouse_code": "WH-12-A",
"status": "shipped", "carrier": "BlueDart",
"tracking_number": "BD9284712...", "customer_notes": "...",
"internal_flags": {...}, "created_by_system": "checkout-v2"
}
Formatted for the model (focused, relevant):
{
"status": "shipped",
"carrier": "BlueDart",
"estimated_delivery": "2 days"
}Stripping irrelevant/internal fields before returning the result to the model reduces token usage and avoids the risk of internal implementation details leaking into a user-facing response.
Handling Tool Execution Errors as Results Too
try:
result = get_order_status(order_id)
except OrderNotFoundError:
result = {"error": "No order found with that ID. Please
verify the order number."}
# The error is still sent back to the model as a "result" —
# the model then decides how to communicate this to the user,
# rather than the application crashing or returning nothingAn error is still a valid, expected kind of tool result — the model needs to see it to respond appropriately ("I couldn't find that order — could you double check the number?") rather than the interaction failing silently or crashing.
Practical Use Case
A well-designed tool-result formatting layer is what keeps a multi-tool agent's context lean and focused as it makes several tool calls in sequence — without it, context can balloon with irrelevant fields from each call, consuming context budget and diluting the model's focus.
Common Mistakes
- Returning raw, unfiltered API/database responses directly as tool results, including internal fields that shouldn't be exposed or that waste context
- Not returning errors as explicit results, causing the model to have no information about what went wrong
- Inconsistent result formatting across different tools, making it harder for the model to reliably parse and use results
Interview Relevance
"Should you send raw API responses back to the model after a tool call, or format them first?" — format them first: strip irrelevant/internal fields, keep it focused and consistent, similar to the discipline applied to RAG context assembly.
Practice Question
Design a formatted tool result structure for a check_inventory tool, given a raw database response with 12 fields, only 3 of which are relevant to answering a customer's stock-availability question.
