proofrelay.review_wire_payoff_changeReview hash-only wire, payoff, or disbursement change metadata for red flags and required controls without approving funds movement.
| Name | Required | Description | Default |
|---|---|---|---|
| wire_change | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / wire_change / additionalPropertiesAdded value: +falseInput schema / properties / wire_change / properties / approval_hashes / items / patternAdded value: +"^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$"Input schema / properties / wire_change / properties / callback_evidence_hash / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "pattern": "^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / wire_change / properties / change_request_hash / patternAdded value: +"^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$"Input schema / properties / wire_change / properties / new_instruction_hash / patternAdded value: +"^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$"Input schema / properties / wire_change / properties / original_instruction_hash / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "pattern": "^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / wire_change / properties / payoff_statement_hash / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "pattern": "^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / wire_change / properties / requester_hash / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "pattern": "^\\s*(?:sha256:)?[0-9a-fA-F]{64}\\s*$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defsRemoved value: -{
- "WirePayoffChangeInput": {
- "description": "Hash-only wire or payoff change evidence input.",
- "properties": {
- "approval_hashes": {
- "description": "Approval or escalation hashes.",
- "items": {
- "type": "string"
- },
- "title": "Approval Hashes",
- "type": "array"
- },
- "callback_evidence_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional callback or out-of-band verification hash.",
- "title": "Callback Evidence Hash"
- },
- "change_request_hash": {
- "description": "SHA-256 change request hash.",
- "title": "Change Request Hash",
- "type": "string"
- },
- "change_type": {
- "description": "Change category under review.",
- "enum": [
- "wire_instruction",
- "payoff_statement",
- "disbursement_instruction",
- "other"
- ],
- "title": "Change Type",
- "type": "string"
- },
- "new_instruction_hash": {
- "description": "SHA-256 new instruction hash.",
- "title": "New Instruction Hash",
- "type": "string"
- },
- "observed_red_flags": {
- "description": "Public-safe red flag reason codes.",
- "items": {
- "type": "string"
- },
- "title": "Observed Red Flags",
- "type": "array"
- },
- "original_instruction_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional original instruction hash.",
- "title": "Original Instruction Hash"
- },
- "payoff_statement_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional payoff statement hash.",
- "title": "Payoff Statement Hash"
- },
- "requester_hash": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional requester hash.",
- "title": "Requester Hash"
- }
- },
- "required": [
- "change_type",
- "change_request_hash",
- "new_instruction_hash"
- ],
- "title": "WirePayoffChangeInput",
- "type": "object"
- }
-}Input schema / properties / wire_change / $refRemoved value: -"#/$defs/WirePayoffChangeInput"Input schema / properties / wire_change / propertiesAdded value: +{
+ "approval_hashes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "callback_evidence_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "change_request_hash": {
+ "type": "string"
+ },
+ "change_type": {
+ "enum": [
+ "wire_instruction",
+ "payoff_statement",
+ "disbursement_instruction",
+ "other"
+ ],
+ "type": "string"
+ },
+ "new_instruction_hash": {
+ "type": "string"
+ },
+ "observed_red_flags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "original_instruction_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "payoff_statement_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "requester_hash": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+}Input schema / properties / wire_change / requiredAdded value: +[
+ "change_type",
+ "change_request_hash",
+ "new_instruction_hash"
+]Input schema / properties / wire_change / typeAdded value: +"object"Input schema / titleRemoved value: -"review_wire_payoff_changeArguments"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds meaningful context: it operates on hashes only (privacy-preserving, no raw wire details) and does not approve funds movement. It omits any note on rate limits or what a review result contains, but the output schema covers returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the action and resource and closes with the most decision-relevant constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema covering return values, the description supplies the key framing an agent needs (hash-only, review-not-approve). The remaining gap is the undocumented nested input fields, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is a nested object with nine fields, so the schema itself explains none of them. The description only loosely gestures at the fields via 'red flags' and 'required controls,' leaving hashes like change_request_hash or callback_evidence_hash unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Review), a specific resource (hash-only wire/payoff/disbursement change metadata), and a scope boundary (without approving funds movement). This clearly distinguishes it from siblings like review_vendor_risk_profile or verify_bundle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without approving funds movement' implies the boundary of what this tool does, but the description never states when to use this versus siblings or what preconditions apply. Usage is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.