Skip to main content
Articles/ai-agents/llm-function-calling-the-tool-definition-contract
Scenario Article

LLM Function Calling: The Tool Definition Contract

The Challenge of Tool Discovery

Abstract Algorithmsβ€’Jul 24, 2026
XLinkedInReddit
πŸ’‘ Executive Summary

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

1

Stage 1 β€” Crafting the Function Contract

Action / Decision:

The solution is a "tool definition contract," often expressed as a JSON schema, that you provide to the LLM alongside the user's prompt.

Component Behavior:

This contract acts as a precise instruction manual for each available function.

Observable Output: It specifies the function's name, a human-readable description of its purpose, and a detailed schema for its input parameters.
Read Full Stage in Deep Dive ↓
πŸ“–

Deep Dive

Detailed Architectural Analysis

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.

Share this case study

Discuss architecture trade-offs and lessons with your team.

Share:XLinkedInReddit