Function Calling as an Affordance: Making AI Actions Legible to Users
Function calling becomes a user-facing affordance when AI can trigger real actions, so schemas, previews, labels, and action states must make consequences understandable.
Function calling is invisible infrastructure until it changes something the user cares about
Function calling gives a model a structured interface to application code, data, and actions. OpenAI describes function tools as schemas the model can use to request work from external systems. [1] Technically, that may look like JSON arguments and a handler. Experientially, it is an affordance: the user is learning that asking “move my study block to Friday” can produce an actual calendar change. Once that expectation exists, the interface must communicate more than conversational fluency. It must make the possible action, target, scope, and result understandable enough that users can predict what the system will do.
The schema has a human-facing shadow
Every machine-readable function definition eventually becomes part of a user’s mental model, even if the JSON is never shown directly.
Tool names and descriptions shape both model choice and user expectations
The MCP tool specification formalizes tools with names, human-readable descriptions, input schemas, and optional behavior annotations. [2] Those fields are not merely developer metadata. They influence tool discovery and can be translated into interface labels such as “Create event,” “Send message,” or “Archive task.” Vague tools like “handle_schedule” hide consequence. Specific tools make the action space composable and easier to review. In motivational design, specificity matters because users should be able to distinguish planning from execution and low-stakes logging from consequential communication.
Capability should be demonstrated before it is assumed
Microsoft’s HAX guidance says AI systems should make clear what they can do, especially when they support multiple tasks or domains. [3] A function-enabled assistant can satisfy this by exposing examples, visible controls, connected-service indicators, or contextual action chips. The goal is not a giant tool catalog. It is to help users discover useful verbs at the moment they matter. A study coach might reveal “block focus time” after a plan is created, not during the first greeting. Capability discovery works best when it is progressive and tied to intent.
Affordances should appear at the right motivational moment
A tool is easier to trust when its availability follows the user’s goal rather than interrupting the user with a feature tour.
Previews translate machine arguments into consequences
Before consequential function calls, interfaces should render a human-readable preview: “Create a 45-minute event titled Deep Work on Friday at 9:00 AM” is more legible than raw parameters. The preview should surface recipients, dates, amounts, destinations, and whether the action is reversible. This is where structured arguments become a safety and motivation feature. A user can correct a mismatch before it becomes an external side effect, avoiding the demoralizing experience of cleaning up an action the AI confidently performed incorrectly.
After acting, the system should explain outcome rather than narrate confidence
Microsoft recommends making clear why an AI system behaved as it did, while warning that explanations can create over-trust if they merely sound persuasive. [4] For function calls, the strongest explanation is often concrete: which tool ran, with which target, what the external service returned, and what changed. The product does not need to expose hidden reasoning. It needs to expose the causal action path. “I moved the task because you asked to protect Friday morning, and the task service confirmed the new due date” is more useful than “I thought this was best.”
Explain the transaction, not the personality
Action transparency should center observable inputs and outcomes rather than anthropomorphic stories about what the model “wanted.”
Errors should be written for recovery
Anthropic’s tool-engineering guidance recommends actionable error responses because agents can often self-correct when a tool explains what was wrong with the request. [5] The same applies to users. “Failed” is weak feedback. “Calendar permission expired; reconnect to create the event, or I can save the plan without scheduling it” preserves both understanding and momentum. Tool errors are part of the affordance because they teach boundaries. A function is not truly understandable if its failure states are opaque.
A good function affordance has a complete state machine
Product teams should design function calls across states: unavailable, available, proposed, awaiting approval, running, succeeded, partially succeeded, failed, and undone. Each state needs consistent language and visual feedback. This avoids a common mismatch where the model speaks as if work is finished while the external system is still processing. In gamified experiences, the state machine should also govern rewards: do not grant completion points until the relevant action has confirmed success. Accurate state protects both trust and the integrity of the progression system.
Visible state prevents fake progress
The interface should reward completed external outcomes, not merely the assistant’s intention to perform them.
Function calling becomes safe motivation when action remains legible
The design standard is not that users understand APIs. It is that users can answer four questions: What can this AI do? What is it about to do now? What actually happened? What can I do if that was wrong? When those answers are visible, function calling becomes an empowering affordance that reduces friction between intention and action. When they are hidden, the same capability feels like mysterious automation. The motivational opportunity comes from turning a plan into a real-world step while preserving the user’s ability to predict, approve, verify, and correct that step.
Works Cited
- 01OpenAI Developers — Function Calling developers.openai.com
- 02Model Context Protocol — Tools Specification modelcontextprotocol.io
- 03
- 04
- 05Anthropic — Writing Effective Tools for Agents anthropic.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.