presidio-hardened-x402-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PRESIDIO_X402_MCP_MODE | No | Mode: 'regex' (zero-setup) or 'nlp' (needs [nlp] extra + spaCy model). | regex |
| PRESIDIO_X402_CHAIN_KEY | No | 32-byte hex key for cross-process audit-chain HMAC. | unset (per-process) |
| PRESIDIO_X402_MCP_AGENT_ID | No | Label written into audit records. | unset |
| PRESIDIO_X402_MCP_LOG_LEVEL | No | Log level: DEBUG / INFO / WARNING / ERROR. | INFO |
| PRESIDIO_X402_MCP_REDIS_URL | No | Use Redis for replay state instead of in-memory. | unset |
| PRESIDIO_X402_MCP_AUDIT_PATH | No | Append-only JSON-L audit log path; omit to disable. | unset |
| PRESIDIO_X402_MCP_REPLAY_TTL | No | Fingerprint cache TTL (seconds). | 300 |
| PRESIDIO_X402_FINGERPRINT_KEY | No | 32-byte hex key for cross-process replay detection. | unset (per-process) |
| PRESIDIO_X402_REQUIRE_CHAIN_KEY | No | Fail startup if audit-chain key is absent or invalid. | unset |
| PRESIDIO_X402_MCP_REMOTE_API_KEY | No | API key for the remote screening service. | unset |
| PRESIDIO_X402_MCP_WINDOW_SECONDS | No | Rolling window for the daily limit. | 86400 |
| PRESIDIO_X402_MCP_DAILY_LIMIT_USD | No | Max USD per rolling window (policy gate). | unset |
| PRESIDIO_X402_MCP_REMOTE_BASE_URL | No | Enable HTTP-proxy mode for tool 1 — see Modes. | unset |
| PRESIDIO_X402_MCP_MAX_PER_CALL_USD | No | Max USD per single payment (policy gate). | unset |
| PRESIDIO_X402_MCP_PER_ENDPOINT_JSON | No | Per-endpoint cap, e.g. '{"api.foo.com": 5.00}'. | unset |
| PRESIDIO_X402_REQUIRE_FINGERPRINT_KEY | No | Fail startup if replay key is absent or invalid. | unset |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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:
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"). |
| check_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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.