Loading ToolBench
MCP Server for 2-way and 3-way PO matching, mismatch classification, and configurable tolerance rules
Five tools with complete JSON schemas and descriptions, but significant quality gaps. Tool names lack action verbs (two_way_match, three_way_match should be match_invoice_po, match_invoice_po_grn). Descriptions are adequate (100-150 chars) but lack WHEN/WHY guidance. Parameter descriptions are sparse or missing entirely. No output schemas documented. Error handling absent. Schemas present but incomplete, many nested object properties lack type definitions or descriptions. No tool annotations (readOnlyHint, destructiveHint). Composition is reasonable (each tool has one responsibility), but parameter naming inconsistencies (match_result vs match_results in same tool) invite LLM confusion.
Applies configurable tolerance rules to matching results, evaluating variances against defined thresholds and company profiles
Classifies mismatches in matching results, identifying exception types (quantity variance, price variance, missing items, etc.) and severity levels
Generates a summary report of batch matching results, including statistics on approved, flagged, and rejected invoices
Performs 3-way matching between an invoice, purchase order, and goods receipt note (GRN), comparing line items and calculating variances
Performs 2-way matching between an invoice and a purchase order, comparing line items and calculating variances
Tool names lack action verbs. 'two_way_match' and 'three_way_match' do not start with verbs (get_, create_, search_, etc.). Should be 'match_invoice_po' and 'match_invoice_po_grn' to clarify the action and objects involved.
Nested object properties lack type definitions and descriptions. In two_way_match, invoice.lines[].item_code, description, qty, unit_price have no type info. Same for purchase_order.lines. LLMs cannot infer structure or validate input.
No output schemas documented. Tools return results but LLMs have no visibility into response structure (fields, types, nesting). Prevents downstream tool chaining and forces LLMs to guess field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Parameter naming inconsistency in apply_tolerance_rules and classify_mismatches: both accept 'match_result' (singular) AND 'match_results' (plural) in the same tool. LLMs will be confused about which to use and may pass both, causing ambiguous behavior.
No error handling guidance. Tools have no documented error cases, recovery steps, or actionable error messages. If tolerance_percent is invalid or config_path does not exist, LLMs have no guidance on what to do next.