Skip to main content
Glama

Supplier Payment Decision Agent (Ireland)

decide_supplier_payment

Flagship. Independent third-party decision for an Irish supplier invoice. Runs five gates (CRO status NORMAL, EU VIES VAT, payee-name and IBAN check, PO/GRN/invoice 3-way match, RSA signature) and returns exactly one of EXECUTE_PAYMENT, REJECT_PAYMENT or FLAG_FOR_HUMAN_REVIEW with per-check results, reason codes and a confidence score. The legacy CONFIRMATION_OF_PAYEE result means a payee-name comparison with the CRO legal name and IBAN validation, not bank Confirmation of Payee. ERP_THREE_WAY_MATCH compares caller-supplied documents, not independently verified ERP records. Decides only; never moves money. Register a signing key first via /v1/agent-keys. Use this for the complete signed invoice/PO/GRN workflow, not verify_supplier_payment's separate identity/VAT contract or get_verification retrieval. Provider uncertainty requires review, not execution; retain independent payment approval. Supply a stable transaction_id for retries and never automatically repay.

Input Schema

NameRequiredDescriptionDefault
payment_requestYesDecide: pay this supplier invoice or not: supply this structured object using the nested schema, not a JSON-encoded string.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • addedInput schema / $defs / LineItem / properties / quantity / description
      Added value: +"Positive ordered or invoiced quantity; send an exact decimal string."
    • addedInput schema / $defs / LineItem / properties / sku / description
      Added value: +"Item identifier used consistently across invoice, PO and receipt."
    • addedInput schema / $defs / LineItem / properties / unit_price / description
      Added value: +"Nonnegative unit price in the document currency; send an exact decimal string."
    • addedInput schema / $defs / PaymentRequest / properties / goods_receipt / description
      Added value: +"Caller-supplied goods receipt with quantities received against the same PO."
    • addedInput schema / $defs / PaymentRequest / properties / invoice / description
      Added value: +"Invoice being reviewed, including payee name, amount, currency, PO/GRN references and line items."
    • addedInput schema / $defs / PaymentRequest / properties / purchase_order / description
      Added value: +"Caller-supplied purchase order to compare with the invoice; no ERP lookup is performed."
    • addedInput schema / $defs / PaymentRequest / properties / signature / description
      Added value: +"RSA-PSS SHA-256 signature of the normalized canonical request without signature, using a previously registered public-key ID in the same tenant."
    • addedInput schema / $defs / PaymentRequest / properties / supplier / description
      Added value: +"Supplier CRO number, Irish VAT number and claimed payment IBAN for all five gates."
    • addedInput schema / $defs / PaymentRequest / properties / transaction_id / description
      Added value: +"Stable caller transaction identifier for the same business request. Reuse on retries; changed content with the same ID conflicts."
    • addedInput schema / $defs / Supplier / properties / cro_number / description
      Added value: +"Irish CRO company number for the invoice supplier; preserve it as a string."
    • addedInput schema / $defs / Supplier / properties / iban / description
      Added value: +"Supplier's claimed payment IBAN. Validation does not independently establish account ownership."
    • addedInput schema / $defs / Supplier / properties / vat_number / description
      Added value: +"Supplier Irish VAT number to validate and check against EU VIES, not a CRO number."
    • addedInput schema / properties / payment_request / description
      Added value: +"Decide: pay this supplier invoice or not: supply this structured object using the nested schema, not a JSON-encoded string."
  2. Changed13 schema fields changed
    • removedInput schema / $defs / LineItem / properties / quantity / description
      Removed value: -"Positive ordered or invoiced quantity; send an exact decimal string."
    • removedInput schema / $defs / LineItem / properties / sku / description
      Removed value: -"Item identifier used consistently across invoice, PO and receipt."
    • removedInput schema / $defs / LineItem / properties / unit_price / description
      Removed value: -"Nonnegative unit price in the document currency; send an exact decimal string."
    • removedInput schema / $defs / PaymentRequest / properties / goods_receipt / description
      Removed value: -"Caller-supplied goods receipt with quantities received against the same PO."
    • removedInput schema / $defs / PaymentRequest / properties / invoice / description
      Removed value: -"Invoice being reviewed, including payee name, amount, currency, PO/GRN references and line items."
    • removedInput schema / $defs / PaymentRequest / properties / purchase_order / description
      Removed value: -"Caller-supplied purchase order to compare with the invoice; no ERP lookup is performed."
    • removedInput schema / $defs / PaymentRequest / properties / signature / description
      Removed value: -"RSA-PSS SHA-256 signature of the normalized canonical request without signature, using a previously registered public-key ID in the same tenant."
    • removedInput schema / $defs / PaymentRequest / properties / supplier / description
      Removed value: -"Supplier CRO number, Irish VAT number and claimed payment IBAN for all five gates."
    • removedInput schema / $defs / PaymentRequest / properties / transaction_id / description
      Removed value: -"Stable caller transaction identifier for the same business request. Reuse on retries; changed content with the same ID conflicts."
    • removedInput schema / $defs / Supplier / properties / cro_number / description
      Removed value: -"Irish CRO company number for the invoice supplier; preserve it as a string."
    • removedInput schema / $defs / Supplier / properties / iban / description
      Removed value: -"Supplier's claimed payment IBAN. Validation does not independently establish account ownership."
    • removedInput schema / $defs / Supplier / properties / vat_number / description
      Removed value: -"Supplier Irish VAT number to validate and check against EU VIES, not a CRO number."
    • removedInput schema / properties / payment_request / description
      Removed value: -"Decide: pay this supplier invoice or not: supply this structured object using the nested schema, not a JSON-encoded string."
  3. Added
  4. Removed
  5. Changed13 schema fields changed
    • addedInput schema / $defs / LineItem / properties / quantity / description
      Added value: +"Positive ordered or invoiced quantity; send an exact decimal string."
    • addedInput schema / $defs / LineItem / properties / sku / description
      Added value: +"Item identifier used consistently across invoice, PO and receipt."
    • addedInput schema / $defs / LineItem / properties / unit_price / description
      Added value: +"Nonnegative unit price in the document currency; send an exact decimal string."
    • addedInput schema / $defs / PaymentRequest / properties / goods_receipt / description
      Added value: +"Caller-supplied goods receipt with quantities received against the same PO."
    • addedInput schema / $defs / PaymentRequest / properties / invoice / description
      Added value: +"Invoice being reviewed, including payee name, amount, currency, PO/GRN references and line items."
    • addedInput schema / $defs / PaymentRequest / properties / purchase_order / description
      Added value: +"Caller-supplied purchase order to compare with the invoice; no ERP lookup is performed."
    • addedInput schema / $defs / PaymentRequest / properties / signature / description
      Added value: +"RSA-PSS SHA-256 signature of the normalized canonical request without signature, using a previously registered public-key ID in the same tenant."
    • addedInput schema / $defs / PaymentRequest / properties / supplier / description
      Added value: +"Supplier CRO number, Irish VAT number and claimed payment IBAN for all five gates."
    • addedInput schema / $defs / PaymentRequest / properties / transaction_id / description
      Added value: +"Stable caller transaction identifier for the same business request. Reuse on retries; changed content with the same ID conflicts."
    • addedInput schema / $defs / Supplier / properties / cro_number / description
      Added value: +"Irish CRO company number for the invoice supplier; preserve it as a string."
    • addedInput schema / $defs / Supplier / properties / iban / description
      Added value: +"Supplier's claimed payment IBAN. Validation does not independently establish account ownership."
    • addedInput schema / $defs / Supplier / properties / vat_number / description
      Added value: +"Supplier Irish VAT number to validate and check against EU VIES, not a CRO number."
    • addedInput schema / properties / payment_request / description
      Added value: +"Decide: pay this supplier invoice or not: supply this structured object using the nested schema, not a JSON-encoded string."
  6. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does so: it states it decides only and never moves money, that retries require a stable transaction_id and must not trigger repayment, that it returns per-check results with reason codes and a confidence score, and that independent payment approval must be retained. It also proactively disambiguates two misleading result labels (CONFIRMATION_OF_PAYEE and ERP_THREE_WAY_MATCH) that an agent would otherwise misinterpret.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and outcome set are front-loaded, and nearly every sentence contributes a distinct constraint (gates, outcome enum, label caveats, key prerequisite, sibling routing, retry discipline). It is dense rather than padded, though the run-on sequence of caveats makes it a wall of text that could be split into clearer blocks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly compensates by describing the return shape (one of three verdicts, per-check results, reason codes, confidence score). Combined with the prerequisite, retry, and escalation guidance, an agent has everything needed to invoke and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single top-level parameter, so the baseline is 3. The description still adds real semantics the schema does not: transaction_id must be stable across retries and changed content under the same ID conflicts, and the signature requires a key registered beforehand. It stops short of detailing the nested supplier/invoice fields, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource (an independent third-party payment decision on an Irish supplier invoice) and enumerates the five gates it runs and the exact three outcomes it can return. It explicitly distinguishes itself from verify_supplier_payment and get_verification, so an agent can route between them without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the conditions for use (complete signed invoice/PO/GRN workflow), the prerequisite (register a signing key first via /v1/agent-keys), the alternatives to avoid (verify_supplier_payment's identity/VAT contract, get_verification retrieval), and the escalation rule (provider uncertainty requires review, not execution). Both when-to-use and when-not-to-use are explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources