Paybond MCP Server
About
Tenant-bound MCP tools for agent spend authorization, evidence, receipts, and settlement in Cursor, Codex, and Claude Code.
Details
- Author
- Unknown
- Categories
- Finance, Other, AI, Knowledge Base
Jump to
An MCP host hands your agent tools that can charge real money. A per-transaction cap does not help much: twelve $399 tool calls under a $500 cap still clear $4,788, because each approval has no memory of the last — and a cleared charge is not proof the work happened.
Paybond ships a tenant-bound MCP server that closes that gap. It binds delegated spend to a signed intent, releases or refunds against submitted completion evidence, and returns a receipt finance can replay — while preserving the same tenant boundary as the SDKs and APIs. Use it for internal agent runtimes and orchestration systems that prefer MCP over custom HTTP wrappers.
First-class adapter surface.MCP hosts are a supported framework integration path alongside in-process adapters — seeAgent middleware,Coding-agent setup, and theKit support matrix.
For coding-agent setup, including Codex and generic stdio MCP snippets usingnpx -y -p @paybond/kit paybond-mcp-server, start withCoding-agent setup.
For a first guardrail integration outside MCP, start with the sandbox scaffold:
npx -p @paybond/kit paybond-init \ --preset paid-tool-guard \ --framework provider-agnostic \ --out paybond-paid-tool-guard.ts paybond-kit-init \ --preset paid-tool-guard \ --framework provider-agnostic \ --out paybond_paid_tool_guard.py npx -p @paybond/kit paybond-init \ --preset paid-tool-guard \ --framework provider-agnostic \ --out paybond-paid-tool-guard.ts paybond-kit-init \ --preset paid-tool-guard \ --framework provider-agnostic \ --out paybond_paid_tool_guard.py
For MCP-native hosts, the matching sandbox tools arepaybond_bootstrap_sandbox_guardrailandpaybond_submit_sandbox_guardrail_evidence.
The server is stdio-first by default — most desktop hosts launch it as a local child process. Hosts that need a network URL instead can use the hosted Streamable HTTP endpoint or self-host the same HTTP transport; seeRemote HTTP (Streamable HTTP)below.
Paybond does not assume a specific model provider or agent framework. The only assumption is that your host can speak MCP tool calls, either over stdio or Streamable HTTP.
import { createPaybondMcpToolSurface } from "@paybond/mcp";
- Equivalent subpath on the core package: @paybond/kit/mcp — use @paybond/kit when you need multiple adapters in one app.
- For stdio MCP hosts, launch npx -y -p @paybond/kit paybond-mcp-server — see Coding-agent setup in the docs.
- Python: paybond agent demo mcp smoke requires the optional mcp extra. Use pip install "paybond-kit[mcp]", pipx install 'paybond-kit[mcp]', or pipx inject paybond-kit mcp (when base paybond-kit is already installed).
- Smoke: paybond agent demo mcp smoke --operation paid-tool --requested-spend-cents 100 --evidence-preset cost_and_completion --format json (in-process MCP).
Always required. For sandbox setup, use one of the login CLIs first:
npx -p @paybond/kit paybond login paybond-kit-login npx -p @paybond/kit paybond login paybond-kit-login
The CLIs writePAYBOND_API_KEYto.env.local; the packaged MCP servers load.env.localby default whenPAYBOND_API_KEYis not already present. SetPAYBOND_ENV_FILEfor a different local secrets file, or passPAYBOND_API_KEYin the MCP host launch environment. Production keys are created in Console and stored in deployment secret managers.
Restricted MCP keys (recommended for hosts)
For Cursor, Claude Desktop, Codex, and other MCP hosts, prefer arestrictedkey (paybond_rk_) over a standard service-account key (paybond_sk_). Restricted keys carry an explicit MCP scope grant;tools/listandtools/callexpose only the tools those scopes unlock, and the gateway enforces the same scopes on the underlying routes. Standard keys keep role-based RBAC and optionalPAYBOND_MCP_TOOL_POLICYfor local dev.
Create one from Console (Machine access → API keys → Restricted MCP key) or the CLI:
paybond keys create \ --name cursor-discovery \ --role analyst \ --kind restricted \ --preset mcp-readonly \ --label cursor-discovery paybond keys create \ --name cursor-discovery \ --role analyst \ --kind restricted \ --preset mcp-readonly \ --label cursor-discovery
Presets (settlement / live-money write is never included — add--scope mcp.settlement:writeonly when you intentionally need fund/confirm):
paybond mcp scopes list paybond mcp scopes list --format json paybond mcp scopes list paybond mcp scopes list --format json
Whenmcp installdetects a restricted key in the env file, it omitsPAYBOND_MCP_TOOL_POLICYfrom the generated host config — scopes come from the key. Pairing--tool-policy/--tool-allowlistwith a restricted key is rejected.
export PAYBOND_PRINCIPAL_PATH="/v1/auth/principal" export PAYBOND_MCP_MAX_RETRIES="3" export PAYBOND_MCP_EVIDENCE_POLICY="strict" export PAYBOND_ENV_FILE=".env.local" export PAYBOND_PRINCIPAL_PATH="/v1/auth/principal" export PAYBOND_MCP_MAX_RETRIES="3" export PAYBOND_MCP_EVIDENCE_POLICY="strict" export PAYBOND_ENV_FILE=".env.local"
PAYBOND_MCP_EVIDENCE_POLICYdefaults tostrict. In strict mode, evidence submit tools refuse calls untilpaybond_validate_completion_evidencesucceeds for the same preset and payload. Setoffonly for local debugging. Harbor predicate and schema validation remain authoritative at submit time.
Optional policy hot-reload for long-lived MCP processes:
export PAYBOND_POLICY_FILE="./paybond.policy.yaml" export PAYBOND_POLICY_RELOAD="watch" # watch | poll | off (default off) export PAYBOND_POLICY_RELOAD_ALLOW_LOOSEN="0" export PAYBOND_POLICY_FILE="./paybond.policy.yaml" export PAYBOND_POLICY_RELOAD="watch" # watch | poll | off (default off) export PAYBOND_POLICY_RELOAD_ALLOW_LOOSEN="0"
WhenPAYBOND_POLICY_FILEis set,paybond_authorize_agent_spendandpaybond_verify_capabilityenforce the policy registry before Harbor verification. Spend caps resolve from the policy file whenrequested_spend_centsis omitted. Reload waits for in-flight MCP tool calls to finish before swapping the registry; failed reloads keep the previous snapshot. Usepollwith tenant overlay policies to refresh effective policy from the Gateway.
npx paybond-mcp-server npx paybond-mcp-server
Stdio remains the default for desktop hosts (Cursor, Claude Desktop, Codex CLI). For hosts that need a network URL instead of a local subprocess — remote agent runtimes, MCP Inspector's HTTP mode, or any orchestrator that cannot launch child processes — Paybond also runs the same tool surface overStreamable HTTP, MCP's current remote transport (a singlePOST /mcpwith a JSON response; no legacy HTTP+SSE).
Hosted endpoint:https://mcp.paybond.ai/mcp
curl https://mcp.paybond.ai/mcp \ -X POST \ -H "content-type: application/json" \ -H "authorization: Bearer $PAYBOND_API_KEY" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' curl https://mcp.paybond.ai/mcp \ -X POST \ -H "content-type: application/json" \ -H "authorization: Bearer $PAYBOND_API_KEY" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Every request supplies its own service-account or restricted MCP key asAuthorization: Bearer paybond_sk_...orBearer paybond_rk_...— the hosted endpoint is multi-tenant and stateless: tenant scope comes from the key alone (never from a client-suppliedtenant_id), and each request is handled independently with nothing cached or shared across callers. Restricted keys filter the tool surface per request fromprincipal.mcp_scopes. Because there is no per-connection session, always passcapability_tokenexplicitly topaybond_authorize_agent_spend/paybond_verify_capabilityrather than relying on the token being remembered from an earlier call in the same process (that convenience only applies to a single long-lived stdio session).
Example MCP client config for an HTTP-capable host (prefer a restricted key in production):
{ "url": "https://mcp.paybond.ai/mcp", "headers": { "Authorization": "Bearer paybond_rk_sandbox_..." } } { "url": "https://mcp.paybond.ai/mcp", "headers": { "Authorization": "Bearer paybond_rk_sandbox_..." } }
Self-hosting the same contract:both Kit CLIs can run the identical Bearer/Origin//healthzcontract locally instead of depending on the hosted endpoint:
# TypeScript npx paybond-kit mcp serve --transport http # Python (requires the optional \mcp\ extra: pip install "paybond-kit[mcp]") paybond-kit mcp serve --transport http # TypeScript npx paybond-kit mcp serve --transport http # Python (requires the optional \mcp\ extra: pip install "paybond-kit[mcp]") paybond-kit mcp serve --transport http
The Python CLI binds toone tenantfor the life of the process: setPAYBOND_API_KEYin the process environment and every incoming Bearer token is checked against that single key (a shared-secret gate on network access, not a way to serve multiple tenants from one process). The TypeScript CLI is multi-tenant like the hosted endpoint — it derives tenant scope per request from whatever key the caller presents. Both accept the samePAYBOND_MCP_HTTP_environment variables:
export PAYBOND_MCP_HTTP_ADDR="0.0.0.0:8080" # default export PAYBOND_MCP_HTTP_ALLOWED_ORIGINS="https://example.com" # comma-separated; only enforced when a client sends an Origin header export PAYBOND_MCP_HTTP_MAX_BODY_BYTES="1048576" # 1 MiB default export PAYBOND_MCP_HTTP_RATE_LIMIT_PER_MINUTE="120" # per authenticated API key export PAYBOND_MCP_HTTP_RATE_LIMIT_UNAUTH_PER_MINUTE="30" # per source IP, slows credential scanning export PAYBOND_MCP_HTTP_ADDR="0.0.0.0:8080" # default export PAYBOND_MCP_HTTP_ALLOWED_ORIGINS="https://example.com" # comma-separated; only enforced when a client sends an Origin header export PAYBOND_MCP_HTTP_MAX_BODY_BYTES="1048576" # 1 MiB default export PAYBOND_MCP_HTTP_RATE_LIMIT_PER_MINUTE="120" # per authenticated API key export PAYBOND_MCP_HTTP_RATE_LIMIT_UNAUTH_PER_MINUTE="30" # per source IP, slows credential scanning
GET /healthzreturns200without auth for load-balancer and container health checks.PAYBOND_POLICY_RELOAD=watch|poll(policy hot reload) is rejected at HTTP startup — it depends on one long-lived process instance and is only supported for stdio; usePAYBOND_POLICY_RELOAD=off(the default) or omit it entirely when running HTTP.
Read-only discovery and compliance (allowed under--tool-policy readonly):
- paybond_get_principal
- paybond_list_intents
- paybond_get_intent
- paybond_list_audit_exports
- paybond_get_audit_export
- paybond_get_reputation_receipt
- paybond_get_portfolio_summary
- paybond_get_signed_portfolio_artifact
- paybond_get_fraud_assessment
- paybond_get_fraud_metrics
- paybond_get_a2a_agent_card
- paybond_list_a2a_task_contracts
- paybond_get_a2a_task_contract
- paybond_verify_agent_mandate_v1
- paybond_verify_agent_recognition_proof_v1
- paybond_get_settlement_receipt_v1
- paybond_verify_protocol_receipt_v1
- paybond_get_agent_receipt_v1
- paybond_verify_agent_receipt_v1
- paybond_validate_completion_evidence
- paybond_get_budget_remaining
- paybond_explain_policy
Spend and mutation tools (default--tool-policy spend-write; live-money tools such aspaybond_fund_intentandpaybond_confirm_settlementstay blocked unless explicitly allowlisted):
- paybond_verify_capability
- paybond_authorize_agent_spend
- paybond_bootstrap_sandbox_guardrail
- paybond_submit_sandbox_guardrail_evidence
- paybond_import_agent_mandate_v1
- paybond_create_intent
- paybond_create_spend_intent
- paybond_fund_intent
- paybond_submit_evidence
- paybond_submit_spend_evidence
- paybond_confirm_settlement
For production hosts, mint a restricted key (seeRestricted MCP keys) so the credential itself limits the tool surface. For local standard-key installs, a readonly env policy still works:
# Preferred (scopes on the key) paybond keys create --name cursor --role analyst --kind restricted --preset mcp-readonly paybond mcp install --host generic --scope project # Local standard-key override (dev only) paybond mcp install --host generic --scope project --tool-policy readonly # Preferred (scopes on the key) paybond keys create --name cursor --role analyst --kind restricted --preset mcp-readonly paybond mcp install --host generic --scope project # Local standard-key override (dev only) paybond mcp install --host generic --scope project --tool-policy readonly
Local audit bundle verification (paybond audit exports verify <path>orpaybond.audit.exports.verify(...)) is SDK/CLI only. MCP hosts cannot verify downloaded ZIP paths on disk. Compliance bundles that includeagent_receiptsmay also contain PEF companion files (.pef.json) alongside each signed receipt.
The spend-named tools are aliases over the same tenant-bound Harbor and Gateway routes. They exist so agent hosts can match user requests like "control agent spend", "add tool-call spend limits", or "authorize paid vendor actions" without guessing from lower-level capability names.
paybond_get_budget_remainingandpaybond_explain_policycall the side-effect-free gateway routePOST /v1/spend/preflight. They evaluate the same spend-control policy as authorize without creating decisions, reservations, or approval requests. Use them beforepaybond_authorize_agent_spendwhen an agent needs remaining budget or a human-readable allow / approval_required / deny explanation. Matching CLI commands:paybond spend budget-remainingandpaybond spend explain-policy.
paybond_verify_protocol_receipt_v1is a read-only offline verify of a signed protocol-v2 authorization or settlement receipt (POST /protocol/v2/receipts/verify). Pass the full receipt object (not areceipt_id). Usepaybond_verify_agent_mandate_v1for mandate envelopes andpaybond_verify_capability/paybond_authorize_agent_spendfor Harbor capability gates. Fetch a settlement receipt first withpaybond_get_settlement_receipt_v1when you only have an intent UUID.
paybond_get_agent_receipt_v1fetches a signedpaybond.agent_receipt_v1byreceipt_id(tenant-boundGET /protocol/v2/agent-receipts/{receipt_id}).paybond_verify_agent_receipt_v1runs the same offline operational-tier signature check asresources/readonpaybond://receipt/{receipt_id}; pass optionalvalidity_tier=primary|attestedwhen you need a stronger bar. Continuity-chain, inclusion proofs, owner disclosure, and ACTA/PEF/SCITT adapters remain Kit TypeScript/Python and CLI/Gateway auditor surfaces—not MCP’s full job.
paybond_get_principalreturns the tenant-bound service-account principal for the configuredPAYBOND_API_KEY(tenant_id,subject,roles) via a read-only gatewayGET. Use it when you need to confirm auth identity; call early as a prerequisite before intent lifecycle calls, Signal reads, or other tenant-scoped tools when tenant identity is unknown. Not required before every later call oncetenant_idis already known. Do not use it when you need intent detail—usepaybond_get_intentinstead when you have anintent_id. Do not use it for A2A discovery—usepaybond_get_a2a_agent_cardinstead.
paybond_get_portfolio_summaryreturns a tenant-scoped Signal aggregate (counts, average score, volume, operators under review). Omitscore_versionto use the gateway default (1.0). Preferpaybond_get_signed_portfolio_artifactwhen you need a portable signed operator list for partner or verifier sharing, andpaybond_get_reputation_receiptfor one operator.
paybond_get_signed_portfolio_artifactreturns a tenant-scoped signed Signal portfolio snapshot (operator list plus Ed25519 signing material) for offline verifier checks or partner sharing. Omitscore_versionto use the gateway default (1.0). Preferpaybond_get_portfolio_summaryfor unsigned aggregates,paybond_get_reputation_receiptfor one operator, andpaybond_get_fraud_assessmentfor fraud review posture.
paybond_get_fraud_metricsreturns tenant-wide fraud backtesting metrics for a rolling window (24hdefault, or7d/30d). Unsupported windows fail with HTTP 400. Usepaybond_get_fraud_assessmentwhen you need one operator's fraud posture instead of tenant aggregates.
paybond_get_reputation_receiptfetches the signed Signal reputation receipt for one operator DID (GET /reputation/{operator_did}). Omitscore_versionto use the gateway default (1.0). Returns null when no receipt exists. Preferpaybond_get_portfolio_summaryfor tenant aggregates,paybond_get_signed_portfolio_artifactfor a portable signed operator list, andpaybond_get_fraud_assessmentfor fraud review posture.
The sandbox guardrail tools are separate developer-only helpers. They call/v1/sandbox/guardrails/..., derive tenant scope from the configured service-account API key, and do not replace the production Harbor create/fund/evidence tools.
- Callpaybond_create_spend_intentto create the signed spend intent.
- If the intent is not funded immediately, callpaybond_fund_intent.
- Optionally callpaybond_get_budget_remainingorpaybond_explain_policyfor a read-only preflight of remaining budget and policy outcome.
- Use the returnedintent_idandcapability_tokenwithpaybond_authorize_agent_spendbefore any paid API call, vendor action, settlement step, or other side-effecting tool.
- Callpaybond_validate_completion_evidencewith the completion preset and payload you plan to submit.
- After the guarded work completes, callpaybond_submit_spend_evidencewith the same preset and payload.
If you are writing SDK code instead of exposing MCP tools, usepaybond.spendGuard(intentId, capabilityToken)in TypeScript orpaybond.spend_guard(intent_id, capability_token)in Python.PaybondCapabilityBindingis only needed for Python framework adapters that require a run-context object.
- Callpaybond_bootstrap_sandbox_guardrailwith an operation and sandbox spend amount.
- Use the returnedintent_idandcapability_tokenwithpaybond_authorize_agent_spendbefore the sample paid tool executes.
- Callpaybond_validate_completion_evidencewhen using a completion preset (for exampleapi_response_ok).
- Callpaybond_submit_sandbox_guardrail_evidencewith the sandboxintent_id,completion_preset_id, and evidence payload.
Validate the MCP authorize and evidence path without launching a stdio subprocess or an LLM:
paybond agent demo mcp smoke \ --operation paid-tool \ --requested-spend-cents 100 \ --evidence-preset cost_and_completion \ --format json paybond agent demo mcp smoke \ --operation paid-tool \ --requested-spend-cents 100 \ --evidence-preset cost_and_completion \ --format json
The smoke uses in-processPaybondMCPServer.callTool()(TypeScript) orbuild_mcp_server().call_tool()(Python): sandbox bind,paybond_authorize_agent_spend, mock side-effect completion, andpaybond_submit_sandbox_guardrail_evidence. Python requires the optionalmcpextra (pip install "paybond-kit[mcp]").
- The server is bound toone tenantderived from the configured service-account API key.
- Donotpass tenant IDs manually through tool arguments for normal flows.
- Gateway-backed state-changing tools require the right proof material and fail closed when proofs are missing, stale, replayed, or mismatched.
- Signed Harbor request bodies remain the caller's responsibility. The MCP server does not manage long-lived signing keys on behalf of the model.
- The hosted HTTP endpoint (https://mcp.paybond.ai/mcp) accepts:
- Restricted keys(paybond_rk_) — preferred for agents and automation; scopes on the key are the permission model.
- Standard keys(paybond_sk_) — full role entitlements; use only when you intentionally want an unrestricted machine credential.
- MCP OAuth access tokens(paybond_oat_) — user-scoped grants from the Console consent flow for interactive hosts (Cursor, Claude, VS Code). Short-lived; refresh withpaybond_ort_viaPOST /v1/oauth/token.
Check which credential a host config will actually use:
paybond doctor --mcp --host claude paybond doctor --mcp --host claude
--mcpfails when the config resolves to an unrestrictedpaybond_sk_key (the gateway cannot cap its MCP surface) and again when that key is not even narrowed byPAYBOND_MCP_TOOL_POLICY. Pass--config <path>to grade an on-disk host config instead of the onepaybond mcp installwould generate.
Interactive MCP hosts can obtain a scoped bearer without embedding a long-lived API key:
- Host redirects the browser toGET /v1/oauth/authorize(PKCE S256,response_type=code).
- Console opens/console/authorize/mcp?request=…for a humantenant_admin.
- Admin reviews requested scopes / visible tools, optionally narrows the grant, and approves (livemcp.settlement:writerequires MFA step-up).
- Host redeems the code atPOST /v1/oauth/tokenand callshttps://mcp.paybond.ai/mcpwithAuthorization: Bearer paybond_oat_….
Tenant admins manage the per-environment MCP kill switch, active OAuth sessions, and custom redirect URIs underConsole → Machine access → MCP access. Disabling MCP blocks new grants and rejects existingpaybond_oat_bearers for that environment.
Example local stdio entry using the default.env.localwritten bypaybond login:
{ "command": "npx", "args": ["-y", "-p", "@paybond/kit", "paybond-mcp-server"], "env": { "PAYBOND_ENV_FILE": ".env.local" } } { "command": "npx", "args": ["-y", "-p", "@paybond/kit", "paybond-mcp-server"], "env": { "PAYBOND_ENV_FILE": ".env.local" } }
Advanced direct-key entry for hosts that cannot read env files:
{ "command": "npx", "args": ["-y", "-p", "@paybond/kit", "paybond-mcp-server"], "env": { "PAYBOND_API_KEY": "paybond_sk_sandbox_..." } } { "command": "npx", "args": ["-y", "-p", "@paybond/kit", "paybond-mcp-server"], "env": { "PAYBOND_API_KEY": "paybond_sk_sandbox_..." } }
MCP’s ARS role isagent-to-agent receipt handoffvia the resource URIpaybond://receipt/{receipt_id}—hosts pass the URI between agents without embedding full JSON in prompts.
- resources/templates/list— publishes thepaybond://receipt/{receipt_id}template
- resources/read— fetches the signedpaybond.agent_receipt_v1JSON and verifies at theoperationaltier before returning; verification failure returns a clear error (contents are not handed off unsigned)
Readonly tools (same surface as settlement-receipt tools):
- paybond_get_agent_receipt_v1— fetch byreceipt_id
- paybond_verify_agent_receipt_v1— offline verify of a receipt object; optionalvalidity_tier(operationaldefault, orprimary/attested)
Validity tiers beyond a quick handoff check, continuity-chain audits, Merkle inclusion / tree-head proofs, confidential owner disclosure, and ACTA / PEF / SCITT export adapters areKit TypeScript/Python, CLI, and Gatewayauditor surfaces—not MCP’s full job. Use Kit client libraries for those flows.
Compliance audit exports that include agent receipts may also ship PEF companions (*.pef.json) beside each signed receipt JSON.
- Coding-agent setup
- One-command guardrails
- Authentication & tenant binding
- Agent integrations
- V2 protocol trust
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.




