Paygente
Sandbox

Model Context Protocol

Six tools. None of them can move money.

The Paygente MCP server lets an agent look up its context and propose a payment. Everything that authorises, executes or withdraws authority is reserved for people and is not reachable from this surface.

Available tools

  • list_agents

    agent:readRead only

    The 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 only

    Recipients 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:submitRead only

    Asks 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.

  • propose_payment

    mandate:createChanges state

    Creates 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 only

    The 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 only

    Mandates 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.

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
  • 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. Point your client at it and pass the agent it is acting as.

Client configuration
{
  "mcpServers": {
    "paygente": {
      "command": "node",
      "args": ["apps/mcp-server/dist/main.js"],
      "env": {
        "DATABASE_URL": "postgresql://…",
        "PAYGENTE_ENV": "local",
        "PAYGENTE_AGENT_EXTERNAL_ID": "research-agent",
        "PAYGENTE_ORGANIZATION_SLUG": "northstar-ai-labs"
      }
    }
  }
}
propose_payment — a typical answer
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.

Full documentation