The two tools target clearly different actions on different resources: one reads PO lines for a supplier, the other performs a three-way match on a single invoice. There is no realistic way to confuse them, and the descriptions reinforce the boundary (read-only listing vs. decision-returning validation).

Both names follow a snake_case verb_noun convention (list_..., check_...) that reads naturally and consistently. The only minor deviation is that list_open_purchase_orders stacks multiple qualifiers while check_invoice is terse, but the pattern is still predictable.

Two tools is thin even for a narrowly scoped three-way match server; the whole workflow lives in a single check_invoice call with one supporting lookup. It is functional and focused, but borderline under-provisioned for a stated accounts-payable domain.

The core path (fetch PO lines with ordered/received quantities, then match an invoice) is covered, and the register flag gives basic duplicate handling. However there is no way to look up a previously registered invoice, list invoices for a supplier, inspect prior decisions, or re-check a HOLD after correction, leaving notable gaps in the lifecycle.