An agent is only as useful as the tools you give it. This chapter covers function calling fundamentals and the two protocols standardizing how agents talk to tools and to each other.
Core concepts
- Function/tool calling fundamentals: A tool is a function with a schema the model can read — name, description, and parameter types — that the model requests by name rather than executing directly. OpenAI: Function calling · Anthropic: Tool use
- Parallel vs sequential tool calls: Most frameworks support requesting multiple independent tool calls in one turn — design tools to be safely callable in parallel where possible.
- Tool result formatting: Return concise, structured results — a huge JSON blob back to the model burns context and often confuses it more than it helps.
What Is It?
The tools chapter explains how agents act on the world: function calling, MCP servers, and Google A2A.
Child pages dive into MCP implementation and A2A task cards.
Without tools, agents only chat — tools turn language into operations.
Why Should I Care?
Tool design is where security and UX live (permissions, confirmations, idempotency).
Standards reduce one-off integrations per SaaS product.
Real World Analogy
Function calling is hiring a handyman; MCP is the standardized toolbox socket so any handyman can grab the same wrenches without custom adapters.
Visual Mental Model
agent -> function call
agent -> MCP server -> APIs/DB
agent <-> A2A peer agentsBeginner Explanation
This hub covers classic function calling plus MCP (tools/data) and A2A (agent-to-agent). Start with function calling mental model, then read protocol chapters.
Smallest Possible Example
def search_docs(q: str) -> str:
return f"results for {q}"
# expose via MCP server in productionCommon Mistakes
❌ Giant mega-tools that do everything.
Models pick wrong actions; split into focused tools with clear descriptions.
❌ No auth on MCP servers.
You expose internal APIs to anyone who can reach the port.
❌ Ignoring idempotency on write tools.
Models retry; duplicate charges or tickets follow.
Real Project Example
Anthropic pushed MCP as the USB-C for agent tools; Cursor and Claude Desktop consume MCP servers.
Google A2A targets agent collaboration in enterprise suites.
Build This Mini Project
List three actions your agent needs; design one function signature each with docstrings models can read.
Interview Question
What problem does MCP solve?
It standardizes how agents discover and call tools/data sources so each integration is not a bespoke plugin — one protocol, many servers.
Key Takeaways
- Tools turn language into actions.
- Hub links MCP and A2A depth.
- Small focused tools win.
- Treat tool security like API security.
Resources
YouTube learning
Core concepts from video walkthroughs:
The 60-second story
An employee who can only talk is a charming intern. An employee who can use the calculator, the calendar, and the warehouse terminal is useful. Tool calling is handing them those objects, with labels, not letting them mime the objects in prose.
A tool is a function plus a name tag: what it is called, what it is for, what arguments it takes. The model does not run your code. It requests the name. Your runtime runs the function and brings the result back, like a receipt. That gap is the whole security story. The model asks. You decide whether the ask is allowed to happen.
Parallel calls are sending two runners at once when the errands do not depend on each other. Sequential calls are “open the door, then walk through it.” If you mark a tool parallel and it is not safe to double-run, you will charge a card twice and learn a new hobby.
The result you bring back should fit on a sticky note. A giant JSON blob is a novel you force the model to reread. They get lost, they get expensive, and they call the tool again because they did not see the one field that mattered. Return the id, the status, and the error. Leave the encyclopedia in the database.
Map the errands.
- The model is the employee who requests.
- Your code is the one who actually does the errand.
- The schema is the name tag.
- Parallel tools are independent errands.
- A fat tool result is a novel on a sticky note.
- MCP, on the next page, is a standard plug so you are not forging name tags per app.
- A2A is how two employees delegate, which is not the same as a calculator.
def lookup_order(order_id: str) -> dict:
return {"id": order_id, "status": "shipped"}Small return, boring and correct. The model can say “shipped” without rereading a warehouse dump.
Tool calling exists because chat is not allowed to pretend it queried production. The schema exists so the request is structured. Your runtime exists so the model never becomes the process that holds the database password. If you blur those, you do not have tools. You have a prompt that hopes.
Mental model: the employee requests, you run the errand, you hand back a sticky note. Not a novel. Not the keys to the building.
You can explain the page if you insist on that split, and if you know when two errands may leave at the same time.
