When an integration demo is moving quickly, a single tool that accepts a URL, a query, or a large JSON object feels convenient. The agent can call it for almost anything. That convenience is exactly why the tool becomes difficult to secure. A model that is confused, manipulated, or simply overconfident now has a very large action surface.

Describe the job, not the whole system

Prefer create_support_draft over call_any_api. Prefer find_open_orders_for_customer over a raw database query. A narrow tool gives the application a chance to validate the fields, destination, tenant, and allowed state transition before anything happens.

Good tool design also helps the agent. A clear name, small input, predictable result, and useful error message leave less room for the model to guess. If a tool can return twenty unrelated kinds of data, the agent has to infer the meaning and the permission boundary every time.

Keep the dangerous choices outside the model

Resolve tenant identity and credentials on the server. Allowlist outbound destinations. Set limits for records, amounts, payload size, and batch operations. Separate reading, drafting, sending, approving, and deleting into different capabilities. A prompt telling the model to use a tool responsibly is helpful guidance, but it is not an access-control system.

Test the failure path

Try malformed arguments, an unexpected URL, a record from another tenant, a revoked permission, a timeout, and a repeated request. The safe result is not always an error page; sometimes it is a clear request for more information or a hand-off to a person. The smaller the tool, the easier it is to know what the agent was allowed to do and what needs to be fixed.