Design MCP tool definitions an agent can actually use correctly

You are designing the tool definitions for a new MCP server, before any implementation code gets written. Your job is to write tool names, descriptions, and parameter schemas the way an LLM actually reads and selects between them — not the way a human-facing API reference would document the same operations.

SERVER PURPOSE
An MCP server exposing a subset of the internal order-management system to AI agents for customer-support use cases

CANDIDATE OPERATIONS
look up an order by ID, look up all orders for a customer email, check whether an order is eligible for a refund, issue a refund up to a preset limit

TOOL DEFINITION RULES
- Name each tool by what it does and returns, not by the underlying implementation — get_order_status, not a name describing the table it happens to query. An LLM selects a tool primarily from its name and description at the moment of deciding what to call, and a name that describes an internal detail instead of an outcome makes correct tool selection harder for no benefit to anyone.
- Write the description to state exactly when to call this tool versus a similar one, not just what it does in isolation. If the candidate operations contain two that could plausibly be confused, the description of each must say the specific thing that distinguishes it — don't rely on the name alone to disambiguate.
- Every parameter needs a description stating its expected format and any constraints, following verb_noun snake_case, matching the rest of the internal API's naming so tool names read consistently with existing docs. An LLM given an untyped-feeling "id" parameter with no format guidance will guess a plausible-looking format that may not match what the server actually expects, and that mismatch fails at execution time with an error the model then has to interpret and recover from.
- State what each tool returns on success, including the shape of the response, and what it returns on a common, expected failure such as not-found or permission-denied versus an unexpected error — a tool that only documents its happy path leaves the calling agent unable to distinguish "this doesn't exist" from "something broke," which leads to different correct next actions.

DISAMBIGUATION PASS
For every pair of tools whose descriptions overlap even slightly, write one sentence stating exactly which one a caller should pick and why, as if answering the question an agent would actually face mid-task. If you can't write that sentence clearly, the two tools are not adequately distinguished yet — merge them or sharpen the descriptions until you can.

SCOPE AND SIDE EFFECTS
For every tool, state explicitly whether it's read-only or has a side effect that writes data, sends something, or costs money — this needs to be visible in the tool's description itself, not just in the server-side implementation, since refunds under $50 can be issued directly; anything above requires a separate human-approval tool, not a parameter on issue_refund only matters if the agent can actually tell from the tool definition alone whether a call is reversible.

OUTPUT FORMAT
For each tool: name, one-sentence purpose stating when to use it over any similar tool, full parameter list with types/formats/constraints, return shape on success, and return shape on the 2-3 most likely failure modes.