Tool Use Reliability in LLM Agents

Tool calling, also called function calling, lets an LLM request external functions or APIs by emitting a structured call instead of plain text. Since OpenAI's June 2023 release, it has become the core mechanism of LLM agents. Reliability problems arise in two places. The first is call selection and argument formation, which prompt formats, training data and structured reasoning can improve. The second is execution, where timeouts after dispatch, delayed visibility and partial state updates break the common assumption that tool calls are atomic. This brief summarizes how tool calls work, what fails in practice, and which mitigations the sources report, for developers and AI agents building or evaluating agent systems.

Key concepts

Function calling (tool calling)

The capability that lets an LLM output a structured request, with a function name and arguments, for an external function or API. Both terms coexist for historic reasons. S3 · symflower.comS6 · martinfowler.com

Agent scaffolding

The system surrounding the LLM. The model asks the scaffolding to perform a tool call on its behalf, and the scaffolding executes it and returns results. S3 · symflower.comS6 · martinfowler.com

Non-atomic tool failures

Real-world behaviors such as timeouts after dispatch, delayed visibility of updates and partial state updates, which violate the assumption that a call either fully succeeds or fails. S2 · arxiv.org

Response vs effect channel

The response channel is what the agent sees; the effect channel is what actually happened on the server. The two can diverge, which causes reliability issues. S2 · arxiv.org

Verification-aware tool wrapper

A lightweight wrapper that adds postcondition verification, verify-before-retry logic and idempotency keys to tool calls, without modifying the underlying language model. S2 · arxiv.org

Decision Token

A proposed token for conditional prompts that, combined with synthetic non-function-call data, enhances relevance detection, meaning deciding whether a function call is needed. S8 · arxiv.org

Tool call lifecycle with verification

1. Describe tools to the modelEach tool gets a name, a description and a parameter description, ideally with data formatting defined via a JSON schema. The model uses descriptions to decide when and how to call.
2. Model emits a structured callThe LLM does not execute the function. It identifies the function, gathers required parameters and returns structured JSON.
3. Scaffolding executes the callThe calling application deserializes the JSON into a function call and runs it in its own runtime, often via MCP-style tool invocation.
4. Verify the postconditionRather than trusting a binary success or failure signal, the wrapper checks whether the intended effect actually occurred.
5. Retry safely if neededVerify-before-retry logic and idempotency keys prevent a naive retry from duplicating actions or corrupting state after a timeout.
6. Feed the result back into the loopThe agent observes, reasons, acts and reflects on the result, looping until the task is done.

Where reliability starts: the call contract

In function calling, the LLM does not execute the function. It identifies the appropriate function, gathers required parameters and returns structured JSON, which the program deserializes and runs in its own runtime (S6). A tool is described by a name, a description and a parameter description, ideally with data formatting defined via a JSON schema (S3). The description fields are critical, because the model uses them to decide when and how to call the function (S5). Providers differ in field naming, for example parameters in one example and input_schema in another, but the concept is identical (S5). The LLM asks the agent scaffolding to perform the call on its behalf, and how the scaffolding invokes tools was de-facto standardized via the Model Context Protocol (S3). Much of the work of explaining tools and format is handled by a provider API or modern framework (S3). Reliability therefore splits into how agents decide to call tools and how those calls are executed (S2).

Non-atomic failures and verified execution

Most agent systems assume tool calls are atomic: an operation either succeeds or fails (S2). Paradigms like ReAct and protocols like MCP focus on the mechanics of tool invocation, such as identifying and assigning parameters, but struggle with latency and out-of-sync states (S2). In distributed systems the atomic assumption is frequently violated by network timeouts after a request is dispatched, eventual consistency that delays visibility of updates, and stale-version conflicts in multi-agent environments (S2). The result is duplicate actions, incorrect task completion and cascading failures in long workflows (S2). Naive retry strategies can lead to duplicate actions and corrupted state under failures such as timeouts (S2). The proposed wrapper adds postcondition verification, verify-before-retry logic and idempotency keys. In a controlled simulated environment with injected non-atomic failures across multiple task templates, it significantly reduced duplicate actions while maintaining comparable task success rates (S2).

Improving call accuracy at the model and prompt level

Separate from execution, several approaches target whether the model chooses and forms calls correctly. Structured, template-based reasoning improves the reliability of function calls by guiding LLMs through structured, interpretable steps (S1). Research on function-calling capabilities compared two prompt formats: a dedicated role for presenting function descriptions, and embedding descriptions in the system role alongside usage instructions (S8). Its findings are that instruction-following data improves both function-calling accuracy and relevance detection, and that a Decision Token combined with synthetic non-function-call data enhances relevance detection (S8). A tailored translation pipeline also produced significant improvements in Traditional Chinese, addressing multilingual limitations (S8). Frameworks such as LangChain, AutoGen, CrewAI and LangGraph support building and orchestrating tool-calling agents with memory management (S1). These measures improve decisions, whereas verified execution addresses what happens after a call is dispatched (S2).

Atomic assumption vs verification-aware wrapper

Timeline

1. 2022
   ChatGPT's initial success late in the year preceded function calling.mbrenndoerfer.com
2. 2023-06
   OpenAI releases function calling, integrated into GPT-3.5-turbo and GPT-4.mbrenndoerfer.com
3. 2025
   Tool calling has evolved to structured reasoning, memory management and agent orchestration.sparkco.ai

Common pitfalls

• Assuming tool calls are atomic. Timeouts after dispatch, delayed visibility and partial updates mean a failure signal does not prove the action did not happen.
• Retrying naively after a timeout can produce duplicate actions and corrupted state; check the postcondition and use idempotency keys first.
• Trusting only the response channel. What the agent sees can differ from what actually happened on the server.
• Writing vague tool descriptions. The model relies on description fields to decide when and how to call a function.

Key takeaways

• Treat tool calls as non-atomic: verify postconditions before retrying, and use idempotency keys to avoid duplicate actions.
• The LLM only emits a structured call; your scaffolding executes it, so execution reliability is an application-layer responsibility.
• Improve call selection with clear JSON-schema tool descriptions, instruction-following data and structured, template-based reasoning.

FAQ

How this page is made. Built from the full text of 8 sources found with the AISA Tavily API (advanced search), refreshed weekly. A language model organizes what those sources state into the blocks above; each block links the sources it draws on, and figures that do not appear in the sources are removed.