Tool use

Tool use in artificial intelligence is the ability of a model-based system to request, coordinate, and use capabilities outside the model's ordinary token-generation process. A tool can retrieve documents, run code, query a database, call an application programming interface (API), operate a user interface, or change the state of an external system. In a typical tool loop, a large language model selects a tool and supplies arguments, an executor performs the operation, and the result is returned to the model or the surrounding application.

Tool use is broader than function calling. Function calling is a structured interface through which a model requests a developer-defined function. Tool use also includes provider-hosted search and code execution, retrieval systems, computer-control environments, protocol-discovered tools, result handling, authorization, and multi-step orchestration. The model itself does not necessarily execute a requested operation. Execution may occur in the developer's application, in a provider-managed service, or in another connected runtime, and that distinction determines where credentials, permissions, validation, and side effects are controlled.^[15][19][22]

Tools can improve access to current or private information and can make exact computation or environmental action possible. They also introduce failure modes that text-only generation does not have: an incorrect call can change real state, tool output can contain malicious instructions, credentials can be overprivileged, and an error early in a multi-step trajectory can affect every later step. A reliable design therefore treats model output as a proposed action subject to parsing, authorization, execution, observation, and, for consequential operations, confirmation.

System model

Tool contracts

A tool contract describes what an operation does and how it may be invoked. Function-calling interfaces commonly represent a tool with a name, a natural-language description, and a schema for its arguments. OpenAI's 2023 function-calling release used JSON Schema descriptions and returned structured arguments for an application to execute.^[15] Google's function-calling documentation follows the same broad separation: a model emits a structured function call, the application executes it, and the application sends the result back to the model.^[28] Anthropic similarly distinguishes client tools, which run in the user's application, from server tools, which run on Anthropic's infrastructure.^[19]

The schema limits the syntactic space of a call, but it does not establish that the requested action is correct. A value can conform to a schema and still identify the wrong account, use the wrong date, or violate a business rule. OpenAI's Structured Outputs mode was designed to make generated arguments conform to a supplied schema; OpenAI's own evaluation reported 100 percent schema adherence for gpt-4o-2024-08-06 on its test set, while the same announcement stated that Structured Outputs does not prevent mistakes within field values and can be interrupted by refusals or token limits.^[16] Schema validation and semantic validation are therefore separate checks.

Descriptions also affect tool selection. Two tools with overlapping names or vague descriptions can be confused even if both schemas are valid. Descriptions should identify the operation, its preconditions, its side effects, and the circumstances in which another tool should be preferred. Enumerations, bounded numeric fields, identifiers with explicit formats, and clear required fields reduce ambiguity. Sensitive defaults should not be inferred silently.

The execution loop

A minimal tool interaction has the following stages:

1. The application sends the model a user request and the tools that are available for the current context.
2. The model either answers directly or emits one or more tool requests.
3. The application or provider validates and authorizes each request.
4. An executor invokes the tool and returns a result or a structured error.
5. The model uses the result to answer, request another tool, ask the user for information, or stop.

This loop may require more than one model request. Developer-defined functions normally execute outside the model provider, so the application must submit the function result in a later turn. Provider-hosted tools and some remote services can instead run while the provider constructs one response.^[17][18] Describing all tools as executing "inside one request" obscures this architectural difference.

Tool results are observations, not automatically trusted instructions. A search result, document, email, or web page may contain text that resembles a command to the model. The runtime should preserve the distinction between the user's request, developer policy, tool metadata, and untrusted returned data. This separation is central to defenses against indirect prompt injection.^[14][29]

Multi-step orchestration

An AI agent can repeat the tool loop to complete a task that requires several operations. It may retrieve a customer record, check a policy, calculate a value, request confirmation, update a database, and then verify the new state. Sequential calls are necessary when one result supplies arguments for the next call. Independent calls can sometimes be executed in parallel to reduce latency.

The controller around the model is responsible for state that should not depend on free-form generation. This can include the action budget, tool-call count, permission set, prior results, pending confirmations, retry policy, and terminal conditions. The controller should distinguish a tool error from a valid empty result and should return errors in a form that permits a safe correction. Repeating a non-idempotent operation after a timeout can create duplicate transactions, so retry behavior must depend on the tool's semantics.

Long trajectories amplify small errors. If an agent chooses the wrong entity in its first lookup, later calls may be internally consistent but still act on the wrong target. Systems can reduce this risk by preserving stable identifiers, checking state before and after mutations, constraining the number of calls, and requiring explicit user confirmation before irreversible or high-impact actions.

Historical development

Research on language-model tool use developed from systems that coupled text generation with restricted interactive environments. WebGPT fine-tuned GPT-3 to answer long-form questions using a text-only web browser. Its training combined behavior cloning with human-feedback optimization, and the model collected references while browsing. In the paper's human evaluation, its best model was preferred to human demonstrators 56 percent of the time and to the highest-voted Reddit answer 69 percent of the time. Those figures describe the paper's ELI5 evaluation, not general web research quality.^[1]

TALM studied language models augmented with non-differentiable text tools for question answering and mathematical reasoning. It used demonstrations and an iterative self-play procedure to create training data for tool selection and result integration.^[2] ReAct then proposed interleaving natural-language reasoning traces with environment actions. The ICLR 2023 paper evaluated ReAct on HotpotQA, FEVER, ALFWorld, and WebShop and reported absolute success-rate improvements of 34 percentage points on ALFWorld and 10 points on WebShop over the comparison methods used in that study.^[3] ReAct is an influential prompting pattern, but tool-using systems need not expose or implement its exact reasoning-trace format.

Toolformer introduced a self-supervised method for learning when and how to insert API calls into text. Starting from a small number of demonstrations for each API, it sampled candidate calls, executed them, and retained calls that improved next-token prediction. Its experiments used a calculator, question-answering system, search engine, translation system, and calendar.^[4] The method addressed training-time acquisition of tool-use behavior rather than general authorization or production orchestration.

Gorilla studied API selection in a large and changing tool catalog. It introduced APIBench and Retriever Aware Training, which paired generation with retrieved API documentation so that a model could respond to documentation changes at test time. Its NeurIPS 2024 paper reported that its fine-tuned configurations outperformed GPT-4 in the authors' API-call evaluations.^[5] That comparison is bounded to the paper's models, documentation, and metrics and is not a current model ranking.

Research datasets expanded the scale and variety of tools. API-Bank included 73 APIs, 314 annotated dialogues, and 753 API calls in its evaluation set, together with a larger training corpus.^[6] ToolLLM collected instructions and solution paths over 16,464 REST APIs from RapidAPI.^[7] These datasets supported studies of tool selection, argument generation, and multi-step plans, but their simulated or curated interfaces do not reproduce every constraint of a live deployment.

Commercial interfaces moved structured tool requests into general model APIs. OpenAI released function calling in June 2023.^[15] Google announced function calling for Gemini Pro in December 2023 and later added parallel calls.^[28] Anthropic's tool-use interface likewise represents model requests and tool results as typed content blocks.^[19] Later provider-hosted tools added web search, file retrieval, code execution, and computer interaction. These product interfaces differ in execution location and lifecycle, so a common conceptual loop should not be mistaken for one identical API.

Forms of tool use

Developer-defined functions

A developer-defined function exposes an operation chosen by the application author. Common examples include looking up an order, checking inventory, creating a calendar event, or requesting a database query through an approved service. The application supplies the function definition, the model proposes arguments, and application code performs the call.

This pattern keeps credentials and execution outside the model. It also lets an application insert deterministic checks before a side effect. A payment tool, for example, can require an account identifier from authenticated state rather than accept an arbitrary account supplied by the model. The application can also remove tools that are irrelevant to the current user or stage of a workflow.

Retrieval and search

Retrieval tools access information that is not reliably represented in model parameters. They can search the public web, a private document collection, a database, or an information retrieval index. WebGPT illustrated an early browser-mediated approach.^[1] Modern retrieval tools are also used in retrieval-augmented generation, where the returned passages become evidence for a response.

Retrieval introduces its own pipeline of query construction, ranking, filtering, and evidence use. A relevant result can be omitted, a stale result can rank highly, or a model can cite a document that does not support its claim. Access control must be applied during retrieval, not only after generation, because returning a restricted document to the model may itself be a disclosure.

Code execution

Code tools let a system perform calculations, transform files, analyze data, or run tests. They are useful when exact execution is more appropriate than asking a language model to simulate a computation. A code tool may be a local sandbox controlled by the application or a provider-hosted environment.

Generated code is untrusted input. A secure runtime restricts filesystem paths, network access, process creation, secrets, execution time, memory, and output size. Dependencies and runtime versions should be recorded when reproducibility matters. Persistent sessions can support multi-step analysis but also carry state from earlier commands, so the lifecycle of files, variables, and credentials must be explicit.

Computer interaction

Computer use exposes observations of a graphical interface and actions such as moving a pointer, clicking, typing, scrolling, or taking a screenshot. Anthropic released a computer-use capability with Claude 3.5 Sonnet in public beta in October 2024 and described it as the first frontier model to offer the capability in public beta.^[20] In Anthropic's API design, the developer provides the environment and executes the requested computer actions; Claude does not independently gain unrestricted control of the user's desktop.

Graphical interfaces are less stable and less formally specified than APIs. Coordinates change with resolution and layout, visual elements can be obscured, and a successful click does not prove that the intended state change occurred. Computer-control systems benefit from isolated environments, restricted accounts, post-action screenshots, state verification, and confirmation before purchases, messages, deletions, or credential entry.

Protocol-discovered tools

The Model Context Protocol (MCP), released by Anthropic in November 2024, defines a way for AI applications to connect to external tools, resources, and prompts.^[21] Its specification uses a host-client-server architecture and stateful JSON-RPC sessions. A host manages permissions and policy, while a client maintains a one-to-one session with a server. Servers can expose tools as model-controlled primitives.^[22][23]

MCP standardizes communication and discovery, not the trustworthiness of a server or the safety of an operation. A host still needs authentication, authorization, consent, input validation, and logging. In December 2025, Anthropic donated MCP as a founding project of the Agentic AI Foundation, a directed fund under the Linux Foundation. The announcement said the existing MCP governance model would remain unchanged.^[24] It is therefore more accurate to describe MCP as an open interoperability protocol under neutral-foundation stewardship than as a certified "Linux Foundation standard."

OpenAI added remote MCP server support to the Responses API in May 2025, building on support in its Agents SDK.^[18] Product-specific dates matter: this was not a blanket March 2025 adoption across the Responses API, Agents SDK, and ChatGPT desktop. Support in one client or API also does not imply that every MCP transport or server is accepted without review.

Training methods

Supervised trajectories

Supervised fine-tuning can train a model on examples containing tool choices, arguments, results, and final responses. High-quality trajectories teach both positive behavior and abstention: when no tool is needed, when a required value is missing, and when the requested action is not permitted. Demonstrations should preserve the actual separation between a proposed call and its execution rather than present a side effect as text the model can simply assert.

API-Bank and ToolLLM used generated and annotated dialogues to scale this form of instruction data.^[6][7] Synthetic trajectories can cover many tools cheaply, but a generated plan may be plausible without being executable. Running calls against a stable simulator, validating the final state, and sampling trajectories for human review reduce the amount of invalid supervision.

Self-supervised and synthetic methods

Toolformer generated candidate API calls within ordinary text and kept calls that reduced language-model loss.^[4] TALM used an iterative process in which a tool-augmented model helped create new training data.^[2] These methods reduce dependence on manually written examples, but their filtering objectives are proxies. An API call that improves token prediction is not necessarily safe, cost-effective, or aligned with the user's intent.

Synthetic instruction generation can also expand coverage across APIs. ToolLLM used ChatGPT to generate instructions and solution paths for a large RapidAPI collection.^[7] Coverage by count does not guarantee diversity of real workflows, error conditions, authentication rules, or consequential side effects.

Retrieval-aware training

Large tool catalogs can exceed a model's useful context and can change after training. Gorilla's Retriever Aware Training supplied retrieved API documentation during fine-tuning, allowing tool selection to depend on current documentation rather than only on memorized signatures.^[5] Retrieval-aware designs can reduce exposure to stale tool definitions, although they inherit retrieval errors and the security risks of untrusted documentation.

Outcome-based optimization

Tool-use policies can also be optimized from task outcomes. A reward can incorporate whether the final environment state matches a goal, whether policy constraints were followed, and whether the trajectory used valid operations. OpenAI stated that o3 and o4-mini were trained with reinforcement learning to decide when and how to use tools.^[18] Public descriptions do not establish one universal reward function across providers, so claims about identical combined objectives for different proprietary models are not warranted.

Outcome rewards can be sparse. A task may fail because of selection, argument construction, execution, interpretation, or stopping, yet provide only one terminal score. Intermediate validators and error labels can improve diagnosis, but overly specific step rewards may favor one trajectory even when several safe solutions exist.

Selection and orchestration

Choosing tools

Selection becomes harder as the catalog grows and operations overlap. Supplying every tool on every turn consumes context and increases the number of plausible but wrong choices. A controller can expose only tools allowed for the authenticated user and relevant to the current workflow. Another approach retrieves a small subset of tool definitions based on the request.

Dynamic discovery separates knowing that a capability exists from loading its full schema. Anthropic's November 2025 Advanced Tool Use release introduced Tool Search, Programmatic Tool Calling, and Tool Use Examples.^[25] Anthropic reported a 37 percent token reduction in an internal complex-research evaluation using its Tool Search feature; that is a vendor-reported result for a specified setup, not a general efficiency guarantee.

The model should be able to decline to call a tool when none is appropriate. Berkeley Function Calling Leaderboard (BFCL) evaluations include relevance detection, which tests whether a model abstains when the available functions cannot satisfy a request.^[11] A system that always produces a syntactically valid call can still perform poorly if it fails to abstain.

Sequential and parallel calls

Sequential calls are appropriate when later arguments depend on earlier results. Parallel calls are useful for independent lookups, but they complicate rate limits, partial failures, ordering, and cost controls. If two calls can change related state, parallel execution may create a race even when each call is valid in isolation.

A controller can construct a dependency graph, execute only calls whose prerequisites are satisfied, and return structured results with stable call identifiers. Google added support for parallel function calls to Gemini in 2024, while later Gemini tooling added more explicit call identifiers and tool combinations on particular model and API surfaces.^[28] Those features should be dated and scoped to the relevant interface rather than treated as properties of every Gemini model.

Budgets and stopping

An agent needs stopping conditions. These may include a maximum number of calls, elapsed time, cost, repeated-error threshold, or a requirement to ask the user after uncertainty increases. A call budget is a controller mechanism even when a model is trained to economize.

Anthropic introduced beta task budgets for Claude in 2026. Its documentation describes a budget spanning thinking, tool calls, tool results, and the final response, with a running countdown presented to the model. The budget is an advisory soft signal rather than a hard cap.^[27] Hard enforcement still belongs in the runtime.

Error handling

Tool errors should be machine-readable and should distinguish invalid arguments, authorization failure, unavailable service, timeout, and a valid empty response. The controller can decide whether a retry is safe, whether a different tool is allowed, or whether the user must intervene.

An agent should not invent a successful result when execution fails. It should retain the original user goal, report the unresolved state, and avoid claiming that an external action occurred without a confirming observation. For state-changing operations, an idempotency key or a read-after-write check can prevent duplicate or phantom actions.

Evaluation

Tool use can be evaluated at several levels. A narrow function-call test compares a predicted name and argument structure with a reference. An end-to-end test executes the call and checks the resulting state. A multi-turn test also measures recovery, policy compliance, and consistency across repeated trials.

Scroll sideways for more →

Function-call correctness

Exact string comparison is often too strict because JSON objects can differ in key order and equivalent calls can have different formatting. BFCL uses abstract-syntax-tree-based evaluation for executable function calls and includes serial, parallel, multilingual, relevance-detection, and stateful categories.^[11] Scores should be reported with the benchmark release, model version, prompting or agent harness, and enabled tool set.

Argument validity is only one part of correctness. An evaluator should separately record whether the right tool was selected, whether required values were grounded in the request or prior results, whether the call was permitted, and whether abstention was appropriate. A model can pass schema validation while fabricating an identifier.

End-to-end state and policy

tau-bench evaluates conversations between a tool-using agent and a simulated user in retail and airline domains. The agent receives domain-specific APIs and policy guidelines, and evaluation compares the final database state with an annotated goal state. The benchmark introduced pass^k to measure whether an agent succeeds consistently across repeated trials.^[12]

The tau-bench paper reported that aggregate performance across its retail and harder airline settings remained below 50 percent for the studied function-calling agents and that retail pass^8 was below 25 percent. Its best GPT-4o function-calling setup exceeded 60 percent pass^1 on retail, so the paper does not support the broader claim that GPT-4o solved fewer than half of retail tasks.^[12] These historical results should not be compared with later task revisions as if they were one unchanged leaderboard.

The 2026 tau-Knowledge preprint extends this style of evaluation to a banking environment where agents must search roughly 700 interconnected natural-language documents while making tool-mediated account changes. It reports about 25.5 percent pass^1 for its strongest tested high-reasoning configurations.^[13] The paper identifies itself as work in progress, and its result is evidence about that preprint's benchmark and harness rather than a general ceiling on tool-using agents.

Stability and reproducibility

Live APIs change, disappear, rate-limit requests, and return nondeterministic data. StableToolBench proposed a virtual API server, response caching, and simulators to make ToolBench-style evaluation more repeatable.^[8] These techniques improve reproducibility but replace some real-service behavior with an approximation.

Repeated-trial metrics expose instability hidden by one successful trajectory. Reporting only the best of several attempts rewards retries without showing reliability. Conversely, requiring every run to succeed can be overly harsh for tasks with an imperfect user simulator. An evaluation should state the number of trials, aggregation rule, randomness controls, and whether failures came from the model, harness, tool, or evaluator.

Safety evaluation

ToolEmu uses a language model to emulate tool execution and another language-model evaluator to identify risky behavior. Its ICLR 2024 paper introduced 36 high-stakes toolkits and 144 test cases. Human review judged 68.8 percent of the automatically identified failures to be valid real-world agent failures, and the safest tested agent still exhibited failures in 23.9 percent of cases according to the evaluator.^[9] Both figures depend on the paper's emulator, cases, agents, and evaluator.

AgentDojo provides an extensible environment for testing prompt-injection attacks and defenses. Its initial release contained 97 realistic tasks and 629 security test cases involving such activities as email, online banking, and travel booking.^[10] The benchmark demonstrates that ordinary task success and security robustness must be measured separately: an agent can fail a benign task without an attack, or complete a task while violating a security property.

Security and control

Indirect prompt injection

Indirect prompt injection occurs when a model encounters attacker-controlled instructions inside data retrieved from an external source. Greshake and colleagues demonstrated attacks delivered through websites, documents, and other data processed by language-model applications.^[14] Tool use increases the possible impact because an injected instruction may cause a call that reads private data or changes external state.

Filtering for phrases such as "ignore previous instructions" is not a complete defense. Legitimate data can contain instruction-like text, and malicious instructions can be paraphrased or encoded. More robust controls limit what the agent can do even if model behavior is manipulated: isolate untrusted content, minimize tool permissions, restrict sensitive data flows, and require confirmation for consequential operations.^[10][29]

Excessive agency

OWASP's 2025 list identifies excessive agency as LLM06:2025. It attributes the risk to excessive functionality, permissions, or autonomy and recommends minimizing extensions, applying least privilege, and requiring user approval for high-impact actions.^[30] The identifier matters because older drafts and secondary summaries may use numbering from a different edition.

Least privilege applies to both tool exposure and credentials. A read-only task should not receive a write-capable token. A calendar assistant need not be able to delete all calendars. Per-user authorization should be checked by the executor against authenticated state rather than inferred from the conversation.

Validation and confirmation

The runtime should validate types, ranges, identifiers, business rules, and authorization after parsing a call. Values derived from tool output should carry provenance so that an attacker-controlled field is not silently reused as a destination, recipient, or command.

Human confirmation is most useful when it shows the exact pending effect. "Proceed?" is less informative than a summary of the account, recipient, amount, and whether the action is reversible. Confirmation should occur after the arguments are fixed and immediately before execution, so the confirmed action cannot change in a later model turn.

Sandboxing and isolation

Code execution, browsing, and computer interaction should run in environments appropriate to their risk. Sandboxes can restrict network destinations, mounted files, processes, and secrets. Browser sessions can use temporary profiles and nonproduction accounts. High-risk tests should not share credentials or persistent state with ordinary user workflows.

A sandbox reduces impact but does not prove correctness. A permitted action can still leak data to an allowed destination or destroy data within the sandbox. Policy checks, data-loss controls, and post-action verification remain necessary.

Logging and rollback

Audit logs should connect the user request, model version, prompt and policy context, selected tool, arguments after redaction, authorization decision, execution result, and final response. Stable call identifiers help reconstruct parallel and multi-step trajectories.

Where possible, tools should support preview, idempotency, and compensation. A transaction can be staged before commit, a file can move to trash instead of being permanently deleted, and a database update can record the prior value. Some external effects cannot be rolled back, which strengthens the case for confirmation and narrow permissions.

Applications

Tool use supports research assistants that search and cite sources, coding agents that inspect repositories and run tests, customer-service systems that read policies and update records, and analytical systems that execute calculations over private data. Provider-hosted search and file tools were incorporated into OpenAI's Responses API in 2025, alongside computer use and later remote MCP and Code Interpreter support.^[17][18] Anthropic's tool interface includes both client and server execution patterns.^[19]

These applications differ in acceptable autonomy. Retrieving a public document is normally less consequential than sending an email, purchasing an item, or modifying a production service. The same model may therefore receive a different tool set, budget, confirmation policy, and sandbox depending on the user, environment, and task.

Open specifications can make capabilities portable without making them interchangeable. MCP defines a communication architecture for tools, resources, and prompts.^[21][22][23] Anthropic separately released Agent Skills as a format for packaging instructions and supporting resources in 2025.^[26] They address related orchestration problems but are distinct specifications and should not be collapsed into one universal industry standard.

Limitations

Tool use does not eliminate hallucination. A model may select the wrong tool, invent arguments, misread a result, or add unsupported claims after a correct retrieval. Structured output reduces formatting errors, not semantic errors.^[16]

Tools add latency, cost, and operational dependencies. A multi-step task can exceed rate limits or fail because one service is unavailable. Large catalogs consume context window capacity unless definitions are retrieved dynamically. External APIs and graphical interfaces also change over time, so examples and benchmarks tied to one version can become stale.

Planning errors compound across trajectories. Recovery requires the system to recognize that an observation conflicts with its expectations rather than rationalize the failure. A retry can be dangerous when the first action may actually have succeeded. Reliable systems prefer observable state transitions and deterministic checks over trusting a fluent narrative of success.

Benchmarks isolate particular aspects of tool use. Function-call accuracy does not measure business-policy compliance, and a simulated environment cannot reproduce every live failure. Scores also combine the base model with prompts, tool definitions, retry logic, and an agent harness. Comparisons should therefore identify the full system and should not mix releases, domains, or harnesses.

Finally, access to a tool creates an authority boundary. A model's ability to generate a valid request should never by itself grant permission to execute it. Authentication, authorization, validation, consent, and monitoring remain responsibilities of the surrounding system.

References

1. ^Nakano, R., et al. "WebGPT: Browser-assisted question-answering with human feedback." arXiv:2112.09332, 2021. arxiv.org/...2112.09332
2. ^Parisi, A., et al. "TALM: Tool Augmented Language Models." arXiv:2205.12255, 2022. arxiv.org/...2205.12255
3. ^Yao, S., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." International Conference on Learning Representations, 2023. iclr.cc/...11003
4. ^Schick, T., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." Advances in Neural Information Processing Systems 36, 2023. proceedings.neurips.cc/...a906-Abstract-Conference
5. ^Patil, S. G., et al. "Gorilla: Large Language Model Connected with Massive APIs." Advances in Neural Information Processing Systems 37, 2024. proceedings.neurips.cc/...cb0d-Abstract-Conference
6. ^Li, M., et al. "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs." Proceedings of EMNLP 2023. aclanthology.org/2023.emnlp-main.187
7. ^Qin, Y., et al. "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs." International Conference on Learning Representations, 2024. arxiv.org/...2307.16789
8. ^Guo, Z., et al. "StableToolBench: Towards Stable Large-Scale Benchmarking on Tool Learning of Large Language Models." Findings of ACL 2024. aclanthology.org/2024.findings-acl.664
9. ^Ruan, Y., et al. "Identifying the Risks of LM Agents with an LM-Emulated Sandbox." International Conference on Learning Representations, 2024. proceedings.iclr.cc/...d1c5f04-Abstract-Conference
10. ^Debenedetti, E., et al. "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents." Advances in Neural Information Processing Systems 37, 2024. proceedings.neurips.cc/...ets_and_Benchmarks_Track
11. ^Patil, S. G., et al. "The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models." Proceedings of the 42nd International Conference on Machine Learning, 2025. proceedings.mlr.press/...patil25a
12. ^Yao, S., et al. "tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains." International Conference on Learning Representations, 2025. proceedings.iclr.cc/...2bb72bf-Abstract-Conference
13. ^Shi, Q., et al. "tau-Knowledge: Evaluating Conversational Agents over Unstructured Knowledge." arXiv:2603.04370, 2026. arxiv.org/...2603.04370
14. ^Greshake, K., et al. "More than you've asked for: A Comprehensive Analysis of Novel Prompt Injection Threats to Application-Integrated Large Language Models." arXiv:2302.12173, 2023. arxiv.org/...2302.12173
15. ^OpenAI. "Function calling and other API updates." June 13, 2023. openai.com/...function-calling-and-other-api-updates
16. ^OpenAI. "Introducing Structured Outputs in the API." August 6, 2024. openai.com/...ducing-structured-outputs-in-the-api
17. ^OpenAI. "New tools for building agents." March 11, 2025. openai.com/...new-tools-for-building-agents
18. ^OpenAI. "New tools and features in the Responses API." May 21, 2025. openai.com/...ls-and-features-in-the-responses-api
19. ^Anthropic. "How tool use works." Claude API documentation. platform.claude.com/...how-tool-use-works
20. ^Anthropic. "Developing a computer use model." October 22, 2024. anthropic.com/...3-5-models-and-computer-use
21. ^Anthropic. "Introducing the Model Context Protocol." November 25, 2024. anthropic.com/...model-context-protocol
22. ^Model Context Protocol. "Architecture overview." Specification revision 2025-11-25. modelcontextprotocol.io/...architecture
23. ^Model Context Protocol. "Server features." Specification revision 2025-11-25. modelcontextprotocol.io/...index
24. ^Anthropic. "Donating the Model Context Protocol and establishing the Agentic AI Foundation." December 9, 2025. anthropic.com/...hing-of-the-agentic-ai-foundation
25. ^Anthropic. "Advanced tool use." November 24, 2025. anthropic.com/...advanced-tool-use
26. ^Anthropic. "Equipping agents for the real world with Agent Skills." October 16, 2025. anthropic.com/...-the-real-world-with-agent-skills
27. ^Anthropic. "Task budgets." Claude API documentation. platform.claude.com/...task-budgets
28. ^Google AI for Developers. "Function calling with the Gemini API." ai.google.dev/...function-calling
29. ^OWASP Foundation. "LLM01:2025 Prompt Injection." OWASP Top 10 for Large Language Model Applications. genai.owasp.org/...llm01-prompt-injection
30. ^OWASP Foundation. "LLM06:2025 Excessive Agency." OWASP Top 10 for Large Language Model Applications. genai.owasp.org/...llm062025-excessive-agency