A support agent needs to answer a question about a company policy. A model can produce a convincing reply without seeing the policy, but that reply may be wrong.
Give it a way to find the document and show the source. The reader can then check the answer. That is a useful first workflow to build before connecting a large collection of tools.
Finding information
Use web search for public information that changes. The Responses API web-search tool can retrieve current sources and return citations. Depending on the request and configuration, search may be optional.
Show the sources and check their dates. A page can be evidence for an answer without being an instruction your agent should follow. An answer that looks right but lacks support should fail your evaluation.
File search is for the documents you supply: manuals, contracts, policies, and similar material. OpenAI's hosted tool searches an uploaded vector store using semantic and keyword retrieval.
Before writing the prompt, organise the documents. Give each a clear title and version, remove obsolete copies, and enforce access controls before sending results to the model. Then test retrieval and answer quality separately: did the search find the right passage, and did the answer use it correctly?
Letting an agent use tools
Function calling lets the model ask your application to run code. Define a narrow contract, describe its arguments, and validate them on the server. Check the user's permissions before executing it, then return a structured result.
A tool call is a request, not permission. Use idempotency keys for actions that might be retried, and get human confirmation before consequential writes.
Remote MCP servers can expose tools through a common protocol. Discovery alone does not make a server trustworthy. Check who operates it, which methods it offers, what data those methods can access, and where approvals occur.
Start with read-only access and narrow scopes. Record which tools were called, but keep secrets and sensitive document contents out of logs. Keep retrieved content separate from developer instructions to reduce prompt-injection risk.
A long tool catalog takes up context. Tool search can defer definitions until they are relevant; programmatic tool calling can orchestrate multiple calls when the workflow and returned data support it.
Both add paths to test. Measure end-to-end latency and check that no path bypasses your authorization layer.
Higher-risk tools
A shell, computer-use tool, and image generator each need different controls. The shell executes commands. Computer use operates an interface through screenshots and actions. Image generation creates or edits visual material.
Use isolated environments and allowlists where appropriate, treat generated artifacts as untrusted, and require review before external actions. For computer use, verify the result of a consequential click rather than assuming it worked.
Testing before launch
Your test set should include a normal request and cases where the agent must stop or recover: missing evidence, conflicting documents, injected instructions, denied permissions, a timeout, and a repeated action.
Track retrieval quality, citation accuracy, unauthorized-action attempts, task success, latency, and cost. Keep a small regression set with synthetic data in source control. Only publish an accuracy figure if you have measured it.
For each tool, record its owner, permissions, retention rules, rollback path, and escalation point. Start with a narrow pilot and review failures before expanding access. The downloadable checklist below can help you work through those decisions.
Sources and further reading
Documentation reviewed November 9, 2026. Verify current model support, limits and pricing before implementation.