Tools and MCP
An agent is only as capable as its tools. Tools are typed capabilities (name, description, JSON schema, implementation). The Model Context Protocol (MCP) is how modern stacks expose tools and data sources in a consistent shape so you are not hand-wiring every integration forever.
Why it matters
Hand-wired tools work for demos. They do not scale across products, IDEs, and runtimes. MCP lets one server expose tools that Claude Code, IDEs, LangGraph wrappers, and Google ADK can consume. You author the capability once; clients connect.
Good tool design (the craft)
- Clear name and description so the model knows when to call it (and when not to).
- Tight input schema: required fields, enums where possible, no giant free-text blobs if structure exists.
- Deterministic, observable failures: return errors the model can read, do not crash the loop silently.
- Least privilege: tools should not be able to do more than the product needs.
MCP in practice
You will connect an agent to real tools (prepared examples in the live session) and watch it choose among them. Mentally separate three layers: the model deciding, the host executing, and the MCP server providing capabilities.
Tip
Two stacks, same idea
LangGraph: bind tools to the model / tools node, or connect MCP via community adapters. Google ADK: first-class MCP tool integration in the ADK docs. Same protocol idea, different host.
What you will do
Give your agent at least one real tool that touches the outside world (HTTP, Sheets, calendar, or a toy CRM). Trace a full Think → Act → Observe cycle in the logs. Optionally connect one MCP server and call a tool through it.
Watch out
Common mistakes
- Vague tool descriptions that cause wrong or missing tool calls.
- Tools with side effects and no confirmation step.
- Assuming MCP replaces judgment about which tools to expose.