Reliable Tool Calls Begin With Narrow Contracts

A model can request a function call, but your application decides whether that request deserves execution. That distinction is the foundation of reliable tool use. Good results depend less on elaborate prompting than on narrow contracts, explicit permissions, and useful feedback. Build those pieces around one concrete workflow before expanding your tool catalog.

Step one defines the decision before the function

Start with a user task: checking whether an order can be canceled. Separate the decisions involved. The application needs to find the order, inspect its fulfillment state, and potentially request cancellation. Those are different capabilities, with different consequences.

Create separate tools for reading order status and requesting cancellation. Avoid a general order management tool whose behavior changes through a loosely defined action field. Narrow tools make selection easier to evaluate and let your application grant read access without also granting permission to change an order.

Step two makes each input contract explicit

Describe every argument in terms the model can connect to the conversation. An order identifier should mean the public reference visible to the customer, not an undocumented database key. State whether the value must come from the user or may come from a previous tool result.

Use required fields for genuinely necessary inputs, enums for bounded choices, and explicit descriptions for units and formats. Keep optional fields limited. Where supported, strict schema enforcement can improve structural conformance, but it cannot establish that an identifier exists or that an operation is authorized. Validate those conditions separately.

Step three explains when each tool applies

A tool description should state its purpose, selection conditions, and important exclusions. The status tool retrieves current fulfillment information; it does not cancel anything. The cancellation tool changes an order and requires an eligible state plus the authorization your application defines.

Tell the model to ask for missing information rather than inventing arguments. Also distinguish a user asking about cancellation policy from a user requesting cancellation. Similar vocabulary does not imply the same intent. Examples in your evaluation set should exercise that boundary.

Step four keeps execution under application control

When the model requests a call, parse its arguments and check them against the contract. Then enforce authentication, tenant boundaries, permissions, and current business rules using trusted application context. Never accept a model-supplied customer identifier as proof that the caller owns an order.

Execute only approved tools, and return each result with the identifier expected by the API so the model can associate it with the correct call. Continue the interaction until the model produces an answer or your orchestration limit is reached. Support multiple requested calls deliberately; do not assume each response contains exactly one.

Step five makes failures recoverable without guessing

Return compact, structured outcomes that distinguish success, missing records, ineligible operations, and temporary failures. Include only information needed for the next decision. A cancellation refusal should explain the relevant business condition without exposing internal infrastructure details.

For mutations, use application-managed idempotency so a repeated request does not repeat the effect. After a timeout, reconcile the operation before retrying if its outcome is uncertain. Treat tool output as data, not as authority to override instructions, particularly when it contains customer notes or other untrusted text.

Step six measures decisions rather than fluent answers

Test tool selection, argument accuracy, permission enforcement, and recovery separately. Include missing identifiers, cross-account requests, stale order states, duplicate submissions, and malicious instructions embedded in retrieved content. A polished final answer is not evidence that execution was correct.

BestRelay publishes this walkthrough from a quality-first relay perspective: each request is forwarded to the official model named in it, without substitution, across Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. Compatibility with Claude Code, Codex, Gemini CLI, and any OpenAI SDK simplifies integration, but does not make every model's tool behavior identical. Verify capabilities against your chosen endpoint.

Create a BestRelay account to try your workflow. Billing is pay-as-you-go using provider-reported token counts, with cache reads and writes priced separately; members also earn referral commissions when invited users top up. Keep those costs separate from correctness metrics: a cheap call that triggers the wrong action is still a failed tool interaction.