More Tools Can Make an Agent Slower

An illustrative renewal agent can call a CRM tool, an email tool, a calendar tool, a support tool, a document search tool, and a contract repository. The first run asks each system for everything related to the customer. It receives hundreds of fields, long message threads, duplicate attachments, and ticket histories stretching back years.

The agent is connected. It is also slower, more expensive, and less certain about which facts matter.

Adding tools expands what an agent can reach. It does not ensure that the agent can select the right capability, retrieve a bounded result, or preserve enough execution budget to finish the task.

A tool schema competes for attention before it is called

The model needs enough information to distinguish one tool from another. Twenty broad tools with overlapping descriptions create a routing problem. If each schema includes many optional fields and several modes, the model must infer which combination represents the intended action.

Compare two interfaces:

manage_account can search, update, assign, add a note, change a stage, or create a task depending on optional parameters.

get_renewal_record accepts a customer identifier and returns a defined renewal view with source timestamps.

The first interface appears more powerful. The second is easier to select, validate, permission, test, and recover. Narrow tools can increase the number of orchestration steps, but they reduce the ambiguity carried by each step.

This is the work behind Fabria: designing and validating the tools and multi-system workflows an agent needs, including their inputs, outputs, failure behavior, and authorized role.

Response shape matters as much as connectivity

A CRM endpoint may return 180 fields when the workflow needs eight. An email search may return complete message bodies when subject, sender, date, and a short extract would identify the relevant thread. A document tool may embed the same attachment once for every message that references it.

Every unnecessary value has a cost. It consumes tokens if placed in model context, storage and transfer if kept outside it, and reasoning attention if the agent must filter it.

The better pattern is task-shaped retrieval:

• select fields required by the decision;
• page until the completeness condition is met;
• preserve stable identifiers and timestamps;
• deduplicate before model use;
• retrieve full content only for selected records; and
• keep raw evidence available without injecting it all into the prompt.

These choices belong in the connector and orchestration design. Prompting the model to “be concise” does not repair an oversized payload.

MCP standardizes exchange, not business meaning

The Model Context Protocol gives systems a common way to expose tools and context. It does not decide whether a tool returns the current policy, whether a write is safe to retry, or whether two records refer to the same customer.

Connector availability and context quality are different properties. A tool can expose the correct system and still return the wrong slice of it. Teams should measure the resulting latency, token use, failure rate, and answer completeness against their own workflow rather than infer quality from the number of connected endpoints.

Pagination and retries create hidden failure paths

The agent asks for all open support tickets. The first page contains fifty records and a continuation token. If the tool description does not state that pagination is required, the result looks complete but is not.

Write actions create a different risk. A CRM update times out after the server commits it. Retrying without an idempotency key may create a duplicate task or note. Refusing to retry may leave the workflow uncertain about the system state.

A production tool needs explicit failure semantics:

• Did the request fail before or after execution?
• Can it be retried safely?
• Is there a status lookup?
• What evidence identifies the committed action?
• Which errors require a person rather than another attempt?

These details rarely appear in an agent demo. They determine whether the system can be operated after the first partial failure.

Count completed outcomes, not connected tools

The Coryntas integrations approach begins with one outcome and maps the context, tools, permissions, actions, and evidence required to complete it. A connection outside that path may still be useful later. It does not improve the current agent merely by existing.

Reducing a tool set can feel restrictive. It may also leave an edge case unsupported until a new capability is designed. That is an honest constraint. A bounded agent that escalates an unsupported case is more dependable than a broadly connected agent that guesses its way through it.

The useful question is not how many systems the agent can call. It is whether each connection returns the right information or performs the right action under conditions the operating team can test.