Tool Use and Function Calling UX is the design of how a person stays in control while an AI model invokes external tools on their behalf. Function calling, the model reaching out to APIs, file systems, and services, is the foundation of every agent product in 2026. The interesting question is no longer whether the model can call a tool. It is how the human keeps oversight while it does.
The organizing rule is a clean split: model-controlled invocation, human-approved consequence. The model decides which tool to call and when. The human approves anything that matters. Safe reads can run on their own; writes, sends, payments, and deletions get a gate. That single distinction, paired with visible tool activity and legible results, is what separates a trustworthy agent from one that surprises people with actions they never sanctioned.
The plumbing got standardized fast. The Model Context Protocol gave the industry a common way to expose tools in 2025, and it is explicit about the design layer: there should always be a human in the loop with the ability to deny a tool invocation. With the wiring solved, the differentiator moved up to UX: the approval prompt, the activity indicator, the scoped permissions, the result report.
The principle: make tool invocation visible, gate consequential actions behind human approval, show the exact call before it runs, and report results legibly.
Tool-use UX rests on a quarter-century of mixed-initiative HCI plus a 2025 protocol that turned the theory into a spec.
Horvitz (1999) wrote the foundational account in Principles of Mixed-Initiative User Interfaces. His central question is exactly the tool-approval decision: when should the system act on its own, and when should it defer to the human? He argues for weighing the expected value of acting against the cost of getting it wrong and the cost of interrupting the user. A tool call with low risk and high confidence can run; a high-stakes, uncertain action should ask. That calculus is the intellectual core of every approval gate.
Amershi et al. (2019) codified this in the Guidelines for Human-AI Interaction (the Microsoft HAX work that already underpins this library's HAX chapters). Two guidelines map directly onto tool use: make clear what the system can do, and scope services when in doubt about the user's goal. Applied to agents, that means showing which tools are exposed and asking before consequential, ambiguous actions.
The Model Context Protocol tools specification (Anthropic, 2025) turns the theory into concrete UI guidance. Tools are model-controlled, but the spec is emphatic that for trust and safety there should always be a human in the loop with the ability to deny invocations. It tells applications to provide UI that makes clear which tools are exposed, insert clear visual indicators when tools are invoked, and present confirmation prompts for operations. Its security guidance adds a sharp rule: clients should show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration. Show the call before you make it.
Anthropic's tool-use documentation (2026) and the parallel function-calling implementations elsewhere give the working mechanics: the model emits a structured call, the application can gate it, the result returns to the model. The design freedom, and the responsibility, sits in that gate.
For Users: Tool-use UX decides whether an agent feels like a capable assistant or a loose cannon. Seeing what the agent is about to do, and approving the consequential parts, is what lets a person delegate without fear.
For Designers: The approval prompt and the activity indicator are core agent interface elements. How much you show before a call, and which calls you gate, determine whether the agent earns trust or spends it.
For Product Managers: Unintended agent actions are an incident and a trust problem. A well-designed gate on consequential tools is the control that lets you ship agentic features without absorbing the blowback.
For AI Engineers: You implement the model-controlled, human-approved split. Gating writes, showing inputs before the call, and reporting results legibly are what make the agent safe to put in front of users.
Tool-use UX comes down to three primitives plus a rule about when to use them.
Auto-run safe reads; gate consequential actions. A read that fetches data can run without a prompt. A write, a send, a payment, or a delete should ask first. This is the model-controlled, human-approved split made concrete.
Show the exact call before a consequential one runs. The confirmation should display the actual tool and arguments, what will be sent and where, not a vague "the agent wants to take an action." Showing inputs before the call is also a security control against exfiltration.
Indicate tool activity in real time. When the agent is invoking a tool, show it. A clear activity indicator tells the user what the agent is doing right now, which is the difference between transparency and a black box mid-task.
Report results legibly. After a tool runs, say what happened and what changed in terms the user understands, not a raw payload. The result report closes the loop the confirmation opened.
Scale the gate to reversibility. The friction of approval should match how hard the action is to undo. A draft email can be low-friction or auto. A sent email is a heavier gate. A wire transfer is the heaviest. Tie approval cost to consequence, so the gate protects without nagging.