Model Context Protocol
Eight tools. None of them lets an agent decide a payment.
The Paygente MCP server lets an agent look up its context, propose a payment, and buy a sandbox resource. Everything that authorises, executes or withdraws authority is reserved for Paygente and for people, and is not reachable from this surface.
MCP/WebMCP is the agent interaction layer. Paygente remains the authorization and control layer. When an agent buys a sandbox resource, the policy engine decides; a payment happens only on the simulated rail, only when policy allowed it or a person approved it, and exactly once. No real money moves, this is not x402, and no payment credential is exposed to the agent.
Available tools
list_agents
agent:readRead onlyThe agents registered in the organization, with their status and assigned policy.
Returns Agent name, external identifier, status, and whether a policy is attached.
list_approved_recipients
recipient:readRead onlyRecipients that are verified, active and available to be paid. Recipients an agent cannot use are not returned at all.
Returns Display name, identifier, supported assets, risk classification.
observe_spend_request
spend_intent:submitRecords the answerAsks what the policy WOULD decide about a purchase. Nothing is paid, ordered or reserved, and no one is asked to approve anything - the answer and the reasons behind it are recorded so a person can review them.
Returns The outcome the policy would have reached, every reason behind it, and a link to the recorded decision. Never a mandate: there is no path from this tool to an executed payment.
get_spend_request
mandate:readRead onlyReads back a spend request the agent made, and reports whether a person has since authorised it and what state that authorization is in. This is how an agent finds out what was decided about a request that needed a person.
Returns The request, the decision and its reasons, and the authorization a person created from it, if one exists — its id, its status and whether it is still waiting for an approver. Reporting that a person authorised something is not a way to make them: this tool changes nothing.
propose_payment
mandate:createCreates an authorizationCreates a mandate and evaluates it against the agent’s policy. This is the only tool that changes anything, and it never moves value.
Returns Mandate id, policy outcome, whether human approval is required, a plain-language explanation, and a link to the mandate in the sandbox.
get_mandate
mandate:readRead onlyThe current state of one mandate, including the decision and the reasons behind it.
Returns Status, amount, recipient, policy decision, approval state, execution state.
list_pending_approvals
mandate:readRead onlyMandates waiting for a person. Useful for an agent that needs to report why it is blocked.
Returns Mandate id, amount, recipient, how long it has been waiting.
buy_sandbox_resource
mandate:createPaid by Paygente in the sandbox, when allowedBuys one of the sandbox merchant’s resources, named by id and nothing else. Paygente evaluates the agent’s policy before anything is paid: ALLOW is paid by Paygente on the simulated rail, REQUIRE_APPROVAL waits for a person in the existing approval flow and is paid once when the agent asks again, and DENY is never paid. Sandbox only — no real money, not x402, and no payment credential ever reaches the agent. Served only where a deployment enables sandbox purchases; elsewhere the tool says so and nothing is paid.
Returns PAID, ALREADY_PAID, APPROVAL_REQUIRED, DENIED or NOT_PAID; the price; the decision and its reasons; the mandate; and the resource itself once it has been paid for.
Authorization boundary
An agent’s authority does not depend on who deployed it.
An agent acting through MCP receives a fixed permission set. It does not inherit the role of the person who registered it, so an agent deployed by an Owner has exactly the same authority as one deployed by an Operator - and neither can approve a payment.
An agent may
- Read the agents in its organization
- Read recipients it is permitted to pay
- Propose a payment for itself
- Buy a sandbox resource, paid only when policy allows or a person approves
- Read a mandate and its decision
- See what is waiting for a person
An agent may never
- Approve a mandate
- Reject a mandate
- Revoke a mandate
- Execute a payment
- Create or change a policy
- Change a recipient’s verification status or risk level
- Use the execution kill switch
- Read another organization’s data
This is not a matter of which tools the server chooses to expose. The agent permission set does not contain those permissions, and every operation in the platform checks it - through MCP, through the REST API and through the web application alike. A prompt injection that persuades an agent to try cannot succeed, because persuasion is not the mechanism by which authority is granted here.
Connecting
The server speaks MCP over stdio and reaches Paygente over HTTPS. It needs a hostname and a credential, and nothing else.
There is no database handle here and no organization to name. The key decides which organization and which agent this server acts for, and it decides it on our side — so a process running on your machine cannot claim to be an agent it is not. Issue one from your sandbox, under Agents.
{
"mcpServers": {
"paygente": {
"command": "npx",
"args": ["-y", "@paygente/mcp-server"],
"env": {
"PAYGENTE_API_URL": "https://api.paygente.com",
"PAYGENTE_AGENT_KEY": "key_....<secret>"
}
}
}
}Mandate mnd_01JQ8F7Z9K3M4N5P6Q7R8S9T0V
Status: WAITING FOR APPROVAL
Approval required: yes
Why:
€75.00 EURC is at or above the €40.00 EURC
threshold, so a person has to approve it.
A person must approve this payment before it can
be executed. Nothing has been paid, and you cannot
approve it yourself.
https://paygente.com/app/mandates/mnd_01JQ…Every MCP input is validated by the same schemas the REST API uses, and every proposal is decided by the same policy engine. There is no softer path into the system for an agent than for a person.