Tools & Connections
Function calling, MCP, APIs, browser and computer use.
24 posts · showing 1–10
-
The Invoice Tool Timed Out, So the Billing Agent Called It Again. The Customer Was Charged Twice. A Timeout Is Not a Failure.
A timeout tells the agent it stopped waiting, not that nothing happened. Here is how a reasonable-looking retry turned into a double charge, and the idempotency key that makes the retry safe.
-
The Expense Agent Logged "Rate limit exceeded" as a Vendor Name. Make Tool Errors Impossible to Mistake for Results.
When a tool returns its failure as a plain string, the model reads it like any other output and carries on. The fix lives in the tool's return shape, not in the prompt.
-
The Inbox Agent Said Nobody Had Replied. The Search Tool Had Returned Page One of Four.
An agent can't tell "there's nothing here" from "I only saw the first page" unless the tool tells it. Here is how to make a paginated tool announce its own incompleteness, and why claims of absence need a stricter rule than claims of presence.
-
The Refund Tool Timed Out, the Agent Retried, and the Customer Got Paid Twice. Make Every Write Tool Idempotent.
A timeout tells the agent nothing about whether the write happened, and a retry is its most reasonable next move. The fix belongs in the tool, not in the prompt.
-
One Tool With Twelve Parameters or Four With Three? Let the Agent's Error Log Decide
Merging tools trades wrong-tool mistakes for wrong-argument mistakes. Your traces already show which one your agent makes more, and an overloaded tool leaves a signature you can grep for.
-
Your Tool Returned 4,000 Rows and the Agent Needed Three: Truncate, Paginate, or Summarize?
Most tool endpoints were written for a caller that can loop and discard. An agent reads the whole response in one gulp and keeps it forever — and the three ways of shrinking that response fail in completely different ways.
-
Cached or Re-Called? Giving Every Agent Tool a Staleness Budget
An agent that reads a value once and acts on it four minutes later isn't reasoning badly — nobody told it how long that value stays true. Per-tool staleness budgets, and the one rule that matters most before a write.
-
Your Agent Has One manage_calendar Tool. That's Why It Deleted the Wrong Meeting.
A single do-everything tool looks tidy in the schema and hides four separate problems: guessed actions, unvalidated payloads, permissions that can't tell reading from deleting, and traces that flatten three risk levels into one name. Here's where to cut instead — and where splitting makes things worse.
-
How Should a Team Review a Tool Description Diff? Treat It Like a Schema Migration
A six-word edit to a tool description is a behavior change with no compiler to catch it. Borrowing the review checklist teams already use for schema migrations turns an unreviewable prose diff into something you can actually approve.
-
The Tool Returned 200 and Nothing Happened
A calendar agent reported success on a meeting that landed at 3am, on the wrong calendar, with no invitation sent. The API did exactly what it was asked — and the return value gave the agent no way to know.