Tool calling and function calling
Tool calling is the mechanism through which an AI application requests an external operation, such as looking up a record or creating a calendar event. In a typical language-model workflow, the model proposes a named operation and arguments. Application code decides whether and how to execute it, then makes the result available to the workflow.
“Function calling” often describes this structured interaction in model APIs. The terms overlap, but providers use them differently. Neither term means that generated text automatically executes a function.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Follow one call from proposal to result
Suppose a scheduling assistant is asked to find a meeting time. Its application exposes a calendar-search tool with start and end times as arguments.
- The application supplies the tool definition to the model.
- The model proposes a calendar-search call.
- The application validates and authorizes the request.
- The calendar service executes the operation.
- The result returns to the application and can inform the next model response.
The loop can repeat or stop at any stage. Invalid dates need correction, a denied calendar request needs a permission check, and a timeout needs recovery handling.
The Model Context Protocol (MCP) tools specification defines a protocol mechanism for discovering and invoking tools. MCP is one way for an application to discover and call a service's tools. Tool calling in a model API does not necessarily use MCP.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Discovery, schemas, and results serve different purposes
Tool discovery tells the application which operations a server exposes. A schema describes the expected shape of a request. A result reports what the operation returned. They answer different questions about the call.
For calendar search, a schema may require two timestamp strings. The application still needs to check the date range, the caller's access to the requested calendars, and whether the search returned a complete result.
Removing a tool from the discovery list doesn't prove that a direct call will be refused. An application may still know the tool's name from an earlier connection. Check permissions when the tool is called, even if it no longer appears in the list.
Keep the tool result separate from the model's explanation. “I booked the meeting” is generated language. The application should rely on the service's confirmed event identifier and outcome before presenting a booking as complete.
Explore Dome: Authorization · Docs: Authorization model.
Describe what a tool can do
For the calendar-search tool, record its permitted use and how the application will recognize completion:
| Question | Calendar example |
|---|---|
| What can it read or change? | Read availability, but not create events |
| Which inputs require validation? | Date range, calendar identity, and result limit |
| What confirms the search completed? | Service response with results limited to the requested scope |
| What happens if the result is unclear? | Return an incomplete result or error, not a fabricated success |
Check failure handling especially carefully when a tool changes data. If a creation request times out after the service accepted it, repeating it may create another event. The application needs a way to check the backend and avoid creating a duplicate.
Dome's Tool Gateway governs configured tool calls and their content path. Use agent authorization for trusted decision inputs and filtering versus validation for the difference between checking a request's shape and handling its content.
Explore Dome: Tool Gateway · Docs: Guards.