On this page
The core idea
An agent can select a tool based on language, but your application must enforce the tool’s real contract. Inputs need validation, actions need authorization and results need predictable structure. A narrow tool with one clear job is often easier to reason about than a broad function that accepts arbitrary commands or unrestricted queries.
A practical approach
Step 1
Specify the purpose, input schema, required permissions and possible side effects. Separate read-only lookup from operations that modify records.
Step 2
Return structured success and failure results with stable identifiers. Include enough information for the next step without exposing unnecessary data.
Step 3
Test invalid arguments, unavailable dependencies and unauthorized users directly against the tool, without relying on the agent to avoid those cases.
Worked example
A course assistant needs to look up available programmes. Give it a search_programmes tool with topic and level fields. Do not give it a general database execution tool when that broader capability is unnecessary. A separate enrollment action should check identity and require its own approved inputs.
A mistake to avoid
A descriptive sentence such as ‘only use for authorized users’ is not an access check. The server-side implementation must reject unauthorized calls even if the model supplies well-formed arguments.
Try it yourself
Write a one-page contract for a single read-only tool. List three valid requests, three invalid requests and the exact response shape for a dependency timeout.
Your implementation checklist
- The tool has one clear purpose.
- Read and write capabilities are separated.
- Validation and permissions run on the server.
- Failure responses are structured and actionable.
Share or cite this guide
Innovate with Ajay Editorial (2026-10-04). Write a Tool Contract before Connecting an AI Agent. https://innovatewithajay.com/blogs/write-a-tool-contract-for-an-ai-agent