Day 2 · Lesson 1 — Agent Tools & MCP

Tools: The Eyes and Hands

Without them, even the best model is just a pattern predictor.

Day 1 built the system around the model. Day 2 is about how the agent actually touches the world. It starts with the simplest, most consequential component: the tool. A model alone can reason; it cannot know anything new or do anything at all. Tools are what change that.

Recall first (spacing — from Day 1)

From Day 1, Lesson 2: an agent's tools are one part of its —

Economic dial
Harness (the hands)
Context budget

The harness. Tools were component 2 of six, and Day 2 zooms all the way into that component: what a good tool is, and how it goes wrong.

The one idea: know, or do

On its own a foundation model is a pattern-prediction engine: it can't fetch new data, reach an external system, or act on its environment. Tools are its eyes and hands.¹ Every tool does exactly one of two things:

TO KNOW   retrieve data the model lacks   (weather, a DB row, a document)
TO DO     take an action in the world      (send email, run code, create a ticket)

And a tool is fundamentally a contract between the model and the world: a clear name, typed parameters, and a natural-language description of what it's for. That description is instructions the model reads to decide when and how to call it, not documentation for you.¹

name:        get_stock_price
description: "Get the price for a ticker. If 'date' is given, return that
              day's close; otherwise the latest price."
input:       { symbol* : string, date : "YYYY-MM-DD" }
output:      { price : number, date : string }

Change the description and you change the model's behaviour without touching a line of code. The contract is the interface.

Three kinds of tool

Function tools — you define a function; the model calls it as needed. The definition (name, params, description) is passed in the request context. In ADK it's read straight from the Python docstring.
Built-in tools — provided implicitly by the model service, definition hidden from you (e.g. Gemini's Google Search grounding, code execution, URL context).
Agent tools — an agent invoked as a tool. The primary agent keeps control of the conversation and processes the sub-agent's output; A2A even exposes remote agents as tools. (This is orchestration, Day 1 Lesson 5, wearing a tool's clothes.)

There's also a useful way to classify any tool by what it enables, a taxonomy worth memorising because risk tracks it:¹

Category	What it does	Risk
Information Retrieval	Fetch data: search, DB, documents	Lower (reads)
Action / Execution	Send email, run code, control devices	Higher (writes/acts)
System / API Integration	Connect to enterprise systems, third parties	Higher (reach)
Human-in-the-Loop	Ask for clarification or approval	A control, not a risk

Linkage back to Day 1

Tools are the harness's hands (L2, component 2). But notice a second thread: every tool's name, description, and schema live in the context window. They are context (L4), and tokens you pay for on every call. Hold that; it becomes the "context bloat" problem when MCP lets you connect dozens of servers (D2·4).

The governance layer, on tools

Governance overlay · Day 2 Lesson 1

A tool is where an agent acts — so every tool is a governance surface

The taxonomy is a risk map. Action/Execution and System/API tools are the "sensitive sinks" that VERDICT's V Validation must gate and E Evidence must log; Human-in-the-Loop tools are the built-in V approval control. Even tool naming is governance: the paper prefers create_critical_bug_in_jira over update_jira precisely because "if tool calls are logged, clear names make audit logs informative."¹ Audit-legible names are an E Evidence decision made at design time.

Ladder read: knowing which tools each agent holds, and that they're all approved, is the L1→L2 step (an inventory). Enforcing an approved-tool catalogue with per-agent identity is L3 Controlled. The whole rest of Day 2 is about what goes wrong when tools arrive ungoverned.

Through your three lenses

Individual (IC)

Name every tool for the action it performs, human-readably, and classify it by the taxonomy before you ship it, so you know at a glance whether it merely reads or actually acts.

Team

Keep a shared, reviewed tool catalogue with a naming convention everyone follows. A tool is an interface many agents call, so treat its contract like any versioned API.

Organisation

Run an Agent Registry: a single catalogue of approved tools + per-agent identity, so no agent can reach a tool nobody vetted. (Your "no unregistered agents" rule, at the tool layer, VERDICT's I Identity.)

Check the reflex

Recall, don't re-read.

Every tool does one of two things for the model —

Let it know, or let it do
Train it, or fine-tune it
Cache it, or compress it

Know (retrieve data it lacks) or do (act on the world). Everything else about a tool is detail around those two jobs.

A sub-agent invoked as a tool by a primary agent is —

A plain function tool
A hidden built-in tool
An agent tool proper

An agent tool: the primary agent keeps control and processes the sub-agent's output, rather than handing off the whole conversation. A2A extends this to remote agents.

Naming a tool create_critical_bug_in_jira over update_jira most helps —

The model run faster
Audit logs and tool choice
Lower the token cost

Two wins: the model picks the right tool more reliably, and logged calls read clearly in the audit trail, a governance (Evidence) decision baked into the name.

Carry this into the week

Look at one tool your agents call. Ask two questions: does its description tell the model exactly when to use it? and which taxonomy box is it in: does it merely read, or does it act? If it acts, it needs a gate. That instinct is the whole of Day 2 in miniature.

Go deeper (primary source)

The MCP introduction and the Google ADK tools docs are the canonical, hands-on references for defining tools well.

Notes

Styer, Patlolla, Mohaan, Díaz & Nawalgaria, Agent Tools & Interoperability with MCP (Day 2), "Tools and tool calling" pp.9–14.

Up next → Day 2 · Lesson 2: Designing Tools the Model Can Use. The handful of design rules (describe actions not APIs, publish tasks not endpoints, stay granular, validate, write errors the model can act on) that separate a tool an agent uses correctly from one it fumbles.