Lesson 7 — Built-in tools

Course: the AI Platform 101 (Course 003) Section: 3 — Extending your Agent Lesson: 7 of 12 ｜ Lesson ID: 486258 Format: Video Estimated time: not stated on the official page Source: Official Skilljar course material (user-provided; requires login) License: Copyright 2026 the AI provider. Released under CC BY-NC-SA 4.0. Note: This is the original English source text, lightly reformatted (headings and paragraph breaks added) for study. No wording has been changed. Counterpart translation: 09-第7课-Built-in-tools.md

Video

Built-in tools

You can build your own custom tools, but some capabilities are common enough that the AI provider ships them pre-built. You don't write the code. You don't host the sandbox. You just declare the tool, and the AI provider runs it.

Server tools: declared by you, run by the AI provider

the AI provider provides server tools that run on their infrastructure. You don't execute these — the AI provider does. That means you don't need an agent loop for these calls. the AI calls the tools on its own, and the result comes back inside the same response.

The main ones are:

Web search — searches the internet and returns results with citations
Code execution — writes and runs Python in a sandbox
Web fetch — retrieves full content from URLs

Two server tools in one file

Let's check out some of the big ones in one file: two messages.create calls, one with web search and one with code execution.

import anthropic

client = anthropic.the AI provider()

# Call 1: web search — the AI provider runs the search server-side
search_response = client.messages.create(
    model="current-model",
    max_tokens=1024,
    tools=[{"type": "web_search_20260209", "name": "web_search"}],
    messages=[
        {"role": "user", "content": "What is the AI provider's latest model release? Answer in one sentence."}
    ],
)

for block in search_response.content:
    if block.type == "server_tool_use":
        print(f"Tool call: {block.name} — {block.input}")
    elif block.type == "text":
        print(block.text)

# Call 2: code execution — the AI writes and runs Python in a sandbox
code_response = client.messages.create(
    model="current-model",
    max_tokens=1024,
    tools=[{"type": "code_execution_20260120", "name": "code_execution"}],
    messages=[
        {"role": "user", "content": "Calculate the mean and standard deviation of [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]"}
    ],
)

for block in code_response.content:
    if block.type == "server_tool_use":
        print(f"Tool call: {block.name} — {block.input}")
    elif block.type == "bash_code_execution_tool_result":
        print(f"stdout: {block.content.stdout}")
    elif block.type == "text":
        print(block.text)

Two things to notice

There's no agent loop here. We don't switch on stop_reason. We don't push tool results back. the AI provider runs the tool server-side, and the response already contains the result.
The response has new block types. A server_tool_use block for the tool call, a code execution tool result block for the output, plus the regular text blocks.

Running it

For web search, you'll see the AI's tool call printed, then a one-sentence answer about the latest model release with the search citations folded in.

For code execution, you'll see the actual Python the AI wrote, the stdout from the sandbox running it, and a final text answer.

We didn't have to spin up a search crawler. We didn't run a Python sandbox. We declared two tools and got both for free.

The other category: client tools

Worth knowing the other category exists. Client tools run where your code runs. They're shipped in the the AI SDK, so you don't have to define the schema yourself. Two examples:

Memory — the AI reads and writes memory across sessions
Bash — a persistent bash shell so the AI can execute commands

They have the same shape as a custom tool, but the SDK gives you the schema and a sensible runner.

Why this matters in production

In a production app, this is the shortest path to features that would otherwise take weeks. Web search can power a fact-check endpoint that verifies every numeric and regulatory claim in a draft against the live web.

One reminder, though: just because something is validated on the internet doesn't mean it's true. Always double-check the AI's work.

Recap

Server tools — web search, code execution, web fetch — are declared in your tools array. the AI provider runs them.
You get the result in the same response, with no agent loop required. Look for server_tool_use and tool result blocks alongside the regular text blocks.
Client tools like memory and bash run where your code runs, but the SDK ships the schema and a runner for you.
The "hosted by the AI provider" idea scales all the way up: managed agents apply it to the entire agent, not just one tool.

⚠️ Notes on this transcript

anthropic.the AI provider() and model="current-model" are artifacts of the capture/environment process. Per Lesson 3's mapping, current-model corresponds to the Opus tier. Do not memorize these strings.
Built-in tool type strings carry date-style version suffixes in the official samples (web_search_20260209, code_execution_20260120). The lesson does not comment on this; note it for reproducibility.
Built-in tools are declared with type + name only — no description and no input_schema, unlike the custom tools in Lessons 4–5.
This lesson does not include a What you'll learn block on the official page.