NAIF Agent Gravity — MCP Diagnostics & Recovery

Verify Repair Payment

verify_repair

Idempotent

Use after the buyer completes the payment action for a checkout created by prepare_repair. APPLE_PAY verifies the existing Tap charge by checkoutId; BASE_USDC and TRON_USDT require the payer-provided txHash. A confirmed payment returns verified=true, while an already-confirmed Apple Pay checkout may return alreadyVerified=true; an unconfirmed or rejected payment returns error and/or reason without fabricating success. Verification may also return the job attached by the existing payment-completion workflow. This tool never creates or sends a transaction and never charges the buyer.

Input Schema

TableJSON Schema

Name	Required	Description
`rail`	Yes	Use the same payment rail selected in prepare_repair.
`txHash`	No	Payer-provided transaction hash. Required for BASE_USDC and TRON_USDT after transfer submission; omit for APPLE_PAY.
`checkoutId`	Yes	Exact checkout ID returned by prepare_repair.

Output Schema

TableJSON Schema

Name	Required	Description
`job`	No	Existing repair job attached by the payment-completion workflow when available; may be null.
`rail`	No	Payment rail checked.
`error`	No	Present when payment is missing, unavailable, invalid or could not be verified.
`phase`	No	VERIFY when the verification route returned a structured result.
`state`	No	Payment/checkout state when returned; PAYMENT_VERIFIED denotes a confirmed payment.
`reason`	No	Verification evidence or rejection reason when returned by a wallet rail.
`verified`	No	True only when the provider/chain evidence confirms the expected payment for this checkout.
`paymentId`	No	Recorded verified payment identifier when available.
`checkoutId`	No	Checkout identifier that was verified.
`alreadyVerified`	No	True when an APPLE_PAY checkout had already been verified previously.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 5, 2026

addedInput schema / properties / checkoutId / description

Added value: +"Exact checkout ID returned by prepare_repair."

addedInput schema / properties / rail / description

Added value: +"Use the same payment rail selected in prepare_repair."

changedInput schema / properties / txHash / description

Previous value: -"Required for wallet rails; omit for APPLE_PAY."New value: +"Payer-provided transaction hash. Required for BASE_USDC and TRON_USDT after transfer submission; omit for APPLE_PAY."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Verification status for an existing checkout payment. Treat verified=true or alreadyVerified=true as confirmed; otherwise inspect error/reason/state and do not assume payment success.",
+  "properties": {
+    "alreadyVerified": {
+      "description": "True when an APPLE_PAY checkout had already been verified previously.",
+      "type": "boolean"
+    },
+    "checkoutId": {
+      "description": "Checkout identifier that was verified.",
+      "type": "string"
+    },
+    "error": {
+      "description": "Present when payment is missing, unavailable, invalid or could not be verified.",
+      "type": "string"
+    },
+    "job": {
+      "description": "Existing repair job attached by the payment-completion workflow when available; may be null."
+    },
+    "paymentId": {
+      "description": "Recorded verified payment identifier when available.",
+      "type": "string"
+    },
+    "phase": {
+      "description": "VERIFY when the verification route returned a structured result.",
+      "type": "string"
+    },
+    "rail": {
+      "description": "Payment rail checked.",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Verification evidence or rejection reason when returned by a wallet rail.",
+      "type": "string"
+    },
+    "state": {
+      "description": "Payment/checkout state when returned; PAYMENT_VERIFIED denotes a confirmed payment.",
+      "type": "string"
+    },
+    "verified": {
+      "description": "True only when the provider/chain evidence confirms the expected payment for this checkout.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedOct 5, 2026

changedInput schema / properties / rail / enum

Previous value: -[
-  "BASE_USDC",
-  "TRON_USDT"
-]New value: +[
+  "APPLE_PAY",
+  "BASE_USDC",
+  "TRON_USDT"
+]

addedInput schema / properties / txHash / description

Added value: +"Required for wallet rails; omit for APPLE_PAY."

changedInput schema / required

Previous value: -[
-  "checkoutId",
-  "rail",
-  "txHash"
-]New value: +[
+  "checkoutId",
+  "rail"
+]

AddedOct 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond annotations: outcome semantics (verified=true, alreadyVerified=true for repeat Apple Pay checks, error/reason on unconfirmed or rejected payment with no fabricated success), the possibility of a returned job, and an explicit non-mutation guarantee ('never creates or sends a transaction and never charges the buyer'). This is consistent with and enriches idempotentHint=true and destructiveHint=false.

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?

Front-loads the trigger and the non-mutation guarantee, with dense but purposeful sentences and no filler. It is slightly packed into long compound clauses, which costs a bit of scannability.

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?

Covers the three-rail branching, the prerequisite tool, and the success/failure/already-verified outcome space; an output schema exists, so return-shape detail is not required. Essentially everything an agent needs to call this correctly is present.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents rail, txHash (including the omit-for-APPLE_PAY rule), and checkoutId. The description's rail-specific restatement confirms intent but adds no syntax or format detail beyond the schema — baseline 3 is appropriate.

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?

States a specific verb (verify) and resource (a repair payment for a checkout), and explicitly anchors it to the sibling prepare_repair as the creating step. An agent can distinguish this from prepare_repair/quote_repair without opening schemas.

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?

Gives a clear trigger: 'Use after the buyer completes the payment action for a checkout created by prepare_repair,' plus per-rail usage (APPLE_PAY uses checkoutId, BASE_USDC/TRON_USDT need txHash). It does not state when to avoid calling or what to do if prepare_repair was never run, so it falls short of full when/when-not guidance.

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

All NAIF Agent Gravity — MCP Diagnostics & Recovery tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.