An assistant that checks inventory and prepares a support case needs access to those systems. A connection to an unrelated calendar adds another permission decision without helping that task.
There is no useful universal count. A focused assistant may need one business system. A workflow that checks inventory, creates a support case, and records an approval may need several. The relevant questions are which tools become available, what permissions they carry, and how the client handles their descriptions and results.
Inventory capabilities before adding integrations
List the actions in your workflow. Separate required reads, optional context, draft creation, and consequential writes. Map each action to an existing tool before adding another provider.
Two servers may expose similar searches with different scopes or freshness. The assistant needs enough information to choose the right one. Ambiguous descriptions create a design problem even when every server works individually.
Use names and descriptions that distinguish systems and actions. A tool that searches archived cases should say so. A tool that sends a message should make that effect clear before it is called.
Work through a connection map
Suppose the assistant needs to answer a delivery question and prepare a support case. The order system supplies order status. The delivery provider supplies shipment events. The support system stores the draft case. Those are separate capabilities, even if a single service exposes more than one of them.
Write each step beside its source of truth. Order status comes from the order record; a shipment event should retain its carrier timestamp; the case draft should identify the source information used. This helps the assistant avoid treating a copied note in the support system as the latest delivery event.
Now consider adding another server that searches all those systems. It could replace several steps, or it could duplicate them with less precise scope. Test whether it supplies the required freshness and identifiers before keeping both paths connected. The useful count follows from this mapping.
There is also a reason to separate capabilities: a read-only assistant may need shipment status without receiving the ability to cancel an order. Whether you can make that separation depends on the server's permissions and the client configuration. Count the authority you are granting alongside the connections.
Review permissions with the workflow
A connection can outlive the task that justified it. Review unused connections and the access attached to them. Revoking one connection may also require action in the upstream service; check the provider's procedure.
Be especially deliberate with tools that send, delete, purchase, or change permissions. Keep approval requirements close to the action and verify the enforcement mechanism. An instruction in a prompt is a request to the model, with different properties from a server-side refusal.
Check how your client loads tools
Clients may expose, search, or load tool descriptions differently. Do not assume that connecting a server always inserts its entire catalog into every model request. Equally, do not assume that deferred loading removes the need for clear descriptions and a bounded result.
Inspect the client's current documentation and observe the workflow you intend to run. Record tool-selection errors, unnecessary calls, and oversized results rather than claiming a fixed overhead per connection.
Our tool-catalog article discusses this operational concern. Any numerical claims there should be read in their original context; your client and workload need their own measurements.
Keep a connection list with an owner, purpose, granted scope, and last successful acceptance test. Remove a connection when nobody can explain which current task needs it.