Give instructions and execution different responsibilities
A prompt describes what the application is trying to accomplish and how the model should respond. A tool contract defines an operation that the application can execute. Both matter: clear instructions help the model choose a useful action, while application code determines whether that action is valid and authorized.
For an illustrative support assistant, a prompt might ask it to find the current delivery status. A lookup tool retrieves the order record. The model’s proposed order identifier is not evidence that the user may access that record, and a fluent answer is not evidence that the lookup succeeded.
Define a narrow operation
Describe the tool’s purpose, input fields, permitted values and result structure. Use separate operations for reading a record, preparing a draft and publishing a change where their permissions or review rules differ. Avoid a general-purpose write operation when the workflow only needs a delivery-status lookup.
Specify missing-record and unavailable-service results. Define which fields come from the receiving system and which are model-generated. Give the model enough description to distinguish similarly named tools, but keep authoritative business rules in application code.
Validate before executing
Check argument structure and business constraints, then enforce the caller’s permissions against the actual resource. A schema-valid request can still identify the wrong customer, use stale data or propose an action outside the user’s authority. Treat retrieved text as task data rather than a new permission to execute.
Anthropic’s tool-use documentation distinguishes application-executed client tools from provider-executed server tools. For a client tool, the model returns a structured request and the application executes it and returns a result. Follow the current provider documentation for the chosen integration; this guide describes the contract rather than a complete SDK example.
Separate an attempt from a confirmed change
Store the task identifier, operation, attempt and authoritative result. A timeout may leave the outcome unknown. Before repeating a write, check whether the receiving system completed it and use its supported duplicate-handling mechanism. Do not assume that a transport error means nothing changed.
Return a result that distinguishes success, failure and unresolved status. Keep the final response aligned with that evidence: report a confirmed update only when the receiving system confirms it. When several dependent tools are needed, execute them in the order required by the task rather than parallelizing a write that depends on a preceding lookup.
Evaluate the action trace
Test missing arguments, inaccessible records, stale permissions, duplicate delivery, downstream failures and misleading retrieved instructions. Include cases where the correct behavior is to ask for clarification or stop. Evaluate tool selection, arguments, authorization and result handling as well as the final wording.
Track verified task completion, incorrect actions, unresolved attempts, review corrections, latency and cost. Compare with a fixed workflow on the same tasks. A higher rate of syntactically valid calls does not establish that the application completed the intended work.
Release with clear operating ownership
Start with read or draft operations where they fit the task. Agree review requirements before enabling consequential writes. Version prompts, tool schemas and execution code together, and rerun relevant evaluation after changing any of them. Provide a fallback and a procedure for reconciling partially completed tasks.
For a broader implementation plan, read the agent development guide. Explore MCP server development or discuss a scoped tool integration with TensorBlue.