MandatePay
Enables execution of authorized payments through Adyen's payment processing platform via a sandbox adapter, allowing the MCP server to interface with Adyen's payment rails (planned).
Enables execution of authorized payments through Stripe's payment processing platform via a sandbox adapter, allowing the MCP server to interface with Stripe's payment rails (planned).
Click on "Install 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., "@MandatePayauthorize €299 payment to software vendor in Germany"
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.
MandatePay
The authorization firewall for agentic payments
Identity · Intent · Policy · Human approval · Cryptographic proof
Autonomous agents can propose payments. They should not receive unlimited financial authority. MandatePay verifies every machine-initiated payment against a signed human mandate before execution.
Why this exists
Agentic commerce introduces a new control problem: how can a payment provider prove that an AI agent acted within authority delegated by a human or organization? Traditional checkout assumes a person is present. API keys establish application access, but not purpose, limits, geography, merchant scope, or the exact boundary of delegated intent.
MandatePay is a research-grade control plane that sits between agents and payment rails. It does not hold or move funds.
Related MCP server: dingdawg-agent-wallet
What makes it different
Signed mandates: authority is machine-verifiable and tamper-evident.
Policy-as-code: deterministic limits for value, total spend, currency, country, merchant, purpose, expiry, and velocity.
Human challenge: higher-risk intents pause for approval bound to the exact payment.
Agent identity binding: a mandate cannot be reused by a different agent.
Replay safety: idempotency keys return the original decision.
Verifiable events: every decision enters a hash-chained journal.
MCP tool: agents can request authorization through a constrained tool interface.
Fail closed: invalid signatures, malformed money, expired authority, and scope escape are denied.
Authorization lifecycle
sequenceDiagram
participant H as Human / Organization
participant A as AI Agent
participant M as MandatePay
participant P as Payment Provider
H->>M: Sign bounded mandate
A->>M: Submit payment intent
M->>M: Verify identity + signature + policy + state
alt within authority
M-->>A: Single-use authorization
A->>P: Execute with authorization proof
else approval threshold
M-->>H: Challenge exact intent
else policy violation
M-->>A: Deny with reason codes
end
M->>M: Append decision to audit chainQuick start
git clone https://github.com/muhammadashir0/mandatepay.git
cd mandatepay
python -m unittest discover -s tests -v
python app.pyOpen http://localhost:8080.
Try four scenarios in the console:
€299 / software / DE→ authorize€400 / software / DE→ human challenge€900 / software / DE→ deny: payment limit€100 / travel / GB→ deny: purpose and country
Use a fresh idempotency key when changing a scenario.
MCP server
python -m mandatepay.mcp_serverThe zero-dependency JSON-RPC server exposes one deliberately narrow tool: request_payment_authorization. The tool returns a decision, not money movement.
Threat model
MandatePay is designed around:
stolen or over-privileged agent credentials;
prompt injection causing unintended purchases;
mandate tampering and scope escalation;
duplicate execution and replay;
velocity abuse and cumulative overspend;
ambiguous human approval;
incomplete forensic evidence.
See docs/THREAT_MODEL.md for trust boundaries, non-goals, and production controls.
Repository architecture
mandatepay/
├── mandatepay/
│ ├── core.py # signed mandate + deterministic policy engine
│ ├── store.py # state, idempotency, tamper-evident journal
│ └── mcp_server.py # constrained MCP-compatible tool server
├── web/index.html # premium operator console
├── tests/ # policy and adversarial scenarios
├── docs/ # protocol, threat model, product direction
└── app.py # sandbox HTTP APIEvaluation, not just a demo
The tests verify authorization, approval challenges, identity mismatch, scope escape, velocity limits, and signed-mandate tampering. The next benchmark layer will measure false authorizations, false denials, replay resistance, policy coverage, decision latency, and approval burden across adversarial scenarios.
Roadmap
Ed25519/JWS production signing and key rotation
OAuth-attested agent identity and workload identity
Approval ceremony bound to intent hash
Single-use authorization tokens for payment providers
Durable SQL ledger with concurrency guarantees
OpenTelemetry decision traces and signed audit export
Adversarial evaluation corpus for agent-payment attacks
Stripe/Adyen sandbox adapter behind an execution interface
Multi-currency decimal and FX policy
Responsible-use boundary
This repository is a security and FinTech research MVP using synthetic identities and no real funds. HMAC is used only to keep the demonstration dependency-free. Production deployment requires reviewed asymmetric cryptography, hardened identity, durable transactional storage, authentication and authorization, regulatory analysis, privacy controls, independent security testing, and payment-provider certification.
Strategic context
Agentic payment systems need mandate-based authorization, separation between decision and execution, agent identity, programmable controls, audit trails, and tiered human oversight. MandatePay turns those design requirements into an inspectable open-source prototype.
License
Apache License 2.0.
Available Tools
1 toolrequest_payment_authorizationA
Evaluate a proposed agent payment against a signed spending mandate. Does not move funds.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| purpose | Yes | ||
| currency | Yes | ||
| merchant_id | Yes | ||
| merchant_country | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The explicit statement 'Does not move funds' is a critical side-effect disclosure that prevents accidental fund transfers. However, it does not describe the output nature (e.g., approval/denial) or any other side effects, leaving some behavioral gaps. The core non-effect is well covered, so a 4 is appropriate.
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 two concise sentences, leading with the core purpose and then a critical safety note. There is no wasted wording, and the most important information (the scrutiny and non-movement) is front-loaded. This is an exemplary level of conciseness.
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?
The description is too brief for a tool with five required parameters and no output schema. It omits the return value (e.g., whether the authorization is granted or denied), any prerequisites like having the mandate document, and does not clarify the 'purpose' field's semantics. An agent lacks critical information to interpret the tool's result and handle errors effectively, making it incomplete.
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?
The schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not describe any of the five fields (amount, currency, merchant_id, merchant_country, purpose). The context of a 'proposed agent payment' hints at their role but provides no additional meaning beyond the schema's field names, which is insufficient for a tool with no inline descriptions.
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 uses a specific verb ('Evaluate') and a clear resource ('proposed agent payment against a signed spending mandate'), and explicitly states it does not move funds, which distinguishes it from payment execution tools. Even without siblings, the purpose is precise and unambiguous, leaving no doubt about what the tool does.
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 description clearly implies the use case: evaluating a payment proposal against a mandate before funds are moved. It does not explicitly state when not to use it or mention alternatives, but the context is strong enough that an agent understands when to invoke it. Since no siblings are present, the lack of exclusions is acceptable.
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. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
request_payment_authorization
TDQS
With only one tool, there is no possibility of confusion or overlap between tools. The tool's purpose is clearly defined and singular.
A single tool follows a consistent verb_noun pattern ('request_payment_authorization'), which is clear and descriptive. No inconsistencies exist by definition.
The server has only one tool, which feels thin for a system named 'MandatePay'—implying broader mandate management. While the tool itself is well-scoped, the overall surface is borderline minimal.
The tool covers only payment authorization, but the domain suggests the need for related operations like mandate creation, listing, updating, or checking status. Without these, agents face significant dead ends when managing mandates.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Pre-spend firewall for AI agents. Approves, blocks, flags transactions against policy rules.
Agent payments, API key vaulting, and governed mandates. Agents spend within user-defined limits.
Advisory policy preflight for AI-agent spend requests; never executes payments or accesses wallets.
Deterministic allow/require_approval/deny verdicts for agent actions, before they happen.
Related MCP Servers
AlicenseAqualityCmaintenanceEnables AI agents to make payments with strict spending limits enforced by signed mandates, preventing unauthorized fund movement beyond predefined caps and allowlists.416MIT- FlicenseNot gradedqualityDmaintenanceProvides MCP tools to enforce spend policies (allow, deny, step-up, allowlist) on agent wallets with an immutable audit trail.-
- AlicenseNot gradedqualityDmaintenanceEnables verification of AI agent identity, authority, and integrity at transaction time, returning signed verdicts for allow, step-up, review, or block.MIT
- AlicenseNot gradedqualityAmaintenanceDeterministic, auditable payment policy enforcement for AI agents. It provides pre-action authorization with scopes, budgets, allowlists, and signed mandates via an MCP server.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/muhammadashir0/mandatepay'
If you have feedback or need assistance with the MCP directory API, please join our Discord server