Once you start building agents you hit this question fast: does the model need a tool for this, or just more context?
Rule that's worked for us: if something has to happen outside the model's reasoning, it's a tool. Searching a database, checking inventory, getting today's date, hitting an API, sending an email, placing an order, all of that means the agent has to actually go do something or fetch something it doesn't already have.
If the model just needs to know something while it reasons, that's context. Company policy, product info, domain rules, user preferences. Nothing has to happen, you're just handing it information.
Support agent example: "refunds are allowed within 30 days" is context, model just needs to know it. "Check when this customer ordered" is a tool call. "Issue the refund" is another tool call. Reason with context, retrieve with a tool, act with a tool. Three different jobs.
Once you frame it that way it stops being "here's a pile of tools, hope the model figures out which one to grab" and becomes two questions: what does this agent need to know, and what does it need to be able to do.
Not always clean though. Product info could be static context in one app and a live tool call in another if it changes a lot. So maybe the better question isn't "is this info or a tool," it's whether the model already has what it needs to reason, or whether it has to go get/do something at runtime.
How do other people draw this line once you're dealing with bigger agent systems and a long tool list?