An AI system can only use a tool through the interface it receives. If the tool name is vague, the inputs are unclear, or the result is hard to interpret, the agent may choose the wrong tool or use it incorrectly.
A tool is part of the AI system’s design. Its description should make clear what it does, when it should be used, what information it needs, and what it returns. The system should also handle invalid inputs and errors in a way that makes the next step understandable.
For example, a tool named search gives little guidance. A tool described as “search the official course handbook for course rules and deadlines” gives a clearer signal about its purpose.
Suppose you are building an assistant that answers questions from a course handbook. It has access to a search tool. A useful tool definition could clarify:
Purpose: Search the official handbook for course information.
When to use it: Use it when an answer depends on handbook content or a course-specific rule.
Inputs: A clear search query, and the course identifier if there are multiple handbooks.
Results: Relevant passages with section names or page references.
No-result behavior: Return a clear “no relevant passage found” result so the assistant knows not to invent an answer.
This helps the agent distinguish a grounded answer from a guess and gives it information it can use in its response.
When you design a tool for an AI system, consider these questions:
Does the name make the tool’s purpose clear?
Does the description explain when the tool should—and should not—be used?
Are input names, formats, and required fields understandable?
Does the tool return information in a predictable, useful format?
Do errors explain what went wrong and how the system can recover?
Design the interface, then test it on realistic tasks. A test set can include ordinary requests, ambiguous requests, missing inputs, and cases where the tool should not be called. Review the results and revise the interface when the agent repeatedly misunderstands it.
Engineering takeaway: Design a tool so its purpose, inputs, and results are clear to the agent.
Design a tool that lets an AI assistant search a course handbook. Write a short specification with:
The tool’s name and purpose.
When the assistant should use it.
The input fields and their formats.
The result fields the tool should return.
What the tool should return when it finds no relevant information or receives invalid input.
Then try three realistic questions. Check whether the assistant chooses the tool appropriately, supplies usable inputs, and explains the result accurately. Add any recurring failure to your evaluation set.
Anthropic, “Writing Effective Tools for Agents — With Agents” (September 11, 2025). The article discusses clearly defined tools, tool descriptions, realistic evaluation tasks, and iterative improvement.
OpenAI, “Function Calling”. The guide recommends clear function names and parameter descriptions, predictable and intuitive functions, and structured inputs that help prevent invalid calls.
This post is an independent study reference based on publicly available engineering material. It is not an official guide or endorsement from the cited organizations.
AIYING — Accomplishing with AI
AI Engineering Principles & Practice · 004
Applying Lateral Thinking to Create Meaningful Impact with AI
By Ravindra Dastikop
Engineering focus: Tool selection, interface contracts, error feedback and evaluation.
Case type: Research-grounded fiction. Characters, events and trial observations are invented. Sources checked: 5 November 2026.
1. The situation and impact sought
Kabir was developing an assistant for a retail support team.
The assistant helped staff investigate return requests, check eligibility
and prepare the next action. Creating a return required an authorised
staff member’s approval.
Its tools were interfaces through which the model could request
information or invoke application functions. The team had exposed twelve
tools, largely reflecting existing backend endpoints.
Each addition had answered a reasonable need: find an order, inspect a
shipment, retrieve policy exceptions or check a return’s status.
Yet the assistant sometimes selected overlapping tools, confused
identifiers and repeated requests after incomplete responses.
The team’s usual repair was another instruction—or another tool.
Kabir had two weeks to test improvements in a staging environment using
representative records and simulated failures.
The useful outcome: Complete the correct support task
with the required approval, accurate records and manageable review effort.
A shorter tool list would count as progress only if it preserved useful
capabilities.
That was why removing any of them initially seemed unreasonable.
During one test, the assistant found the correct order but passed a
shipment identifier into a field expecting an order identifier. The
value was a valid string. It identified the wrong kind of object.
In another, a tool returned an empty list after a service timeout.
The assistant interpreted this as evidence that no return existed.
“Let’s add a recovery tool,” suggested Sana, the support lead.
Kabir wrote down the suggestion. Then he looked at the tool catalogue.
They had built it one endpoint at a time. Nobody had reconsidered
whether the catalogue should still follow that structure.
He asked a different question:
“Why must the assistant make every backend choice that our
application already knows how to make?”
Sana pointed to a familiar sequence. Once staff had identified an
order, they normally inspected its items, customer details and shipment
information together.
The assistant performed those lookups separately.
That was one opportunity. But Kabir resisted turning it immediately
into a single giant tool.
He explored three alternatives.
They could retain the existing tools and improve their names,
arguments and responses.
They could offer a smaller set organised around support tasks.
Or they could keep a larger catalogue and expose relevant tools
through discovery when needed.
An AI assistant helped compare the proposals. Its first recommendation
combined investigation and return creation into one convenient operation.
Kabir rejected that boundary.
A request to investigate a return did not authorise creating one.
He tried consolidating only the related information retrieval.
A read-only tool assembled order items and shipment details while
preserving their identifiers and source status.
That removed several routine choices from the model.
The first version still failed.
When shipment information was unavailable, the response contained an
order record and no shipment section. The assistant treated the
missing section as “not shipped.”
Kabir changed the contract. Each component now reported whether it was
available, absent or unavailable because of an error. Partial results
were labelled.
Then the team tested a customer with several orders.
The convenient tool selected the most recent one.
The customer had meant an older purchase.
Kabir removed that assumption. Search could return candidates.
The context tool required a resolved order identifier. When the
user’s request remained ambiguous, the assistant had to clarify.
The revised interface contained six tools.
One searched for orders. One assembled order context. One checked
eligibility against the applicable policy. One prepared a return
draft without changing operational records. One created the approved
return. One checked an existing request’s status.
The underlying services remained.
The change concerned the interface presented to the model.
A timeout during return creation produced another difficult test.
The request might have succeeded even though the response had not arrived.
The assistant proposed trying again.
The backend needed a reliable way to recognise the same operation
and check its status. A better tool name could not resolve uncertainty
about whether a write had occurred.
Kabir added this case to the acceptance tests rather than hiding it
inside a reassuring error message.
The team compared the original interface, a clarified twelve-tool
version and the six-tool design. A separate discovery experiment
examined whether a broader catalogue could remain usable without
presenting everything initially.
The fictional findings were mixed. Consolidation helped some routine
tasks, while unusual investigations still benefited from specialised
access. Aggregate responses also cost more when they fetched
information nobody needed.
Kabir proposed a limited pilot for the defined return workflow.
Sana read the change summary.
“You deleted half the tools.”
“From this interface,” Kabir replied. “We kept asking what the
assistant needed to decide—and what the application could handle reliably.”
Creative Challenge questions whether an established arrangement is
the only useful way to proceed. It does not require proving that
the existing arrangement is defective.
In Serious Creativity, de Bono distinguishes this from
criticism and discusses challenging assumptions and arrangements
that continue because nobody has reconsidered them. See the
“Challenge” summary, printed page 314, in the
supplied edition.
[1]
Kabir challenges this assumption:
Each backend endpoint should become a separate tool available
to the model.
The challenge opens several directions:
Preserve the structure but clarify its contracts.
Organise tools around meaningful tasks.
Discover specialised tools when needed.
Move predictable coordination into application code.
This is Creative Challenge, not PO. There is no
deliberately provocative statement requiring movement from an
apparently unreasonable position.
The modern tool-design application is this series’ adaptation.
Complete the correct return task with controlled changes and useful review.
Accepted arrangement
Expose backend operations individually.
Challenge
Must the model choose and coordinate every operation?
Generate alternatives
Clarify existing tools, consolidate selected tasks, or introduce discovery.
Preserve boundaries
Keep investigation, preparation and execution distinct where their authority differs.
Test
Compare actual outcomes, recovery and total effort.
AI’s contribution
AI can identify overlapping descriptions, suggest alternative groupings
and generate difficult test requests.
Its suggestions require review. A convenient combination may conceal
an assumption, increase authority or make partial failures harder to
interpret.
Reusable prompt
Examine this tool catalogue: [catalogue].
Our user task is [task]. Our constraints are [constraints].
Challenge the assumption that the current boundaries must remain
unchanged. Generate three different designs: clarify the existing
interface, consolidate selected operations, and discover specialised
tools when needed.
For each, identify which decisions remain with the model, which
move into code, what capabilities could be lost and how failures
would be reported.
Preserve distinctions between reading, preparing and executing.
Do not assume fewer tools are better. Propose a small comparison
with observable success criteria.
More backend orchestration and partial-result handling.
Does consolidation preserve necessary flexibility?
Limited trial.
Discover relevant tools
Retains a broader catalogue.
Discovery adds another selection step.
Can the assistant find the required capability?
Separate experiment.
One broad “handle return” tool
Simple entry point.
Conceals scope, assumptions and effects.
Can investigation occur without unintended execution?
Reject this proposed design.
Define contracts beyond field types
A tool contract should explain:
Its purpose and when to use it.
Required identifiers and their meaning.
Preconditions and permitted effects.
The meaning of successful, empty and partial results.
Recoverable failures and unresolved outcomes.
A structurally valid request can still contain the wrong identifier
or an unjustified selection.
Preserve ambiguity
A tool should not silently select the newest order when several
candidates could match. Either require a resolved identifier or
return enough information for clarification.
Make errors useful
“No matching record,” “access denied” and “service unavailable”
imply different next steps. Do not collapse them into an empty response.
Treat uncertain writes explicitly
If a response is lost after a mutation request, success may be unknown.
The proposed design uses operation identifiers, status checks and
backend deduplication where supported. These mechanisms require
implementation and testing; a prompt cannot supply them.
The decision is a trial of the six-tool interface for a bounded
workflow—not a rule that six tools, or fewer tools generally,
produce better agents.
Anthropic’s tool-engineering guidance recommends clear purposes,
meaningful responses and evaluation with realistic tasks. It
discusses selective consolidation rather than simply wrapping every
existing endpoint. This supports examining interface boundaries;
it does not establish the best catalogue for this fictional retailer.
[2]
Anthropic’s advanced tool-use work describes discovering tools on
demand. It provides an important alternative to removing capabilities
from a large catalogue. Its reported outcomes are specific to its
experiments and configurations.
[3]
The cited Model Context Protocol specification defines tool
descriptions, input schemas, optional output schemas and error
signalling. These describe an interface, but schema compliance alone
does not establish business correctness or authorisation.
[4]
Anthropic’s agent-evaluation guidance distinguishes the interaction
transcript from the resulting state and discusses repeated trials.
That distinction matters when an assistant says a return was created:
the test must inspect whether the correct record actually exists.
[5]
Case adaptation
The retailer, twelve-to-six redesign, failures and pilot proposal are
fictional teaching choices. The retry and approval arrangements are
proposed engineering requirements for this scenario.
Uncertainty
Consolidation can increase response size, backend work and hidden
coupling. Discovery can fail to surface an appropriate tool.
Clear granular tools may outperform both.
The cited organisations are not being represented as users of
de Bono’s methods.
Choose a workflow with several functions or steps.
List the decisions its user must make.
Identify which decisions are meaningful and which are routine coordination.
Challenge one existing boundary.
Develop three alternatives.
Walk through an ambiguous request and a partial failure.
Check whether any convenience has introduced an unsupported assumption.
You can simulate the interfaces using written tool cards.
Technical extension
Compare the existing interface with clarified descriptions and a
redesigned catalogue.
Keep the model, task set and permissions comparable where practical.
Record differences that prevent direct comparison. Test discovery
separately before combining improvements.
Include:
Multiple matching records.
Similar identifier types.
Missing required information.
Empty results and unavailable services.
Partial responses.
Expired approval.
Timeouts after possible writes.
Rare tasks needing specialised capabilities.
Check the final system state, not just the assistant’s wording.
Measure accepted task completion, incorrect selections, parameter
errors, unintended changes, recovery, human corrections, latency
and total cost.
Record tool-call counts as diagnostic information. Fewer calls are
not automatically better.
Reserve validation tasks and repeat variable trials. Do not require
one exact call sequence when several paths correctly satisfy the task.
Stop or revise if the redesign loses required
capabilities, conceals uncertainty or makes consequential actions
harder to control.
Design tools around the decisions an agent must make. Keep
predictable coordination in code when that improves reliability,
while retaining the flexibility the task needs.
Read tool traces and results. Failures may come from descriptions,
semantics, backend behaviour or recovery—not simply model choice.
For technical leaders
Evaluate the interface and its operating responsibilities together.
A shorter catalogue may require more orchestration, monitoring
and maintenance.
Ask what became easier, what became hidden and who owns the
resulting complexity.
Limits of transfer
Task-oriented consolidation can suit stable, repeated workflows.
Exploratory work may benefit from granular capabilities or discovery.
A broad tool is especially difficult to assess when it mixes
information gathering with consequential changes.
Transfer question
Which decisions in your tool interface genuinely require judgment—and
which exist because your backend happened to be divided that way?
Editorial note: This is research-grounded fiction for
professional learning. Sources support the technical discussion, not
the fictional trial observations. The connection between Lateral
Thinking and the engineering choices is this series’ educational
adaptation. Platform capabilities and specifications can change.
