Ask It Simply
Build With AI · Advanced · Lesson A4

Give your agent tools (function calling and MCP)

about 9 minutes. Level: Beginner. Nothing to install: copy-paste blocks into Grok.

By Dontè

Watch the video

Lesson video, about 4 min 34 s. Captions are off by default. Press CC to turn them on. It starts muted. Press Sound to hear the lesson from the start. Press and hold the playing video (or hold the period key) to watch at 2x speed.
Show transcript

Welcome to Lesson A4. In A1, you learned that an agent is AI, plus tools, plus a goal, plus a loop. Today we zoom in on the tools. You'll learn how an AI uses a tool, what MCP means, and the one safety rule every builder needs.

Here's the big idea. An AI can't press buttons by itself. Instead, you hand it a menu of tools. Each item on the menu has three things. The tool's name. What it does. And what inputs it needs.

When the AI wants to use a tool, it picks one from the menu and fills in the inputs. Your program runs the tool and hands the result back, like this made-up example. This is called function calling. A function is just a small piece of code that does one job.

xAI documents this for Grok in its function calling guide. And Anthropic describes the same idea. Quote: "Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides." End quote. Different companies, same idea.

Now, MCP. For a long time, every AI app connected to tools its own way. Picture a drawer full of different chargers. MCP's own site says, quote: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems." End quote.

And here's their best line. Quote: "Think of MCP like a USB-C port for AI applications." End quote. One standard plug, instead of a different one for every tool.

Next, two kinds of tools. A read-only tool only looks. Checking the weather. Reading a calendar. A write tool changes something. Sending an email. Moving money. Deleting a file.

Our tip: start with read-only tools. Add write tools only with a human okay step.

Let's try it. On the lesson page there's a menu card for a weather tool. Copy the whole block and paste it into Grok. The tool's name is get underscore weather. It looks up today's weather for a city, and it's read-only. It needs a city, like Chicago, and optionally the units, Fahrenheit or Celsius.

We ask Grok to turn this into a JSON tool definition. JSON is just a tidy way to write information so computers can read it. Then we ask Grok to explain each part, and to tell us if it's read-only or a write tool.

Here's Grok's answer. Let's check it. There's the name. There's the description. And there's the list of parameters, which is just a fancy word for inputs. Look for city marked as required. And look for Grok saying the tool is read-only, so it can't change anything. In our run, it did both.

Bonus. Ask Grok to make a menu card for a tool that sends a text message, and ask what safety rule it should have. Look for a rule like, ask the human first. That's the difference between a read-only tool and a write tool.

Now the safety rule every builder needs. OWASP, a respected security group, lists something called Excessive Agency as a top risk for AI apps. They say, quote: "The root cause of Excessive Agency is typically one or more of: excessive functionality; excessive permissions; excessive autonomy." End quote.

In plain words, trouble starts when a tool can do too much, can reach too much, or can act without asking. So give each tool the least power it needs.

When you're ready to build real agents in code, the lesson page lists some next steps. The OpenAI Agents SDK, LangGraph, CrewAI and Google's Agent Development Kit. They're optional, and they'll be there when you want them.

Safety check. Our tip: only connect tools you trust, and give each tool the least access it needs.

Quick check. What goes on a tool menu card? A name, what it does, and its inputs. What is MCP compared to? A USB-C port for AI applications. Which tool should you start with? Read-only. Congratulations, you've finished Level A. Next up, Lesson B1, where you'll learn how sneaky hidden instructions can trick an agent, and how to stop them.

What you'll learn

Step 1: Tools are a menu

In Lesson A1, an agent was AI plus tools plus a goal plus a loop. Now let's look at the tools.

The AI can't press buttons by itself. Instead, you give it a menu of tools. Each item on the menu says: - the tool's name - what it does - what inputs it needs

When the AI wants a tool, it picks one from the menu and fills in the inputs. Your program runs the tool and hands the result back. This is called function calling (a function is a small piece of code that does one job). xAI documents this for Grok in its function calling guide. Anthropic describes the same idea: "Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides." (Anthropic tool use)

Step 2: MCP, the USB-C port for AI

Every AI app used to connect to tools its own way. MCP fixes that. MCP's own site says: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems." And: "Think of MCP like a USB-C port for AI applications." (Model Context Protocol)

So instead of a different plug for every tool, there's one standard plug.

Step 3: Read-only vs write tools

Our tip: start with read-only tools. Add write tools only with a human "OK" step.

Step 4: Try it (copy and paste, no setup)

Here's a tool "menu card" for a weather tool. Copy it into Grok along with the prompt.

Here is a menu card for a tool. Turn it into a JSON tool definition
that an AI could use for function calling. Then explain each part in plain words.

Tool menu card
- Name: get_weather
- What it does: looks up today's weather for a city. Read-only.
- Inputs:
  - city (text, required), for example "Chicago"
  - units (text, optional): "fahrenheit" or "celsius"

Finally, tell me: is this tool read-only or a write tool, and why does that matter?

What to look for: - A name, a description and a list of parameters (the inputs) - city marked as required - Grok saying it's read-only, so it can't change anything

Bonus: Ask Grok, "Now make a menu card for a tool that sends a text message. What safety rule should it have?" Compare the two.

Grok's real answer (our test run)

We ran this exact prompt through Grok (model grok-4.7) on Oct 30, 2026. Grok's answers change from run to run, so yours will differ. Quoted as Grok returned it, except where we mark [trimmed] and where we swapped dashes for commas to match our style.

{
  "name": "get_weather",
  "description": "Looks up today's weather for a city. Read-only.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "City to look up, for example \"Chicago\"."
      },
      "units": {
        "type": "string",
        "enum": ["fahrenheit", "celsius"],
        "description": "Temperature units. Optional."
      }
    },
    "required": ["city"]
  }
}

What each part means

Read-only or write?

This is a read-only tool. It only looks up weather and does not create, change, or delete anything. That matters because read-only tools are safer to call automatically: they don’t alter user data or external systems, so a wrong call is much less harmful than a write tool (which might send email, charge a card, or overwrite records).

Grok's real bonus answer (our test run)

We ran the bonus question, right after the first answer, through Grok (model grok-4.7) on Oct 30, 2026. Grok's answers change from run to run, so yours will differ. Quoted as Grok returned it, except where we mark [trimmed] and where we swapped dashes for commas to match our style.

Tool menu card
- Name: send_text_message
- What it does: sends a text message to a phone number. Write action; not read-only.
- Inputs:
  - to (text, required): phone number in E.164 form, for example "+13125551212"
  - body (text, required): message text, max 1600 characters
- Safety rule: do not send until the user has explicitly confirmed the recipient and the exact message text in this conversation.

Safety rule: require explicit confirmation of both the recipient and the exact wording before the tool is called.

That matters because this is a write tool. Unlike get_weather, it changes the outside world: it delivers a message that cannot be unsent, may cost money, and could reach the wrong person or say the wrong thing. A confirmation step keeps the model from sending on a guess, a partial instruction, or a misunderstood number.

Notice the safety rule: confirm the person and the exact words before sending. That's the "ask the human first" rule for a write tool.

Step 5: Give tools the least power they need

OWASP, a respected security group, lists "Excessive Agency" as a top risk for AI apps. It says: "The root cause of Excessive Agency is typically one or more of: excessive functionality; excessive permissions; excessive autonomy." (OWASP LLM06:2025 Excessive Agency)

In plain words, trouble starts when a tool can do too much, can reach too much, or can act without asking.

Where to go next (optional)

When you're ready to build real agents in code, these are good next steps: the OpenAI Agents SDK, LangGraph, CrewAI and Google's Agent Development Kit.

Check yourself

  1. What three things go on a tool menu card? (Answer: name, what it does, inputs)
  2. What is MCP compared to? (Answer: a USB-C port for AI applications)
  3. Which is safer to start with, a read-only tool or a write tool? (Answer: read-only)

Caution box OWASP calls this risk "Excessive Agency." (OWASP) Our tip: only connect tools you trust, and give each tool the least access it needs.

Builds on

Sources

Creator credits

Keep going

PreviousA3 →NextB1 →TrackBack to Build With AI →