A renewal agent can call the CRM, email, calendar, support, document search, and contract systems. On its first run, it asks every system for everything related to one customer.
The result looks thorough: hundreds of CRM fields, years of ticket history, complete email threads, and the same contract attached to several messages. But the agent now has to spend time and tokens deciding which records matter before it can make progress on the renewal.
The agent is well connected. It is also slower, more expensive, and less certain.
Adding a tool expands what an agent can reach. It does not guarantee that the agent can select the right capability, retrieve a bounded result, or preserve enough of its execution budget to finish the task.
Tool schemas consume attention before the first call
An LLM needs the name, description, and input schema of each available tool before it can choose one. When several tools expose similar actions, selection becomes a routing problem.
Consider a broad interface like this:
{
"name": "manage_account",
"description": "Search, update, assign, add a note, change a stage, or create a task for an account",
"parameters": {
"account_id": "string",
"operation": "string",
"query": "string",
"fields": "object",
"assignee": "string",
"stage": "string",
"note": "string",
"due_at": "string"
}
}
It appears flexible, but every call asks the model to infer which combination of optional parameters represents the intended action. Validation and permissions must then account for every mode hidden behind the same interface.
A task-shaped read is less ambitious:
{
"name": "get_renewal_record",
"description": "Return the approved renewal view for one customer, including source timestamps",
"parameters": {
"customer_id": "string"
}
}
The narrower tool is easier to select, permission, test, and recover. It may require additional orchestration steps, and it will not cover every future account workflow. That is a real tradeoff. The benefit is that each supported step carries less ambiguity.
Tool count therefore has two costs before execution begins:
- every schema occupies context;
- overlapping descriptions increase routing uncertainty.
Neither cost appears in a dashboard that reports only the number of connected systems.
Connectivity does not control the response shape
Suppose the CRM API returns 180 fields for an account. The renewal decision needs eight:
- renewal date;
- contract value;
- account owner;
- current stage;
- product set;
- open commercial risks;
- last verified customer contact; and
- source timestamps.
Passing all 180 fields to the model moves a data-selection problem into the most expensive part of the workflow. The same failure appears when an email connector returns complete message bodies instead of headers and short extracts, or when a document connector sends the same attachment once for every message that references it.
Each unnecessary value consumes something. It uses tokens when placed in model context, storage and transfer when retained outside it, and reasoning attention when the agent has to filter it.
The connector should return a task-shaped view:
{
"customer_id": "cus_1842",
"renewal_date": "2026-09-30",
"contract_value": {
"amount": 120000,
"currency": "USD"
},
"account_owner_id": "usr_291",
"open_risk_ids": ["risk_17"],
"source_updated_at": "2026-07-29T08:42:10Z"
}
Raw records can remain available for inspection without being injected into every prompt. The agent can retrieve full email bodies or documents only after a bounded search identifies the relevant records.
Prompting the model to “focus on what matters” does not repair an oversized payload. By that point, the system has already paid to retrieve and expose the data.
MCP standardizes exchange, not business meaning
The Model Context Protocol gives compatible systems a common way to expose tools and context. That interface boundary is useful, but it cannot decide what a renewal agent needs from a CRM or which source should win when records disagree.
An MCP server can expose a technically valid tool that still returns the wrong slice of the system. It does not automatically answer questions such as:
- Is this the current policy or an archived version?
- Does the response include all pages?
- Can this write be retried safely?
- Do two records represent the same customer?
- Is the caller allowed to see the underlying support incident?
Protocol compatibility and context quality are different properties. Standardizing the call does not remove the need to design the tool contract around the business task.
Pagination can make an incomplete result look complete
The agent asks for all open support tickets. The API returns 50 records and a continuation token.
If the tool output does not expose that token clearly—or its contract does not say when pagination is required—the first page can look like the complete result. The agent may produce a confident renewal summary while missing the ticket that explains the account risk.
“Fetch every page” is not always the right correction. An account with years of activity may have thousands of records. The workflow needs a completeness condition, such as:
- retrieve all open tickets;
- stop after the relevant date boundary;
- continue until a known record is found; or
- escalate when the result exceeds the reviewable limit.
The condition belongs in the workflow and tool contract. Otherwise, the model has to invent one at runtime.
Retries are part of the tool interface
Reads and writes fail differently.
If a CRM read times out, another attempt may be harmless. If a request to create a follow-up task times out after the server commits it, retrying can create a duplicate. Refusing to retry leaves the agent uncertain about whether the action happened.
A production write tool needs explicit answers:
- Did the request fail before or after execution?
- Does the operation accept an idempotency key?
- Can the agent look up the committed action?
- What evidence identifies a successful write?
- Which errors require a person rather than another attempt?
These details rarely matter in a short demo. They matter as soon as an agent changes business state.
Measure accepted outcomes, not available tools
A useful evaluation starts with one outcome—for example, prepare a renewal brief with current commercial terms, unresolved support risks, source references, and an escalation when required evidence is missing.
Then measure the system that produces it:
- latency per accepted brief;
- tokens and tool calls per accepted brief;
- incomplete or duplicated records;
- unsafe or unnecessary retries;
- reviewer corrections; and
- cases escalated because a capability was intentionally unsupported.
Removing a broad tool may leave an edge case unavailable until the team designs a safer capability. A bounded agent that identifies that limit is often more dependable than one that guesses its way through a large tool catalog.
The practical question is not “How many systems can the agent call?” It is “Does each connection return the right information or perform the right action under conditions we can test?”
That is the distinction between an agent that looks capable in a tool list and one that can finish a workflow without losing control of cost, latency, or business state.
This article was adapted for the DEV community from More Tools Can Make an Agent Slower, originally published by Coryntas.
Top comments (0)