Tool-Use Conceptual Model Design

The Anatomy of a Tool-Use Function

At its core, a "tool-use function" is a capability that you grant to an AI agent, allowing it to interact with the world beyond its internal knowledge. To make a function usable by a Large Language Model (LLM), we must describe it in a structured way.

This structure, or conceptual model, consists of four key parts.

As the resource outlines, a function definition includes a name, a description, and parameters. We will add return values to complete our conceptual model:

1. Name: A unique, machine-readable identifier (e.g., get_user_preferences).
2. Purpose (Description): A clear, natural language explanation of what the function does and, crucially, when the LLM should use it.
3. Parameters: The inputs the function requires to do its job, including their data types and whether they are required.
4. Return Values: The structured output the function sends back to the agent after execution.

This diagram shows how a chatbot agent might use several functions, each with its own purpose, parameters, and return values, to serve a user.

Designing the Function's "Contract"

Let's break down how to design each part of this contract. We'll use a practical example: designing a function to get the weather.

1. Name and Purpose (Description)

The function's name should be concise and programmatic. The description, however, is written for the LLM. It is the single most important piece of information the model uses to decide which tool to use and why. A vague description leads to errors.

The Google AI documentation provides excellent guidance on how to structure this using standard programming conventions like docstrings.

As you read, the key insight is that the function's description isn't just for human developers; it is a direct instruction to the AI.

2. Parameters (Inputs)

Parameters are the data fields the function needs to execute. For each parameter, you must define:

• Name: e.g., location.
• Type: e.g., string, integer, boolean.
• Description: A clear explanation for the LLM, e.g., "The city and state, such as 'San Francisco, CA'".
• Required/Optional: Is this parameter mandatory for the function to run?

This next video gives a concrete walkthrough of how these parameter definitions look in the JSON format that is actually sent to the OpenAI API.

A crucial design decision is whether to make a parameter required or optional. The "Function tools - Google" page you reviewed earlier has a great section on this. An optional parameter usually has a default value (e.g., a search radius defaulting to 10 miles).

3. Return Values (Outputs)

The return value is the data the function passes back to the agent. This isn't for the end-user directly; it's for the LLM to process and use in its final response. Therefore, the return value should be structured and descriptive.

For example, a weather function shouldn't just return "25". It should return a structured object like:

{
  "status": "success",
  "location": "Paris, FR",
  "temperature": 25,
  "unit": "celsius",
  "condition": "Sunny"
}

If something goes wrong, it could return:

{
  "status": "error",
  "error_message": "Location not found."
}

This structured response gives the agent everything it needs to formulate a helpful reply.

Your Turn: Design a Function Model

Now, let's apply these concepts. Your task is to design a conceptual model for a function that would be useful in a product you're familiar with from your UI/UX work—managing user settings.

Scenario: An AI assistant helps users manage their profile on an e-commerce app. You need to design the update_user_profile function.

Instructions: Based on the four components we've discussed, create a conceptual model for this function. Think about what information is absolutely necessary and what is optional.

Fill out the following structure:

• Name: update_user_profile
• Purpose (Description): (Write a clear description for the LLM. What does this do and when should it be used?)
• Parameters:
  • Parameter 1:
    • Name: user_id
    • Type: string
    • Description: The unique identifier for the user whose profile is being updated.
    • Required: Yes
  • Parameter 2:
    • Name: (e.g., email)
    • Type: (e.g., string)
    • Description: (Explain this parameter)
    • Required: (Yes or No?)
  • Add at least two more optional parameters relevant to a user profile (e.g., preferred_theme, newsletter_subscription).
• Return Values:
  • Describe the structure of a successful return object.
  • Describe the structure of an error return object.

Take about 10-15 minutes to complete this. There's no single right answer; this exercise is about applying the design principles of clarity, structure, and intent.

How the Agent Uses Your Model

You've designed the "contract." The final step is to see how the agent uses it. The LLM's magic is its ability to translate unstructured natural language into the structured JSON that matches your function's model.

Conclusion

Today, you've moved from understanding what a function is to designing one yourself. This is a fundamental skill for any system architect working with AI. By defining a clear and robust contract for each tool, you enable agents to perform complex, real-world tasks reliably.

Key Takeaways:

• A conceptual model for a tool-use function has four parts: Name, Purpose (Description), Parameters, and Return Values.
• The Description is a critical instruction for the LLM, guiding its decision-making.
• Parameters form a contract defining the required and optional inputs for the function.
• Return Values should be structured (e.g., JSON objects) and informative, providing the agent with clear feedback on the outcome of the tool's execution.

Next Lesson Preview

Now that you can design an individual tool, we need to think about how an agent manages its toolkit and handles situations where the tools aren't enough. In the next lesson, we will address the learning outcome: Diagram a human-agent-human escalation path with defined triggers for handoff. This will explore the critical design patterns for collaboration between AI agents and human experts.