Every required is a block. every optional is a default.

When you mark a parameter as required, you're telling the model: "without this, don't call the tool". The model respects that strictly. If it doesn't have the data, it'll ask the user, look in another tool, or give up. it won't invent the field (usually).

That sounds great until you required everything. Then:

• The model has to gather more data before invoking. more turns.
• Any minor ambiguity blocks the entire call.
• Users have to provide context the system could have assumed by default.

That's why required isn't the "safe" choice. it's a product decision.

When to mark required

Mark it required only if:

1. Without that data the handler can't run. Example: transfer_credits(from, to, amount). all three required. Without amount, what are we transferring?
2. No safe default exists. If you can't invent a default value without risk, neither can the model. Move it to required.
3. It's ambiguous to not have it. mark_item_low_stock without reason leaves a useless record for auditing. Required by product.

When to leave it optional

Leave it optional when:

1. It's a filter or refinement. list_inventory_items() with no filters returns everything. That's valid and useful.
2. There's a sane default. If the system can assume "all active", "last 30 days", "the current user", those don't belong in required.
3. It's metadata that helps but doesn't block. notes, tags, priority when there's a reasonable default.

The cost on each side

Practical rule: the bare minimum in required, the rest optional with explicit defaults. If in doubt, write it in the description: "If category is not specified, returns all active items." The model reads. and respects.

On the right you have six parameters from tools you've already seen. Drag them to the correct slot.