1. Introduction
An AI model can understand language and generate useful responses, but many real applications require capabilities beyond text generation.
A customer support assistant may need to retrieve an order. A scheduling assistant may need to check availability. A business assistant may need to search a database or retrieve information from an internal system.
Function calling and tools provide a structured way for an AI application to connect a model with external capabilities.
The important principle is that the AI model can request an operation, while the application remains responsible for deciding whether and how that operation is actually executed.
2. What Is a Tool?
A tool is a capability that an AI application can make available to an AI model.
A tool might perform an operation such as:
- Search a database
- Retrieve an order
- Look up product information
- Check appointment availability
- Perform a calculation
- Search approved documents
- Send information to another system
The tool itself is normally implemented by application code or by an external service.
3. What Is Function Calling?
Function calling is a mechanism through which an AI model can produce a structured request for a particular function or tool.
Instead of generating a sentence such as “I will check the order,” the model can produce structured information indicating that an order lookup function should be used and identifying the required arguments.
The application then receives that request and decides what should happen next.
4. The Model Does Not Automatically Execute the Function
This distinction is fundamental.
The model can request that a function be called, but the model itself does not automatically gain unrestricted access to the underlying database, operating system, or external service.
The application receives the requested operation and controls execution.
This separation provides an important security boundary.
5. A Basic Tool Workflow
A typical workflow looks like this:
- User sends a request
- Application prepares the relevant context
- AI model receives the request and available tool descriptions
- Model determines that a tool may be useful
- Model produces a structured tool request
- Application validates the request
- Application checks authentication and authorization
- Application executes the approved tool
- Tool produces a result
- Application provides the result to the model
- Model generates an appropriate response
- Application returns the response to the user
6. Describing Tools to a Model
The application normally provides information describing each available tool.
A tool description can identify the function name, purpose, expected arguments, and argument data types.
For example, an application might define a tool called get_order_status that accepts an order identifier.
Clear descriptions help the model understand when a tool is relevant and what information the tool expects.
7. Tool Arguments
Tools often require arguments.
A weather lookup may require a location. An order lookup may require an order identifier. A database search may require a search term and optional filters.
Arguments should be represented in a predictable structure so that the application can validate them before execution.
8. Structured Tool Requests
Structured tool requests are important because application code should not need to interpret arbitrary natural-language instructions before executing an operation.
For example, instead of parsing a sentence such as “Please find order 4582,” the application can receive a structured request containing a function name and an order identifier.
This makes validation and software integration easier.
9. Tool Selection
The model may decide that one of the available tools is useful for a particular request.
For example, if a user asks for the status of an order, the model may request an order lookup tool.
However, model selection does not mean that the operation should automatically be executed. The application must still evaluate the request.
10. Application Validation
Every tool request should be treated as untrusted input.
The application should validate the function name, required arguments, data types, allowed values, request size, and other relevant constraints.
Validation should happen before the tool is executed.
11. Authentication
Authentication identifies the user making the request.
A tool-enabled application should know which user or service account is requesting the operation before allowing access to protected functionality.
For example, an authenticated customer may use an order lookup tool for their own orders.
12. Authorization
Authorization determines what an authenticated user is allowed to access or modify.
This control must be enforced by the application.
If a model requests information about an account that the current user is not authorized to access, the application should reject the request even if the model produced a perfectly valid tool call.
13. Tool Permissions
Not every assistant should have access to every available tool.
An application can limit tools according to the user, application role, workflow, or risk level.
For example, a read-only assistant might be allowed to search information but not modify records.
14. Read Operations vs Write Operations
Tool operations can have different levels of risk.
A read operation such as searching public product information may have relatively low risk.
A write operation such as deleting a record, changing account information, or submitting a financial transaction can have much greater consequences.
Higher-risk operations should normally have stronger validation, authorization, confirmation, and monitoring.
15. Confirmation Before Important Actions
Some actions should require explicit confirmation from the user before execution.
For example, an assistant may prepare a payment or appointment cancellation but ask the user to confirm before the final action occurs.
The exact confirmation design depends on the risk and purpose of the application.
16. Tool Execution
After validation and authorization, the application executes the tool.
The tool may call internal application code, a database, an API, or another approved service.
The execution should remain within the permissions and limits defined by the application.
17. Tool Results
A tool returns information to the application.
The application can then provide the relevant result to the AI model so that the model can explain the result to the user.
The tool result should also be treated carefully. External systems can return unexpected, incomplete, stale, or malformed information.
18. Validating Tool Results
Validation is needed not only before tool execution but also after execution.
The application may check required fields, expected data types, status values, error indicators, and other business rules.
This prevents malformed or unexpected tool results from being passed blindly through the rest of the workflow.
19. Example: Order Support Assistant
Consider an online store assistant.
A customer asks, “Where is my order?”
The model can determine that an order lookup tool is relevant and request the order identifier.
The application verifies that the user is authenticated and authorized to access that order. It then retrieves the order status.
The application provides the approved result to the model, which can explain the current status in natural language.
The model does not receive unrestricted access to the store database.
20. Example: Scheduling Assistant
A scheduling assistant could use tools for checking availability and creating appointments.
The assistant may first use a read-only availability tool. If the user selects a time, the application can validate the selection and require confirmation before creating the appointment.
This design separates conversational understanding from the actual scheduling operation.
21. Tool Results and AI Reasoning
The AI model can use tool results as additional context for producing a response.
For example, after receiving an order status of “shipped,” the model can explain the status to the user.
The application should still determine which tool results are safe and relevant to provide to the model.
22. Preventing Unauthorized Actions
A tool-enabled assistant should never rely on the model alone to determine whether an action is permitted.
Application controls should independently enforce permissions.
This is especially important when tools can access private information, modify records, communicate externally, or perform financial or operational actions.
23. Prompt Injection and Tools
Tool access increases the potential impact of prompt injection.
A malicious or unexpected instruction could attempt to convince a model to request a dangerous tool operation.
Therefore, applications should use independent authorization, input validation, tool restrictions, confirmation mechanisms, and other controls appropriate to the risk.
24. Limiting Tool Scope
A tool should provide only the capability that the application actually needs.
A narrow tool such as get_order_status is easier to control than a generic tool that can execute arbitrary database commands.
Least privilege is an important principle for tool-enabled AI systems.
25. Tool Errors
Tools can fail.
A database may be unavailable, an external API may time out, a requested record may not exist, or the supplied arguments may be invalid.
The application should handle these errors explicitly and provide an appropriate result to the model or user.
26. Avoiding Arbitrary Code Execution
One of the most important security principles is to avoid giving a model unrestricted ability to execute arbitrary code or commands.
Instead, applications should expose narrowly defined functions with controlled inputs and clear permissions.
This makes the system easier to test, monitor, and secure.
27. Logging Tool Usage
Tool activity should be monitored in production systems where appropriate.
Useful information can include the user or service identity, tool requested, execution result, execution time, error status, and relevant audit information.
Logs should be designed carefully so that sensitive information is not unnecessarily exposed.
28. Tool Calls and Privacy
Before sending information to a tool, developers should determine whether the data is necessary.
Only the information required for the operation should be provided.
Tools connected to external services require additional consideration because information may leave the immediate application environment.
29. Tool Calls and Cost
Tool-enabled applications can create additional costs.
An assistant may make multiple AI requests and several external service calls during one conversation.
Developers should monitor tool frequency, API usage, execution time, and unnecessary repeated operations.
30. Designing Good Tools
Good AI tools are:
- Clearly named
- Narrow in purpose
- Easy to validate
- Explicit about required arguments
- Limited by authorization
- Predictable in their results
- Easy to monitor
- Designed with failure handling
Tool design is an application engineering task, not simply a prompt-writing task.
31. Common Beginner Mistakes
- Allowing the model to execute unrestricted commands
- Skipping authorization because the model selected the tool
- Failing to validate tool arguments
- Giving every assistant access to every tool
- Using broad tools when narrow tools are sufficient
- Ignoring confirmation for high-risk actions
- Trusting tool results without validation
- Failing to log important tool activity
- Sending unnecessary sensitive information to tools
- Ignoring tool failures and timeouts
32. A Safe Tool-Enabled Architecture
A useful mental model is:
User → AI Model → Tool Request → Application Validation → Authorization → Tool Execution → Tool Result → Validation → AI Model → User
The application remains the control point between the AI model and external capabilities.
33. Function Calling Is Not the Same as an AI Agent
Function calling is one mechanism that can be used by AI applications and agents.
A system that supports a few controlled function calls does not automatically become a fully autonomous agent.
Agents may involve planning, repeated tool use, state management, and more complex decision loops. Those concepts are covered later in this module.
34. Where This Module Goes Next
The next lesson introduces AI Agents Explained. It builds on tool use and explains how systems can combine models, tools, memory, planning, and application controls into more autonomous workflows.
Conclusion
Function calling provides a structured bridge between AI models and external software capabilities.
The model can request a tool, but the application should remain responsible for validation, authentication, authorization, execution, result handling, privacy, and security.
Well-designed tools are narrow, predictable, permission-controlled, and observable. This approach allows developers to build assistants that can perform useful operations without giving the AI model unrestricted control over the underlying systems.