2.2.3. Agent Tools: Function, Code Interpreter, File Search, Connected
💡 First Principle: Tools fall into two families — you provide the logic (function/OpenAPI tools that call your code or APIs) or Foundry provides the logic (hosted tools like code interpreter, file search, web/Bing search). Matching the requirement to the right family is the recurring tool question.
The major tool types: Function tools map your own Python/C# functions to model-callable interfaces via JSON schema — use these for business actions (look up a ticket, place an order). Code Interpreter is a hosted, sandboxed Python environment for data analysis, math, and chart generation — the agent writes and runs code iteratively, isolated per session, with its own cost beyond tokens. File Search grounds the agent on uploaded files via a vector store. Connected/OpenAPI tools call external REST services by their OpenAPI spec. Web/Bing grounding brings in current public information.
| Tool | Logic provided by | Use when | Note |
|---|---|---|---|
| Function tool | You (your code) | Business actions, your APIs | Model emits call; you execute |
| Code Interpreter | Foundry (sandbox) | Data analysis, math, charts | 🧪 Extra cost; per-session sandbox |
| File Search | Foundry (vector store) | Ground on uploaded docs | Backed by embeddings |
| Connected / OpenAPI | External service | Call a documented REST API | Driven by OpenAPI spec |
| Web / Bing grounding | Foundry | Need current public info | Public web data |
⚠️ Exam Trap: Don't reach for Code Interpreter to "call our internal API" — that's a function or connected tool. Code Interpreter runs its own sandboxed Python for analysis; it isn't a gateway to your systems. Likewise, file search grounds on documents but can't take actions.
Reflection Question: An agent must compute statistics on an uploaded CSV and create a record in your CRM. Which tool handles each task, and why can't one tool do both?
