External APIs
Agency is useless if every action is a free-form HTTP request the model can point at your metadata service.
A labeled button on the wall, not a raw wiring closet.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
Safe weather tool
Scroll inside the frame to explore · use + / − to zoom up to 200%
Model sends city. You attach the API key and hit a fixed host.
Key Takeaways
- 1.Most tools are HTTP: your code calls someone else's API. Wrap one capability per tool — not a giant 'call_any_url'.
- 2.Timeouts, auth, and error mapping live in the wrapper. Never let the model supply the full URL and headers.
- 3.One tool = one vendor operation. Secrets stay in env.
- 4.Timeouts and retries in the wrapper. Map HTTP errors to short strings.
- 5.Ban open URL tools unless sandboxed.
Learn elsewhere
- →Tool Validation
- →Retry & Fallback
Real Example
Scenario
get_weather(city) hits api.weather.com with your key. There is no fetch(url) tool on this agent.
What you would do
In Tool Calling & Function Calling, apply External APIs to this scenario: get_weather(city) hits api. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
One capability per toolFixed host, your authTimeouts in the wrapperNo open URL from the model
Cheat Sheet
Quick recap
quick ref- •Labeled button
- •Secrets stay server-side
- •Map errors
- •SSRF if you allow any URL
Common Mistakes
- ✕A generic http_request tool in production
- ✕Putting API keys in the schema 'for convenience'
- ✕No timeout so one vendor hangs the agent