A tool definition looks like an API endpoint with a description attached. The difference is who walks through it — a model that will be shown text written by other people: user input, web content, an email quoting an order ID.
Four questions decide how much that matters.
Scope. What can this tool reach? query_database() can read anything, which makes it a liability. get_order_status(order_id) can reach exactly one thing.
Blast radius. Read or write, reversible or not? Fetching a status is cheap to get wrong. Cancelling an order needs a human in the loop.
Identity. Whose permissions apply? A tool running on service credentials runs with full access for every user who triggers it. Scoped to the caller's own permissions, it can only reach what that person could already reach.
Idempotency. The model may call more than once. create_order(item_id) duplicates; add an idempotency key and a second call is safe.
Then there is the description itself, which does more work than it looks like. The model reads it as instruction, so a vague one produces confident misuse. "Search and get customer data" invites exactly that. "Get order status by order_id only. Do not access other data" closes the door behind it.
The question was never what the tool can do. It's what happens when it's called by someone we didn't anticipate.