presidio-hardened-x402-mcp
A pre-payment safety gate MCP server exposing three tools that let an agent check x402 payment metadata and spend rules before signing — catching PII leakage, budget overruns, and duplicate payments.
screen_payment_metadata(resource_url, description?, reason?, entities?)— detect and redact PII (emails, phones, SSNs, names, …) in the resource URL, description, and reason fields; returns redacted strings plus per-fieldentities_foundcounts. Read-only, no side effects, safe to call repeatedly. Field caps: URL ≤ 2048, others ≤ 4096 chars.check_payment_policy(resource_url, amount_usd)— spending-policy gate against per-call, rolling-window daily, and per-endpoint USD limits (set via env vars); returns{allowed: true}or{allowed: false, reason, limit_usd, amount_usd}. Records the spend on success — call exactly once, right before paying.check_payment_replay(resource_url, pay_to, amount, currency, deadline_seconds)— duplicate-payment gate using an HMAC-SHA256 fingerprint of the canonical fields; returns{is_replay, fingerprint}. Records the fingerprint on success — call exactly once, right before paying.amountis a string to preserve precision.Two modes — in-process (default: local library, no network/API key/quota, PII never leaves the host) or HTTP-proxy for
screen_payment_metadatawhenPRESIDIO_X402_MCP_REMOTE_BASE_URL+..._REMOTE_API_KEYare set (POSTs to/v1/screen, never silently falls back; returns structuredauth_error/rate_limit/unavailable). Tools 2 and 3 always stay in-process.Cross-process state — replay fingerprints and audit-chain HMACs can be shared via
PRESIDIO_X402_FINGERPRINT_KEY/PRESIDIO_X402_CHAIN_KEY(optionally Redis); otherwise each process keeps an ephemeral in-memory store (replay TTL default 300s).Auditing — optional append-only JSON-L audit log via
PRESIDIO_X402_MCP_AUDIT_PATH, with agent labelling viaPRESIDIO_X402_MCP_AGENT_ID.Composability — designed to slot into an agent's pre-sign flow alongside endpoint-safety (x402station
preflight) and payment-execution servers: preflight → screen → policy → replay → pay. Note the gates only screen the 402 challenge metadata and spend; they never see an agent-invented POST request body, so an unscreened/guessed body stays outside their scope.
Provides pre-payment safety gates (PII redaction, spending policy, replay detection) for x402 agentic payments, designed to compose with Coinbase x402 payment execution MCP server.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@presidio-hardened-x402-mcpScreen payment metadata for PII before signing the invoice."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
presidio-hardened-x402-mcp
Pre-payment safety gate for x402 — agents call screen_payment_metadata(...), check_payment_policy(...), and check_payment_replay(...) before signing, catching PII, budget overruns, and duplicate payments before metadata or money leaves the agent host.
Part of the presidio-hardened-* toolkit family. Thin MCP (Model Context Protocol) adapter over the presidio-hardened-x402 library, pinned to parent 0.13.x (presidio-hardened-x402>=0.13.0,<0.14.0). 0.13.0 is the first parent that can record a control as NOT_EVALUATED, which signed decision evidence needs; it also includes the 0.11.1 fix for the percent-encoded PII redaction bypass, which remains a security floor.
Why this exists
x402 agentic payments routinely carry user-supplied free text — descriptions, memos, query-string parameters — straight through to merchants and facilitators. When an LLM agent generates that text, it can include PII the user never intended to share. Once the merchant logs it, retention is their decision, not yours.
This MCP server gives agents a small default-deny gate before payment leaves the agent host. Three tools expose the parent library's stable pre-payment controls: PII redaction, spending policy, and replay detection. Since 0.3.0 each decision can also be emitted as a signed payment-decision@1 record that a third party verifies offline (see Signed decision evidence). The tools are designed to compose with payment-execution and endpoint-safety MCP servers (x402station, Coinbase x402, Sardis, ...), while other parent-library surfaces — evidence-ref@1 verification of inbound evidence, the v0.9.1 SLO broker, the v0.10.0 settlement-ref@1 treasury binding, and the v0.11.0 CapabilityEnforcer — stay in the Python library unless an MCP tool explicitly wraps them later.
Related MCP server: pulsefeed-x402-mcp
Install & configure
Requires Python ≥ 3.10. Distributed on PyPI; recommended invocation via uvx (no global install).
Claude Desktop / Claude Code
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on your platform:
{
"mcpServers": {
"presidio-x402": {
"command": "uvx",
"args": ["presidio-hardened-x402-mcp"]
}
}
}Cursor / Windsurf / Continue
Same shape — every MCP host accepts command / args / env. See your editor's MCP-server docs for the config-file path.
Environment variables
All optional. Defaults give a zero-config in-process mode with no quota, no network, and no PII storage.
Variable | Purpose | Default |
|
|
|
| Max USD per single payment (policy gate) | unset → no limit |
| Max USD per rolling window (policy gate) | unset → no limit |
| Per-endpoint cap, e.g. | unset |
| Rolling window for the daily limit |
|
| Label written into audit records | unset |
| Fingerprint cache TTL (seconds) |
|
| Use Redis for replay state instead of in-memory | unset |
| Append-only JSON-L audit log path; omit to disable | unset |
|
|
|
| Enable HTTP-proxy mode for tool 1 — see Modes. Must be | unset |
| API key for the remote screening service | unset |
| 32-byte hex key for cross-process replay detection | unset (per-process) |
| 32-byte hex key for cross-process audit-chain HMAC | unset (per-process) |
| Fail startup if replay key is absent or invalid | unset |
| Fail startup if audit-chain key is absent or invalid | unset |
| File holding the decision-signing key (preferred; wins over the env key) | unset |
| Decision-signing key (the parent library's variable): Ed25519 private key as 64 hex chars, or an HMAC secret | unset |
| Append-only JSON-L file for signed | unset |
|
|
|
| Signer identity; the trust-store key verifiers look up |
|
| Optional key id written into each record (for rotation) | unset |
| Fail startup unless signed evidence is fully configured and the key signs | unset |
Generate cross-process keys with openssl rand -hex 32.
Tools
screen_payment_metadata(resource_url, description, reason, entities?)
Detects and redacts PII in payment metadata. No side effects — safe to call repeatedly.
// Input
{
"resource_url": "https://api.foo.com/u/jane@example.com",
"description": "monthly fee for jane@example.com",
"reason": ""
}
// Output
{
"redacted_resource_url": "https://api.foo.com/u/<EMAIL_ADDRESS>",
"redacted_description": "monthly fee for <EMAIL_ADDRESS>",
"redacted_reason": "",
"entities_found": [
{ "entity_type": "EMAIL_ADDRESS", "field": "resource_url", "count": 1 },
{ "entity_type": "EMAIL_ADDRESS", "field": "description", "count": 1 }
],
"mode": "in_process"
// + "decision_ref": "<64 hex>" when signed decision evidence is enabled
}entities (optional list of Presidio entity types) narrows detection to a whitelist. Field-length caps mirror the screening-api wire contract that remains stable through parent 0.7.x: resource_url ≤ 2048, description ≤ 4096, reason ≤ 4096 characters. Oversized inputs raise ValueError.
check_payment_policy(resource_url, amount_usd, prior_decision_refs?)
Spending-policy gate. Records the spend on success — call exactly once, immediately before payment. Skipping the actual payment after a successful check inflates the daily-limit ledger until the window rolls over.
The URL is screened first and only the redacted URL reaches the policy engine, so no raw URL lands in the parent's logs. Per-endpoint limits match on that redacted URL; keep PII out of configured endpoint prefixes. If screening fails, the gate denies without recording spend.
// Input
{ "resource_url": "https://api.foo.com/x", "amount_usd": 1.50 }
// Output (allowed)
{ "allowed": true }
// Output (denied — over per-call limit of $5.00)
{ "allowed": false, "reason": "...", "limit_usd": 5.00, "amount_usd": 6.00 }With signed evidence enabled, both outputs also carry decision_ref. prior_decision_refs (optional, up to 8) links refs this server returned earlier for the same payment — typically the one from screen_payment_metadata — into the signed record; a ref this process did not issue is refused before any spend is recorded.
check_payment_replay(resource_url, pay_to, amount, currency, deadline_seconds, prior_decision_refs?)
Duplicate-payment gate via HMAC-SHA256 fingerprint of the canonical fields. Records the fingerprint on success — call exactly once, immediately before payment.
amount is a string to preserve precision. Cross-process detection requires PRESIDIO_X402_FINGERPRINT_KEY (and optionally PRESIDIO_X402_MCP_REDIS_URL); otherwise each MCP server process keeps its own in-memory store.
// Input
{
"resource_url": "https://api.foo.com/x",
"pay_to": "0xabc...",
"amount": "1.50",
"currency": "USDC",
"deadline_seconds": 1700000000
}
// Output (first seen)
{ "is_replay": false, "fingerprint": "29aaf60f..." }
// Output (duplicate within TTL)
{ "is_replay": true, "fingerprint": "29aaf60f..." }decision_ref and prior_decision_refs behave as for check_payment_policy.
Signed decision evidence
The audit log (PRESIDIO_X402_MCP_AUDIT_PATH) is HMAC-chained: tamper-evident to whoever holds PRESIDIO_X402_CHAIN_KEY, and to nobody else. From 0.3.0 every tool decision — allow and block alike — can also be written as a signed payment-decision@1 record, built and signed by the parent library (build_payment_decision_content, build_decision_evidence) and checked by anyone with the public key (verify_decision_ref). The audit log is still written; the records go alongside it, never instead of it.
# One-time: an Ed25519 key pair for the signer (hex private key, 0600).
python - <<'PY'
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat
sk = Ed25519PrivateKey.generate()
open("evidence.key", "w").write(sk.private_bytes_raw().hex())
print(sk.public_key().public_bytes(Encoding.Raw, PublicFormat.Raw).hex()) # -> trust store
PY
chmod 600 evidence.key"env": {
"PRESIDIO_X402_MCP_EVIDENCE_KEY_FILE": "/etc/presidio/evidence.key",
"PRESIDIO_X402_MCP_DECISION_PATH": "/var/log/presidio/x402-mcp-decisions.jsonl",
"PRESIDIO_X402_MCP_REQUIRE_EVIDENCE_KEY": "1"
}Verify offline with the parent's CLI against a trust store that pins the public key under the signer name:
echo '{"presidio-hardened-x402-mcp": {"alg": "ed25519", "public_key": "<public hex>"}}' > trust.json
python -m presidio_x402.decision_ref /var/log/presidio/x402-mcp-decisions.jsonl trust.jsonWithout a key the server behaves exactly as 0.2.x — audit log only — and logs one WARNING at startup saying signed evidence is disabled. A key without PRESIDIO_X402_MCP_DECISION_PATH, an unreadable key file, or a key the signer rejects is logged at ERROR and also leaves evidence off. Set PRESIDIO_X402_MCP_REQUIRE_EVIDENCE_KEY=1 to refuse to start in any of those cases instead. Once running, a failed write is logged and the gate's answer stands: a record of a decision never reverses the decision.
What a record says. payment-decision@1 always carries all five controls (pii → trusted_wallet → policy → replay → mpa). Each record holds real verdicts only for what its tool ran and NOT_EVALUATED for the rest: every tool screens the URL (pii), check_payment_policy adds policy, check_payment_replay adds replay; trusted_wallet and mpa are never evaluated here. NOT_EVALUATED never fails a decision and never claims a pass, so the controls block alone says which gate decided. Chain the three with prior_decision_refs to get one linked set per payment.
What it never contains. Raw resource_url, description, or reason; only the URL's scheme and host, the entity-type labels found, and hashes (policy snapshot, replay fingerprint, payment details). The gates see PII in the URL they are handed but pay it unchanged, so their PII verdict is PII_WARNED; screen_payment_metadata returns redacted strings and records PII_REDACTED. Fields an MCP tool never sees — payer wallet, network, the raw 402 offer — are recorded as unspecified / not-presented. The records carry no capability-chain parents, so the ADR-0002 top-level parents field is never set.
Modes
In-process (default). Wraps the local presidio-hardened-x402 library in the same process as the MCP server. No network, no API key, no quota. PII never leaves the agent host. Use this unless you have a specific reason not to.
HTTP-proxy. When both PRESIDIO_X402_MCP_REMOTE_BASE_URL and PRESIDIO_X402_MCP_REMOTE_API_KEY are set, screen_payment_metadata calls /v1/screen on the configured host (e.g. https://screen.presidio-group.eu) for centralized audit. On auth / quota / network failure, returns a structured { "error": "auth_error" | "rate_limit" | "unavailable", "detail": ..., "mode": "remote" } — never silently falls back to in-process. Tools 2 and 3 always stay in-process.
Composability
Designed to slot into agent flows alongside payment-execution and endpoint-safety MCP servers:
agent intent: pay https://api.foo.com/x with 1.50 USDC
│
├─ x402station preflight(url) ← is the ENDPOINT safe? (decoys, dead, traps)
│
├─ presidio-x402 screen_payment_metadata ← is the PAYLOAD safe? (PII)
├─ presidio-x402 check_payment_policy ← within budget?
├─ presidio-x402 check_payment_replay ← not a duplicate?
│
└─ pay()screen_payment_metadata is read-only and safe to interleave anywhere. The policy and replay gates record state on call — sequence them immediately before payment.
What none of these gates can see: a request body the agent made up. The three tools screen the 402 challenge's metadata and the spend; they never see the body the agent sends to a POST route. Independent measurement of the x402 and MPP catalogues (probe402, MCRI #001, 1 September 2026) found 1,521 of 8,056 listed POST routes — 18.9% — publish no usable request example, and 72% of those still return a payable quote at the wall. A route like that is listed, priced, and not machine-executable from the published contract. An agent that fills the gap by synthesising a body is guessing, and a guessed body is where user data enters the request unscreened. Posture: if the catalogue entry carries no request example or schema, stop at the 402 quote and surface it; do not invent a body to get past the wall. Put that rule in the agent's instructions — it is a decision the agent makes before any of these tools run.
Combined snippet: preflight → screen → pay
Endpoint-safety and payload-safety are independent signals — calling both is what you actually want before signing. Configure the two MCP servers side-by-side:
{
"mcpServers": {
"x402station": { "command": "npx", "args": ["-y", "x402station-mcp"],
"env": { "AGENT_PRIVATE_KEY": "0x…" } },
"presidio-x402": { "command": "uvx", "args": ["presidio-hardened-x402-mcp"] }
}
}Agent flow before signing a payment (pseudocode — each step is one MCP tool call):
# 1. endpoint safety: is the URL trustworthy? (x402station-mcp)
pf = preflight(url)
if not pf["ok"]:
abort(reason=pf["warnings"]) # decoy / zombie / dead / price-trap
# 2. payload safety: redact PII before it leaves the host (presidio-x402)
s = screen_payment_metadata(resource_url=url, description=description, reason="")
url, description = s["redacted_resource_url"], s["redacted_description"]
# 3. spend gates: record-on-success, call exactly once each (presidio-x402)
if not check_payment_policy(url, amount_usd)["allowed"]:
abort(reason="policy")
if check_payment_replay(url, pay_to, amount, currency, deadline_seconds)["is_replay"]:
abort(reason="replay")
# 4. sign + pay
pay(url, amount, description=description)The two servers are developed independently, on purpose — keeping the signals uncorrelated is the point. See x402station-mcp for the preflight tool's full output schema and warning catalog.
Notes for developers
Logs go to stderr (MCP clients capture stderr). stdout is reserved for JSON-RPC frames.
The package is a thin adapter. All security logic lives in
presidio-hardened-x402— read its docs for the entity-type catalog, policy semantics, evidence-ref verification, SLO broker, and audit-chain details.This MCP release exposes the same three tools as
0.1.1. 0.3.0 adds signedpayment-decision@1emission from those tools and an optionalprior_decision_refsargument on the two gates; the rest of the parent SLO/evidence/capability surface is not promoted into MCP.When testing via
mcp-inspector --cli, bare numeric--tool-arg amount=1.50is auto-coerced to a float and rejected by the schema. Real MCP clients send proper JSON types; the tool'samountargument is a string to preserve precision.Local dev:
uv venv && uv pip install -e ".[dev]" && pytest tests/.
License
MIT. See LICENSE.
Links
This repo: https://github.com/presidio-v/presidio-hardened-x402-mcp
Issues: https://github.com/presidio-v/presidio-hardened-x402-mcp/issues
Parent library: https://github.com/presidio-v/presidio-hardened-x402
Library on PyPI: https://pypi.org/project/presidio-hardened-x402/
Requirements: PRESIDIO-REQ.md
Security policy: SECURITY.md
MCP spec: https://modelcontextprotocol.io
x402: https://x402.org
SDLC
This repository is on the open-source baseline of the PRESIDIO hardened-family SDLC (report · PDF). The controls measured for it, and any open gaps, are its row in the applicability matrix.
Roadmap (next 12 months)
Now / in flight — OpenSSF Best Practices silver and a Scorecard above 7: governance docs, a real CodeQL job alongside Bandit, least-privilege workflow tokens, and Atheris fuzzing of the configuration validators. Closing the remaining findings in
SECURITY-AUDIT.md.Next — hash-pinned CI dependencies, ideally as a family-wide change rather than in this repo alone.
Later (under evaluation) — signed releases with build provenance; tracking the MCP specification as it stabilises; exposing the parent library's
capability-grant@1enforcement as a fourth tool, if agent demand justifies the added surface.
Governance, Architecture, Security
Governance — roles, decision process, and how to become a maintainer.
Architecture — components, trust boundaries, and the core processing path.
Assurance case — the security claims and the evidence backing each one.
Security policy — supported versions and how to report a vulnerability.
Contributing — review bar, test policy, and verification commands.
Stability guarantees — what counts as the public API and what may not change.
Available Tools
3 toolscheck_payment_policyA
Check whether a payment is allowed by the configured spending policy.
WARNING: this records the spend against rolling time-window ledgers. Call exactly once, immediately before submitting the payment. If you call this and then do not pay, the spend window will be inflated until it rolls over.
Configure limits at server startup via PRESIDIO_X402_MCP_* env vars.
Args: resource_url: x402 resource URL being paid. Screened first; only the redacted URL reaches the policy engine (per-endpoint limits match on it, so keep PII out of configured endpoint prefixes). amount_usd: Payment amount in USD-equivalent. prior_decision_refs: Optional decision_ref values this server returned earlier for the same payment (e.g. from screen_payment_metadata); linked into the signed record. Max 8.
Returns: {"allowed": true} on success, or {"allowed": false, "reason": str, "limit_usd": float, "amount_usd": float}; plus decision_ref when signed decision evidence is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_usd | Yes | ||
| resource_url | Yes | ||
| prior_decision_refs | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that the call mutates rolling spend ledgers, warns about window inflation if no payment follows, explains the URL redaction/screening behavior, and states configuration via env vars and optional signed decision evidence.
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?
The warning and the core rule are front-loaded, and the Args/Returns structure is easy to scan. It is somewhat long, but nearly every line conveys operationally relevant behavior for a side-effecting tool.
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?
Given no annotations, a 3-parameter mutation-style check, and an output schema, the description covers the critical side effect, safe-call timing, parameter meanings, and return shapes. Nothing essential for correct invocation is missing.
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%, but the description supplies meaning for every parameter: resource_url is screened and redacted before policy matching, amount_usd is USD-equivalent, and prior_decision_refs are optional decision_ref values from earlier server responses, capped at 8.
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?
The description states a specific verb and object: checking whether a payment is allowed by the configured spending policy. It is clearly a policy-evaluation tool, though it does not explicitly distinguish itself from the sibling check_payment_replay beyond the shared payment-checking context.
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?
It gives an explicit operational rule: call exactly once, immediately before submitting the payment, and warns what happens if the payment is not then made. It also points to screen_payment_metadata as the source of prior_decision_refs, so the agent knows where that input comes from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_payment_replayA
Check whether this exact payment has been seen recently (replay protection).
WARNING: this records the fingerprint. Call exactly once, immediately before submitting the payment.
Cross-process detection requires PRESIDIO_X402_FINGERPRINT_KEY (and optionally PRESIDIO_X402_MCP_REDIS_URL); otherwise each MCP server process has its own ephemeral in-memory store.
Args: resource_url: x402 resource URL. pay_to: Recipient address. amount: Amount as string (preserves precision). currency: Currency symbol (e.g. "USDC"). deadline_seconds: Payment deadline as epoch seconds. prior_decision_refs: Optional decision_ref values this server returned earlier for the same payment; linked into the signed record. Max 8.
Returns: {"is_replay": false, "fingerprint": ""} on first seen, or {"is_replay": true, "fingerprint": ""} on duplicate; plus decision_ref when signed decision evidence is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| pay_to | Yes | ||
| currency | Yes | ||
| resource_url | Yes | ||
| deadline_seconds | Yes | ||
| prior_decision_refs | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden and does so: it warns that the call has a recording side effect, explains cross-process behavior depends on PRESIDIO_X402_FINGERPRINT_KEY / PRESIDIO_X402_MCP_REDIS_URL, and states the fallback is a per-process ephemeral store. It also documents both return shapes, which is genuinely beyond structured data.
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?
Front-loaded with the purpose, then the timing warning, then Args/Returns—a sensible reading order. The cross-process paragraph is dense but earns its place; overall sizing is appropriate for a tool with a mutation side effect and a config dependency.
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?
An output schema exists, so the Returns summary is a convenience rather than a requirement, and the args section plus the fingerprint-store caveat cover what an agent needs. Nothing material about invocation risk or environment prerequisites is missing.
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%, so the Args block is doing all the work and it does cover all six parameters, adding useful hints like amount being a string to preserve precision and prior_decision_refs capping at 8. Some entries (resource_url, pay_to) are terse restatements rather than semantic clarification, keeping it below a 5.
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 and resource: checking whether an exact payment has been seen before, framed as replay protection. That is clearly distinct from screening metadata or checking policy, though the description never names the sibling tools to route explicitly.
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?
"Call exactly once, immediately before submitting the payment" gives an unusually precise usage constraint and sequencing rule. It stops short of naming when to prefer a sibling tool (screen_payment_metadata, check_payment_policy), so alternatives are left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_payment_metadataA
Screen x402 payment metadata for PII before signing the payment.
Call BEFORE sending the payment request. Detects emails, phone numbers, SSNs, names, and other PII in the resource URL, description, and reason fields and returns redacted strings plus per-field entity counts.
No side effects.
Runs in one of two modes:
in_process (default): wraps the local presidio_x402 PIIFilter.
remote: when both PRESIDIO_X402_MCP_REMOTE_BASE_URL and ..._REMOTE_API_KEY are set, POSTs to /v1/screen on that host for centralized audit. On remote failure, returns a structured error dict instead of silently falling back — the caller must decide whether to retry, accept reduced screening, or abort.
Args: resource_url: x402 resource URL the agent is about to pay (max 2048 chars). description: Human-readable description (max 4096 chars). reason: Reason / memo string (max 4096 chars). entities: Optional whitelist of Presidio entity types to detect. If None, all configured entities are scanned.
Returns: On success: dict with keys redacted_resource_url, redacted_description, redacted_reason, entities_found (list of {entity_type, field, count}), and mode (one of "in_process", "remote"); plus decision_ref when signed decision evidence is enabled (pass it to the gates as prior_decision_refs). On remote failure: dict with keys error (one of "auth_error", "rate_limit", "unavailable"), detail, optional retry_after (for rate_limit), and mode ("remote").
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| entities | No | ||
| description | No | ||
| resource_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well. It discloses no side effects, the two execution modes, remote-mode environment-variable requirements, and the important behavior that remote failures return structured errors instead of silently falling back.
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?
The description is front-loaded with the purpose and timing, then proceeds through modes, args, and returns. Despite its length, each section adds information that matters for correct invocation, especially given the empty schema descriptions.
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?
For a complex screening tool with no annotations and 0% schema description coverage, the description supplies the missing operational context. It covers purpose, timing, modes, parameters, success returns, failure returns, and decision_ref handling.
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%, so the description must explain all four parameters, and it does. It documents resource_url, description, reason, the entities whitelist, and the meaning of entities=None as scanning all configured entities.
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?
The description states a specific verb and resource: screen x402 payment metadata for PII before signing. It clearly scopes the operation to resource URL, description, and reason fields. It does not explicitly differentiate itself from the sibling payment-policy and replay checks, so it stops short of a 5.
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 timing instruction is explicit: call BEFORE sending the payment request. That gives the agent a clear point at which to use the tool. It does not mention when not to use it or how it relates to check_payment_policy and check_payment_replay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.3.0- Changed
check_payment_policy1 field changed- added
Input schema / properties / prior_decision_refsAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Prior Decision Refs" +}
- Changed
check_payment_replay1 field changed- added
Input schema / properties / prior_decision_refsAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Prior Decision Refs" +}
3 tool updates
v0.1.2- First observed
check_payment_policy - First observed
check_payment_replay - First observed
screen_payment_metadata
TDQS
Scored across 3 tools
Each tool targets a distinct pre-payment concern: PII screening, spending-policy authorization, and replay detection. Their inputs overlap, but the roles are complementary and clearly separated by purpose and description.
All names use snake_case and follow a predictable verb_payment_<object> pattern. The slight verb variation (screen vs. check) reflects genuinely different actions while remaining consistent.
Three tools fit a focused pre-payment hardening pipeline, with each tool earning its place. There is no filler or redundant surface for this narrow scope.
The set covers the core safety checks: PII screening, policy limits, and replay protection. Minor gaps exist around inspecting configured policy limits or releasing recorded spend/fingerprints when a payment is not completed, though the warnings document these operational constraints.
Maintenance
Related MCP Connectors
x402 payment security and pre-execution transaction risk screening for autonomous AI agents.
x402 payment verification: safe-to-pay preflight, on-chain receipt proof, OFAC/scam wallet screen
Pre-execution safety layer for autonomous agent wallets via MCP and x402.
Authorize x402 payments before signing with request-bound, signed safety decisions.
Related MCP Servers
- AlicenseAqualityAmaintenanceThis tool library gives AI agents a discovery and "know before you pay" layer to find and check the historic reputation of endpoints in the x402 ecosystem.415203 npm1MIT
- AlicenseAqualityBmaintenanceBefore an AI agent pays an x402 endpoint, checks whether it's safe to pay: liveness, scam/anomaly scan (payTo hijack, bait-and-switch, honeypot), and on-chain receiver verification. ~70% of x402 endpoints are dead or scams.3MIT
- AlicenseAqualityDmaintenanceMCP server for assessing counterparty risk in x402 payments using on-chain data, providing risk scores, decisions, and wallet spending policies to prevent fraud and unauthorized payments.10132 npm1MIT

TWZRD Agent Intelofficial
AlicenseNot gradedqualityBmaintenancePre-spend trust layer for agents paying over x402 on Solana, providing seller vetting and readiness checks before USDC leaves the wallet.MIT