---
theme: seriph
title: "Lesson 14 — What Makes a Tool Easy for a Model to Use?"
info: "English video course for AI Agents in Depth"
author: Bojie Li
transition: slide-left
mdc: true
lineNumbers: false
monaco: false
aspectRatio: 16/9
canvasWidth: 980
layout: cover
class: cover
---
Build · Chapter 4 · Tools
# What Makes a Tool Easy for a Model to Use?
Capability boundaries, granularity, descriptions, and MCP
Lesson 14 of 42 · 18 minutes · Tool Classification; Universal Principles; MCP; Perception Tools
---
Build · Chapter 4 · Tools
# Problems this chapter will solve
Lesson 14
What Makes a Tool Easy for a Model to Use?
Lesson 15
How Do You Let an Agent Act Without Letting It Cause Damage?
Lesson 16
When Should an Agent Ask for Help or Delegate?
Lesson 17
How Can a Synchronous Model Live in an Asynchronous World?
---
# Why this problem matters
Granularity
One broad tool or several composable operations?
Description
The model selects tools from names, schemas, and examples.
Fidelity
Arguments must preserve the user's intended operation.
---
# Three ideas to keep in view
Perception
Read the world without changing it
Execution
Change state and create consequences
Collaboration
Reach another Agent or human
---
# The book's visual model
MCP protocol interaction sequence
---
# Dedicated tool vs. Skill + executor
Dedicated tool
- Clear intent
- Narrow schema
- Many definitions at scale
Skill + executor
- General action surface
- Instructions on demand
- Needs stronger sandboxing
Capability expression is a design choice.
---
# A schema is an Agent-facing API
~~~json
{
"name": "weather",
"description": "Current observed weather for one place",
"parameters": {"city": {"type": "string"}},
"required": ["city"]
}
~~~
---
# Test the claim
4-13 min
Discover and call perception tools
Observe: Tool discovery, typed arguments, truncation, and evidence returned
Demo budget: 3 minutes · one contiguous terminal block
---
class: course-terminal
---
Live demo
# Switching to the terminal
~~~bash
$ uv run python chapter4/perception-tools/cli.py demo --offline
~~~
Run the command(s), narrate decisions, and point to the observation—not just the output.
---
# What the evidence supports
Finding 1
Read-only tools are easier to cache, parallelize, and trust.
Finding 2
Descriptions should state scope, provenance, and failure behavior.
Finding 3
MCP standardizes interoperability but not tool quality.
---
layout: center
---
Where the claim stops
# Boundary condition
Every third-party server creates a new trust boundary for descriptions, credentials, and returned content.
---
layout: center
---
Engineering takeaway
# Design rule
Design tools for faithful action and inspectable evidence before optimizing convenience.
---
# Continue the experiment
---
layout: center
class: text-center
---
Pause and apply
# Your turn
Which parameter in your tool can silently change the meaning of the user's request?
---
layout: center
class: text-center
---
Next · Lesson 15
Add execution power without letting a model become the security boundary.
→