Tool and Function-Calling Integration
The layer where a language model meets your systems, designed for a caller that will occasionally get it wrong: strict schemas, idempotent writes, and error messages written to be acted on rather than logged.
When an agent behaves badly, the prompt gets rewritten. In our experience the fault is usually one layer down: a tool with an ambiguous name, an argument that accepts free text where it should accept an enumeration, or an error message that tells the model nothing it can use. Tool design is API design for a caller that reasons rather than compiles.
Tool and function-calling integration is the design and engineering of the functions a language model can invoke: their naming, purpose, input schemas, output shapes, error behaviour, idempotency and permissions, tuned so that a model selects the right tool with the right arguments reliably enough to be trusted with real work.
Why tool design decides agent reliability
A model chooses a tool from its description and fills the arguments from a schema. Both are prompts, whether or not anyone treats them that way. The failures that follow are predictable:
| Design flaw | What the model does | The fix |
|---|---|---|
| Two tools with overlapping purposes | Picks either, inconsistently | Merge, or make the boundary explicit in both descriptions |
| Free-text argument for a bounded value | Invents a plausible variant that fails validation | Enumerate the allowed values in the schema |
| Vague tool name | Calls it for the wrong task | Name for the task, not for the endpoint |
| Opaque error | Retries the identical call | State what was wrong and what to try instead |
| Tool that returns everything | Fills the context window with noise | Return a summary with a follow-up tool for detail |
| Non-idempotent write | A retry creates a duplicate record | Idempotency key, enforced server-side |
Fixing these usually improves agent reliability more than any amount of prompt rewriting, and the improvement is permanent rather than fragile.
How we design and integrate tools
Shape tools around tasks, not around endpoints
Your API exposes resources; the agent needs actions. One task-shaped tool that fetches an account with its open items beats three resource endpoints the model has to compose correctly, and it removes an entire class of sequencing error.
Constrain the arguments
Enumerations rather than strings, typed dates, explicit required fields, and validation that rejects rather than coerces. Where an argument genuinely is free text, we validate it downstream and return a usable error rather than accepting nonsense quietly.
Write errors for a model
The error message is the only feedback the model gets, so it should say precisely what was invalid, what values are acceptable and whether retrying could ever help. A well-written error turns a failed call into a corrected one on the next step; a stack trace turns it into a loop.
Make every write safe to repeat
Retries happen. Every write takes an idempotency key so a repeat is a no-op rather than a duplicate, and supports a dry-run mode so an agent, or a test, can check an action before committing it.
Measure tool selection accuracy
We build a test set of realistic requests with the correct tool and arguments for each, then score selection and argument accuracy separately. That number becomes a release gate, so a new tool cannot quietly degrade the agent's choices elsewhere. It fits directly into the trajectory evaluation described under AgentOps.
Fewer tools, better chosen
Tool selection accuracy falls as the list grows, and the decline is steeper than most teams expect. We routinely cut a tool set by a third and see reliability rise. Where many capabilities are genuinely needed, they belong behind a scoped, discoverable boundary such as an MCP server rather than all loaded at once.
What the engagement covers
- An audit of the current tool set: naming, overlap, schema quality, error behaviour and measured selection accuracy.
- Redesigned schemas with enumerations, required fields and validation, plus rewritten descriptions and errors.
- Idempotency and dry-run support for every write, implemented server-side rather than assumed.
- Permission scoping per tool and per environment, so a staging agent cannot reach production.
- A tool selection test set wired into your pipeline as a release gate.
- Documentation written for the engineers who will add the next tool.
Where the tools should be shared across several agents or assistants, the same work is delivered as an MCP server so the controls live at the boundary.
How the engagement runs
Short, measurable and self-contained. The score before and after is the whole argument.
Tool audit and baseline
Existing tools inventoried, failure patterns collected from traces, and tool selection accuracy measured as a baseline.
Redesign
Schemas, names, descriptions and errors rewritten; tools merged or split; idempotency and dry-run added to writes.
Integration and testing
Tools wired back into the agent, selection and argument accuracy scored against the baseline, permissions scoped per environment.
Handover
Test set wired into CI as a gate, documentation delivered, and a working session on adding tools without regressing selection.
What you receive
A tool layer the model uses correctly, with the measurement that keeps it that way.
Tool audit
Every tool assessed for naming, overlap, schema quality and error behaviour, with the failures each one causes.
Redesigned tool set
Implemented tools with strict schemas, model-readable errors and scoped permissions.
Idempotency and dry-run
Safe repeat behaviour and pre-commit checking on every write, enforced server-side.
Selection test set
Realistic requests with correct tool and arguments, scored separately, runnable in CI.
Before and after scores
Tool selection and argument accuracy against the baseline, per request type.
Extension guide
How to add a tool without degrading selection accuracy elsewhere.
Is this the right engagement?
Worth being direct. Tool and Function-Calling Integration is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- An agent exists and misuses its tools, or picks the wrong one, more often than is acceptable.
- Retries create duplicate records or half-completed writes.
- The tool list has grown past a dozen and reliability has fallen.
- Errors from your APIs are written for developers and the agent cannot act on them.
- You are about to build an agent and want the tool layer right before the loop is written.
Choose something else if
- There is no agent and no plan for one. Tools without a caller are just an API.
- The systems have no programmatic interface at all.
- Several agents need the same tools, in which case build the boundary once with MCP server development.
- The real problem is the agent's planning loop rather than its tools.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What is function calling in AI agents?
It is the mechanism by which a language model invokes your code: it is given a list of functions with descriptions and input schemas, and it returns a structured call that your system executes. The quality of those descriptions and schemas determines how often the model calls the right thing with the right arguments.
Why does our agent keep calling the wrong tool?
Almost always because two tools have overlapping purposes, a name describes an endpoint rather than a task, or a description does not say when not to use it. Selection accuracy also falls as the tool list grows, so the fix is often to merge or remove tools rather than to explain them better.
How do you stop retries from creating duplicates?
Idempotency keys enforced on the server, so a repeated call with the same key is a no-op that returns the original result. This has to be server-side; an instruction telling the model not to retry is not a control.
How many tools should an agent have?
Fewer than teams expect. Selection accuracy degrades as the list grows, and in most of the agents we assess a third of the tools are unused or duplicative. Where a large capability surface is genuinely required, it belongs behind a discoverable boundary rather than loaded into every request.
Can you fix tools without rebuilding the agent?
Usually yes, and it is often the highest-return change available. The tool layer can be redesigned, measured and swapped in behind the same agent loop, which is why we treat this as a standalone engagement rather than only as part of a build.
Often paired with this
Most clients combine two or three engagements from the AI Agents & Agentic Automation pillar. These are the ones that most often run immediately before or after.
MCP Server Development and Integration
Your internal systems exposed as safe, scoped, audited tools that any compliant agent or assistant can use.
Read more →Custom AI Agent Development
An agent that completes work in your systems, with scoped tools, trajectory evaluation and a circuit breaker.
Read more →AgentOps: Monitoring, Evaluation and Guardrails
The operations layer for production agents: trajectory tracing, evaluation, spend ceilings and a tested kill switch.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.