x402-data-gateway

Evaluate Stateful Wallet Policy Conformance

stateful_wallet_policy_conformance

Evaluate safe standardized observations from wallet policies that track prior or concurrent requests. Use wallet_policy_conformance instead for one-request action shape, method, chain, token, recipient, amount, and function controls. This tool separately tests sequential cumulative limits, signed-but-unbroadcast accounting, ABI extraction, concurrent oversubscription, counter-reference failure, and application serialization. It accepts no credentials, counter values, wallet or resource IDs, signatures, transactions, or raw provider responses and does not run the provider tests itself. Payment challenge and credentials are bound to POST https://agents.samedaydesk.com/security/stateful-wallet-policy-conformance, not mcp://. Retry the identical authorized arguments and credential.

Input Schema

Name	Required	Description
`network`	Yes	Network identifier used by the tested stateful profile.
`protocol`	Yes	Payment or execution protocol bound by the tested stateful profile.
`provider`	Yes	Wallet or delegated-signer provider name.
`profileId`	Yes	Caller-defined stateful policy profile identifier with no credential, wallet, or counter secret.
`observations`	Yes	Unique standardized stateful observations. Raw provider responses, signatures, transactions, counter values, credentials, wallet IDs, and resource IDs are rejected.

Output Schema

Name	Required	Description	Default
`product`	Yes
`profile`	Yes
`results`	Yes
`boundary`	Yes
`complete`	Yes
`decision`	Yes
`evaluatedAt`	Yes
`unsafeCases`	Yes
`schemaVersion`	Yes
`inconclusiveCases`	Yes
`strictBudgetPassed`	Yes
`applicationVerified`	Yes
`missingRequiredCases`	Yes
`standardSchemaVersion`	Yes
`providerNativeVerified`	Yes
`providerNativeUnverified`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "applicationVerified": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "boundary": {
+      "additionalProperties": false,
+      "properties": {
+        "credentialsAccepted": {
+          "const": false,
+          "type": "boolean"
+        },
+        "signaturesVerified": {
+          "const": false,
+          "type": "boolean"
+        },
+        "statement": {
+          "type": "string"
+        },
+        "transactionBroadcast": {
+          "const": false,
+          "type": "boolean"
+        },
+        "walletAccessed": {
+          "const": false,
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "credentialsAccepted",
+        "walletAccessed",
+        "signaturesVerified",
+        "transactionBroadcast",
+        "statement"
+      ],
+      "type": "object"
+    },
+    "complete": {
+      "type": "boolean"
+    },
+    "decision": {
+      "enum": [
+        "conformant",
+        "partial",
+        "unsafe"
+      ],
+      "type": "string"
+    },
+    "evaluatedAt": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "inconclusiveCases": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "missingRequiredCases": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "product": {
+      "const": "samedaydesk-stateful-wallet-policy-conformance",
+      "type": "string"
+    },
+    "profile": {
+      "additionalProperties": false,
+      "properties": {
+        "network": {
+          "type": "string"
+        },
+        "profileId": {
+          "type": "string"
+        },
+        "protocol": {
+          "type": "string"
+        },
+        "provider": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "profileId",
+        "provider",
+        "network",
+        "protocol"
+      ],
+      "type": "object"
+    },
+    "providerNativeUnverified": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "providerNativeVerified": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "actual": {
+            "enum": [
+              "allowed",
+              "denied",
+              "error"
+            ],
+            "type": "string"
+          },
+          "applicationVerified": {
+            "type": "boolean"
+          },
+          "case": {
+            "enum": [
+              "first_within_cap",
+              "sequential_exceeds_cap",
+              "signed_unbroadcast_counts",
+              "unrecognized_calldata",
+              "concurrent_exceeds_cap",
+              "missing_counter_reference",
+              "application_serialized_concurrent_exceeds_cap"
+            ],
+            "type": "string"
+          },
+          "code": {
+            "pattern": "^[A-Za-z0-9][A-Za-z0-9._:/-]{0,63}$",
+            "type": "string"
+          },
+          "control": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "enforcementClass": {
+            "enum": [
+              "none",
+              "policy",
+              "application",
+              "validation",
+              "provider"
+            ],
+            "type": "string"
+          },
+          "expectationMet": {
+            "type": "boolean"
+          },
+          "expected": {
+            "enum": [
+              "allow",
+              "deny"
+            ],
+            "type": "string"
+          },
+          "finding": {
+            "enum": [
+              "expected_behavior",
+              "unsafe_allowed",
+              "expected_behavior_not_proven",
+              "denied_outside_policy_or_application_guard"
+            ],
+            "type": "string"
+          },
+          "providerNativeVerified": {
+            "type": "boolean"
+          },
+          "required": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "case",
+          "actual",
+          "enforcementClass",
+          "expected",
+          "control",
+          "required",
+          "expectationMet",
+          "providerNativeVerified",
+          "applicationVerified",
+          "finding"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "schemaVersion": {
+      "const": "samedaydesk.stateful-wallet-policy-conformance.v1",
+      "type": "string"
+    },
+    "standardSchemaVersion": {
+      "const": "agent-payment-policy.stateful-wallet-policy-observation-report.v1",
+      "type": "string"
+    },
+    "strictBudgetPassed": {
+      "type": "boolean"
+    },
+    "unsafeCases": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "standardSchemaVersion",
+    "product",
+    "evaluatedAt",
+    "profile",
+    "decision",
+    "complete",
+    "strictBudgetPassed",
+    "results",
+    "providerNativeVerified",
+    "providerNativeUnverified",
+    "applicationVerified",
+    "missingRequiredCases",
+    "unsafeCases",
+    "inconclusiveCases",
+    "boundary"
+  ],
+  "type": "object"
+}

AddedAug 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it discloses that no credentials, counter values, wallet/resource IDs, signatures, transactions, or raw provider responses are accepted, that the tool does not run provider tests itself, and that payment challenge/credentials are bound to a specific POST URL rather than mcp://. It lacks a clear statement of traditional auth requirements or rate limits, keeping it below 5.

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

Conciseness3/5

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

The core scope statement is front-loaded, which is good. However the description runs to five dense sentences with some redundancy and tangential clauses (the payment-challenge/URL binding sentence reads as operational boilerplate), making it heavier than necessary for the information conveyed.

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

Completeness4/5

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

The tool is complex and has an output schema, so return values need not be explained. With 100% schema coverage plus stated purpose, alternative routing, rejection constraints, and auth binding, an agent has nearly everything needed to call it correctly; only explicit auth/rate-limit expectations are missing.

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 all five parameters (profileId, provider, network, protocol, observations) including nested enum semantics. The description reinforces the rejection constraints but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb (Evaluate) and resource (standardized observations from stateful wallet policies) and explicitly distinguishes the scope from the stateless sibling wallet_policy_conformance. It enumerates the stateful scenarios tested (sequential cumulative limits, signed-but-unbroadcast accounting, concurrency, counter-reference failure, serialization). The phrase 'safe standardized observations' is somewhat abstract but the overall purpose is discernible.

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?

It explicitly names the alternative ('Use wallet_policy_conformance instead for one-request action shape...') and gives the condition that selects it, which is exactly the routing an agent needs. It does not spell out further when-not-to-use conditions, but the primary alternative routing is clear.

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

All x402-data-gateway 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.