Function Calling for Beginners: The Playbook on Letting AI Use Your Tools

Meera is a developer in Pune. Her friend runs a small bakery that delivers cakes across the city, and Meera built the bakery a chat assistant for its website. It is polite and quick. Then the first real customer types: “Where is my order BK-1042?”

The assistant replies with a friendly guess. It has no idea where the cake is. A language model cannot open the bakery’s order database on its own.

This chapter is function calling for beginners. Function calling (also called tool calling or tool use) is how you let an AI ask your code to do real work, like looking up an order, and then answer with the real result. By the end, Meera’s assistant will know exactly where BK-1042 is.

Last verified: 11 November 2026. AI tools change fast; check the linked sources for anything newer.

Who this is for: anyone looking for function calling for beginners: people who have called an AI model once or twice and want it to use real data or take actions. You need no framework. Time needed: about 30-45 minutes to read and try the plays.

Function calling for beginners: what it is, in simple words

Think of a waiter in a restaurant. The waiter talks to you, understands what you want and writes an order slip. But the waiter never cooks. The slip goes to the kitchen, the kitchen cooks, and the waiter brings the plate back to you.

In function calling, the model is the waiter and your code is the kitchen. You give the model a menu: a short list of tools (functions) your code can run. When a question needs one, the model writes an order slip: the tool’s name and the inputs, as structured data called JSON. Your code runs the tool and sends the result back. The model then writes the final answer.

The precise version in one sentence: the model never runs anything itself; it only returns a structured request, and your application decides whether and how to run it.

Function calling vs tool calling: is there a difference?

Mostly no. They are different names for the same idea. OpenAI’s docs say “function calling”, Anthropic’s say “tool use”, and many people now say “tool calling” as the wider term, because a tool is not always a plain function. In this playbook the three names mean the same thing.

The playbook at a glance

Here is the whole function calling for beginners playbook in five plays. Each one takes a few minutes.

1. Play 1: Pick one job the AI cannot do alone.
2. Play 2: Describe the tool so the model knows when and how to use it.
3. Play 3: Run the loop: ask, call, run, return, answer.
4. Play 4: Check every call before your code runs it.
5. Play 5: Handle errors and test with real questions.

Play 1: Pick one job the AI cannot do alone

Goal: find the one missing ability that matters most, and only that one.

1. Collect 10-20 real questions from users (or write the ones you expect).
2. Mark the ones the model gets wrong because it lacks fresh data (order status, stock, weather) or the power to act (book, cancel, send).
3. Pick the most common one. Find the code you already have that does it, such as a database query or an internal API.
4. Give it a clear verb-first name, like get_order_status.

Meera’s list was easy to read. Seven of her twelve test questions were some version of “where is my order?” Her backend already had a function that returns an order’s status, so that became her first tool.

You are done when: you can name one tool, say what it takes in and what it gives back, in one sentence.

Play 2: Describe the tool so the model knows when to use it

Goal: write the “menu entry” for your tool. The model only sees the description, never your code, so the words matter a lot.

1. Write a name and a description that says what the tool does, when to use it and when not to.
2. Describe each input with a JSON schema: a small format that lists the inputs, their types and which ones are required.
3. Use a fixed list of allowed values (an “enum”) when an input has only a few valid options.
4. Turn on strict mode if your provider has it, so the model’s inputs follow your schema more reliably.
5. Keep the menu short: a few clear tools beat many vague ones.

Here is Meera’s tool description, in the style of the OpenAI Responses API. It is an illustration; other providers use the same idea with slightly different field names.

{
  "type": "function",
  "name": "get_order_status",
  "description": "Look up the delivery status of one cake order. Use when a customer asks where their order is.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "Order number, like BK-1042" }
    },
    "required": ["order_id"],
    "additionalProperties": false
  },
  "strict": true
}

In plain steps: the tool is called get_order_status; the description tells the model when to pick it; it needs exactly one input, order_id, which is text; nothing extra is allowed; and strict mode asks the model to stick to that shape.

You are done when: a friend who has never seen your code could read the description and know when to use the tool.

Play 3: Run the function calling loop

Goal: connect the model and your code so the order slip reaches the kitchen and the plate comes back.

1. Send the user’s question to the model together with the list of tools.
2. Read the reply. If it is a tool call, it contains the tool name and the inputs as JSON.
3. Run the matching function in your code with those inputs.
4. Send a second request that includes the earlier messages, the tool call and the tool’s result.
5. The model now writes the final answer, or asks for another tool. Repeat until it answers, with a limit on how many rounds you allow.

Meera’s first test worked like this: the customer asked about BK-1042, the model returned get_order_status with order_id: "BK-1042", her code found “out for delivery, about 25 minutes” (illustrative), and the model replied: “Your cake is out for delivery and should arrive in about 25 minutes.”

The model may ask for several tools in one turn (called parallel calls), so your code should handle a list. And most providers let you control choice: let the model decide (the default), force it to use a tool, or turn tools off.

This loop is also the heart of every AI agent. If you want to see how it grows into a full agent, read the AI agents playbook.

You are done when: one real question goes in, a tool runs, and a correct answer comes out that uses the tool’s result.

Play 4: Check every call before your code runs it

Goal: remember that the model writes the slip, but you own the kitchen. Never run a tool call blindly.

1. Validate the inputs. Is the order ID in the right format? Is the number in a sensible range?
2. Do not ask the model for things your code already knows. Take the customer’s ID from their login session, not from the model’s arguments. Then the model cannot look up someone else’s order.
3. Start read-only. Looking things up is low risk. Actions that change things (refunds, cancellations, emails) need extra checks.
4. Ask a human before risky actions. Show the user what will happen and wait for a yes.

Meera’s code checks that the order belongs to the logged-in customer before returning anything. When she later adds a cancel_order tool, the bot will ask “Cancel order BK-1042? Yes or no” first. The AI guardrails playbook and the prompt injection playbook go deeper on this.

You are done when: every tool call passes through your own checks, and no risky action runs without approval.

Play 5: Handle errors and test with real questions

Goal: behave well when things go wrong, and prove it works.

1. When a tool fails, send back a clear, short error as the result, such as “Order not found”. The model can then explain it kindly or ask the user to check the number.
2. Add a timeout and a limit on loop rounds, so one broken tool cannot cause endless retries.
3. Turn your Play 1 questions into a small test set. Include tricky ones: a wrong order ID, a question that needs no tool, and a question in a different language.
4. Rerun the tests every time you change a description, a tool or the model.

Meera’s test set caught one surprise: for “What cakes do you sell?” the model tried to call get_order_status. She added “Do not use for menu or price questions” to the description, and the problem went away. The AI evals playbook shows how to build such tests.

You are done when: your test set passes, including the tricky questions, and errors produce helpful replies instead of guesses.

Do you need function calling?

New to these terms? See What is RAG?, the structured outputs guide and how to build an MCP server.

Mistakes to avoid

Every function calling for beginners guide should warn you about these slips. Here is the fix for each.

• Vague descriptions. “Gets data” tells the model nothing. Fix: say what, when and when not to use it.
• Too many tools at once. A long menu confuses the model. Fix: start with one to three tools and add more only when tests show a need.
• Trusting the arguments. The model can produce wrong or harmful inputs. Fix: validate everything and take identity from the session.
• No loop limit. A failing tool can make the model try again and again. Fix: cap the rounds and return clear errors.

How to know it is working

• The model calls the tool for questions that need it, and does not call it for questions that do not.
• The inputs it sends are valid most of the time, and your checks catch the rest.
• Final answers match the tool’s results, with no invented details.

Your function calling for beginners checklist

• ☐ One clear job chosen, with a verb-first tool name
• ☐ Description says what, when and when not to use the tool
• ☐ JSON schema for inputs, with strict mode on if available
• ☐ Loop sends the tool result back and has a round limit
• ☐ Inputs validated; identity taken from the session
• ☐ Risky actions need human approval
• ☐ Errors returned as clear results; calls logged
• ☐ Test set of real and tricky questions passes

Frequently asked questions

Does the AI run my code by itself?

No. The model only returns the name of a tool and the inputs it wants. Your application runs the code, which is why you stay in control of what actually happens.

Is function calling the same as an AI agent?

Not quite. Function calling is one building block: one question, one or a few tool calls, one answer. An agent repeats that loop many times, planning steps toward a bigger goal.

How many tools can I give the model?

Fewer is better. OpenAI’s guide suggests keeping fewer than about 20 tools available at the start of a turn, and using tool search for large tool sets. Start with one to three.

What is the difference between function calling and MCP?

Function calling is how a model asks for a tool. MCP (Model Context Protocol) is a standard way to package tools as a server so many different AI apps can use them. MCP tools are still used through tool calls.

Meera’s bakery bot, one week later

A week later, Meera’s assistant answers “where is my order?” with the real status, refuses to show other people’s orders and asks customers to check the number when it finds nothing. That is function calling for beginners in one picture: the model talks, your code works.

Your next action: pick the one question your users ask most that your AI cannot answer, and turn it into your first tool using Play 1 and Play 2 today. If you use Java, the Spring AI function calling guide shows the same idea in code. Next on the CodeSpy roadmap: how AI models read images, audio and documents.

Sources: OpenAI function calling guide (flow, strict mode, tool choice, parallel calls, tool count advice); Anthropic tool use overview (the same idea under the name tool use); Apideck: an introduction to function calling and tool use.