This is the part that surprises people. The model chooses which tool to call based only on the tool's name, its description, and the names of its parameters. There is no other signal. A tool with a vague description will be used wrongly or ignored entirely, regardless of how well it's built.

The Same Tool, Described Two Ways

WEAK

name: get_data

description: Gets shipment data.

-> The model doesn't know what data, for what, or when to

use this rather than one of the other four lookup tools.

It will guess, and sometimes guess wrong.

STRONG

name: get_shipment_status

description: Returns the current status, location and

expected delivery date for one shipment, by its

reference number. Use this first when investigating

any delay. Does not include customs documents, use

get_customs_records for those. Returns not_found if

the reference is invalid.

-> Says what it does, when to use it, what it excludes,

what to use instead, and what happens on failure.

Write Tool Descriptions Like Onboarding Copy

You are briefing a capable new colleague who will read this once and then work unsupervised. Tell them what it does, when to reach for it, what it doesn't cover, and what to use instead. Four sentences. This is the highest-leverage writing you'll do on an agent project and it's routinely left to whoever implemented the function.

Agentic AI and MCP for Product Managers

Module 1What 'Agentic' Actually Means

Module 2How an Agent Actually Works

Module 3MCP: What It Is and Why You Should Care

Module 4Designing the Tool Layer

Module 5Permissions and the Human in the Loop

Module 6Evaluating Agents

Module 7Cost, Latency and Unpredictability

Module 8Designing What the User Sees

Module 9Risk and Blast Radius

Module 10When an Agent Is the Wrong Answer

Module 11Final Project: Design One Real Agent End to End

Module 12Appendix: The Prompt Library

Names and Descriptions