retail-ops-mcp-kit

stage_invoice_payment

Stage a supplier invoice payment for human approval. Validates the invoice and amount, then creates a pending approval record for subsequent confirmation.

Instructions

STAGE (do not execute) a supplier-invoice payment for human approval.

- invoice_id: corpus invoice id, e.g. "INV-01".
- amount: payment amount; echoed into the staged payload for the human to confirm.
- currency: ISO code, default "USD".

Validates the invoice exists and the amount is numeric, then records a pending record
and returns {result:"pending_approval", approval_id, target_endpoint, ...}. Models SAP
API_JOURNALENTRYITEMBASIC_SRV vendor payment. THIS DOES NOT PAY ANYTHING — a human must
approve(approval_id, token) to execute. 'pay_invoice' is in policy.gated_actions, so
validation.policy_gated is true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "invoice_id": "<invoice_id>",
      "amount": "<amount>"
    },
    "name": "stage_invoice_payment"
  }
}

Input Schema

Name	Required	Default
`amount`	Yes
`currency`	No	USD
`invoice_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals that the tool validates invoice existence and numeric amount, records a pending record, returns a specific response structure, models an SAP API, does NOT pay anything, and requires human approval via approve(). It also notes the policy-gating of 'pay_invoice' in policy.gated_actions. This is exceptionally transparent.

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 description is front-loaded with the key message 'STAGE (do not execute)' and uses a clear bullet list for parameters. It is somewhat repetitive about the non-execution aspect (emphasized three times), but each sentence adds value—covering validation, return payload, SAP model, the approval workflow, and policy gating. It is dense but efficient, with minor redundancy keeping it from a 5.

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?

The description covers all essential aspects: parameter semantics, validation behavior, side effects (pending record), return payload shape, the required next step (approve), policy gating, and the underlying SAP model. It even notes the output schema implicitly by naming key response fields. This is complete for an agent to correctly select and invoke the tool.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully explain parameters. It does: invoice_id is a corpus invoice id with example 'INV-01', amount is echoed for human confirmation, currency is ISO with default 'USD'. This adds meaning well beyond the schema's type/title/default fields.

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 clearly states the tool's purpose: 'STAGE (do not execute) a supplier-invoice payment for human approval.' It uses a specific verb ('STAGE'), identifies the resource (supplier-invoice payment), and immediately clarifies a critical distinction—it does not execute payment—which differentiates it from sibling tools like 'approve' and 'stage_po_amendment'.

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

Usage Guidelines4/5

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

The description provides strong usage context: it explicitly says this tool does not pay anything, that human approval is required via approve(approval_id, token), and that the action is policy-gated. While it doesn't explicitly name alternative tools for comparison, it clearly places this tool in a staging workflow and tells the agent when not to use it (to actually pay), which is nearly complete guidance.

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

Deploy Server