LLM Function Calling: The Tool Definition Contract
The Challenge of Tool Discovery
LLMs need explicit, structured descriptions (tool definition contracts) of external functions to call them reliably.
π― System Scenario & Requirements
System Goal
LLMs need explicit, structured descriptions (tool definition contracts) of external functions to call them reliably.
Actors & Components
- Request Gateway
- Policy & Router
- Target Executors
- Request Entrypoint
- Policy Router
- Target Handler
Functional Requirements
- TLDR: LLMs need explicit, structured descriptions (tool definition contracts) of external functions to call them reliably.
- Without this contract, they'll hallucinate or misuse tools, making your AI agents unpredictable.
- π€ As AI systems evolve from simple text generation to intelligent agents, they need to interact with the real world by calling external tools or APIs.
Constraints & Assumptions
- Constraints are derived from the rebuilt scenario stages.
β‘ Execution Stages & Decision Trace
Stage 1 β Crafting the Function Contract
The solution is a "tool definition contract," often expressed as a JSON schema, that you provide to the LLM alongside the user's prompt.
This contract acts as a precise instruction manual for each available function.
Deep Dive
Scenario context
LLMs need explicit, structured descriptions (tool definition contracts) of external functions to call them reliably. Without this contract, they'll hallucinate or misuse tools, making your AI agents unpredictable. π€ As AI systems evolve from simple text generation to intelligent agents, they need to interact with the real world by calling external tools or APIs. The problem arises when an LLM is given a user requesβ¦
This walkthrough focuses on The Challenge of Tool Discovery.
Before making a design choice, clarify:
- As AI systems evolve from simple text generation to intelligent agents, they need to interact with the real world by calling external tools or APIs.
- The problem arises when an LLM is given a user request like "What's the weather in London?" but has no structured way to understand which tool can provide weather information, what its name is, or what parameters it expβ¦
- Without a clear contract, the LLM might guess function names, invent parameters, or simply fail to identify the correct tool, leading to unpredictable and unreliable agent behavior.
Concepts in play: llm-agents-and-langgraph, api-gateway, event-driven-architecture, consistency-replication
Stage 1 β Crafting the Function Contract
- The solution is a "tool definition contract," often expressed as a JSON schema, that you provide to the LLM alongside the user's prompt.
- This contract acts as a precise instruction manual for each available function.
- It specifies the function's name, a human-readable description of its purpose, and a detailed schema for its input parameters.
- By parsing this contract, the LLM can accurately determine if a user's intent matches an available tool, extract the necessary arguments from the prompt, and generate a correctly formatted function call.
Observable outcome: By parsing this contract, the LLM can accurately determine if a user's intent matches an available tool, extract the necessary arguments from the prompt, and generate a correctly formatted function call.
Stage 2 β How LLMs Use the Contract
- When an LLM receives a prompt and a set of tool definitions, it first analyzes the user's intent.
- If it identifies an intent that can be fulfilled by one of the defined tools, it then consults the tool's parameter schema.
- It extracts relevant information from the user's prompt to populate these parameters, ensuring the generated function call adheres to the tool's API specifications.
- The LLM then outputs a structured JSON object representing the function call, which your application intercepts, executes, and potentially feeds the result back to the LLM for further processing.
[
{
"type": "function",
"function": {
"name": "get_current_weather",
"description": "Get the current weather in a given location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city and state, e.g. San Francisco, CA"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "The unit of temperature to return"
}
},
"required": ["location"]
}
}
}
]
Observable outcome: The LLM then outputs a structured JSON object representing the function call, which your application intercepts, executes, and potentially feeds the result back to the LLM for further processing.
End-to-end outcome
As AI systems evolve from simple text generation to intelligent agents, they need to interact with the real world by calling external tools or APIs.
Alternatives considered
The source focuses on one primary design. A second architecture is not compared, so no alternative is invented here.
Failure and degraded modes
The source does not isolate a separate failure mode. Limits that matter for the scenario are called out in the stage decisions above.
Key learnings
- The solution is a "tool definition contract," often expressed as a JSON schema, that you provide to the LLM alongside the user's prompt.
- When an LLM receives a prompt and a set of tool definitions, it first analyzes the user's intent.
