paybond-mcp
Paybond MCP server provides tenant-scoped agent spend controls, evidence-gated settlement, and audit/reputation tools for AI agents that move money.
Spend authorization & budget gates: Verify capability tokens (
paybond_verify_capability), authorize spend before side-effecting tools (paybond_authorize_agent_spend), and dry-run remaining budget or policy explanations (paybond_get_budget_remaining,paybond_explain_policy).Intent & evidence lifecycle: Create/fund Harbor intents (
paybond_create_spend_intent,paybond_create_intent), submit signed evidence for release/refund (paybond_submit_spend_evidence,paybond_submit_evidence), and validate evidence against schemas (paybond_validate_completion_evidence).Sandbox guardrails: Bootstrap sandbox-only guardrail intents (
paybond_bootstrap_sandbox_guardrail) and submit sandbox evidence for simulator settlement (paybond_submit_sandbox_guardrail_evidence).Tenant identity & intent introspection: Confirm principal identity (
paybond_get_principal), list/get Harbor intents (paybond_list_intents,paybond_get_intent), and audit export jobs (paybond_list_audit_exports,paybond_get_audit_export).Signal reputation & portfolio: Fetch signed reputation receipts per operator (
paybond_get_reputation_receipt), tenant portfolio summaries (paybond_get_portfolio_summary), and signed portfolio artifacts for partner sharing (paybond_get_signed_portfolio_artifact).Fraud assessment & metrics: Query per-operator fraud posture (
paybond_get_fraud_assessment) and tenant-wide fraud metrics over rolling windows (paybond_get_fraud_metrics).A2A discovery & contracts: Fetch Paybond A2A agent card (
paybond_get_a2a_agent_card) and task contract catalog (paybond_list_a2a_task_contracts,paybond_get_a2a_task_contract).Protocol verification & receipts: Verify agent mandates (
paybond_verify_agent_mandate_v1), recognition proofs (paybond_verify_agent_recognition_proof_v1), import mandates bound to intents (paybond_import_agent_mandate_v1), fetch settlement/agent receipts (paybond_get_settlement_receipt_v1,paybond_get_agent_receipt_v1), and offline-verify agent or protocol receipts (paybond_verify_agent_receipt_v1,paybond_verify_protocol_receipt_v1).
Framework integration with LangGraph to build agent workflows with Paybond spend guardrails, tool-call budgets, and evidence submission.
Framework integration with OpenAI Agents SDK for adding Paybond spend controls and authorization to OpenAI agent tools.
Enables reading tenant-scoped Signal data for fraud detection and risk assessment in agent workflows.
Provides settlement rails via Stripe Connect and ACH Direct Debit for processing payments and refunds in agent tool-call spend.
Framework integration with Vercel AI SDK to apply Paybond spend guardrails and evidence submission in Vercel AI projects.
@paybond/kit
Your AI agent shouldn't accidentally spend $20,000.
An unsupervised agent that can book travel, call paid APIs, or buy compute can also loop through “approved” tool calls until the budget is gone — each charge succeeds, and nothing proves the work was delivered. Per-transaction caps alone do not stop that.
@paybond/kit is the TypeScript SDK for delegated agent spend controls: authorize against a bounded budget and policy before a paid tool runs, then release or refund only after signed completion evidence. Wrap three lines around any paid tool call — authorize → execute → verify. Keep your runtime. Keep your payment rails (prefer Stripe Connect / x402; Stripe ACH Direct Debit and USDC-on-Base are also available). You get spend authorization, evidence-gated settlement, refunds, disputes, and a portable signed receipt — without building your own proof-gated release middleware.
Under the hood, Kit opens hosted Gateway sessions, verifies capability tokens, signs intent and evidence payloads, and can read tenant-scoped Signal, fraud, ledger, protocol, and A2A data, with adapters for common agent runtimes.
Docs · TypeScript quickstart · Support matrix · Free sandbox signup · Python package
When to use Paybond
Reach for Paybond Kit whenever an AI agent can move money and you need spend that stays inside a budget — not just token metering: agentic payments and commerce, tool-call spend limits, outcome evidence before release, and audit-ready records — across OpenAI, Gemini, Claude/Anthropic, Vercel AI SDK, LangGraph, MCP hosts, and custom runtimes, settling through the payment rails your tenant already uses.
Use Paybond Kit when spend needs authorization against a bounded budget, proof-gated release/refund/dispute handling, or audit-ready receipts.
Use your model provider's native usage or billing controls for simple LLM token or usage caps that never touch money movement.
Related MCP server: l402-kit-mcp
Start here (sandbox in ~60 seconds)
No account and no API key — rehearse the full authorize → execute → evidence loop locally, then open the trace dashboard:
npm install @paybond/kit
npx -p @paybond/kit paybond dev loop --offline
npx -p @paybond/kit paybond dev tracepaybond dev trace renders the middleware timeline at http://127.0.0.1:9477.
To try the same flow against the real hosted sandbox Gateway, first create a free Free Developer workspace if you do not already have a Paybond account (no card required), then:
npx -p @paybond/kit paybond login
npx -p @paybond/kit paybond-init --preset paid-tool-guard --framework provider-agnostic --out paybond-paid-tool-guard.ts
npx -p @paybond/kit paybond agent sandbox smoke \
--operation travel.book_hotel \
--requested-spend-cents 20000 \
--evidence-preset cost_and_completion \
--result-body '{"status":"completed","cost_cents":18700}' \
--format jsonpaybond login opens a browser device-approval step; the workspace owner (you, right after signup) approves it and the CLI writes a sandbox PAYBOND_API_KEY to .env.local.
Launch the tenant-bound MCP server for MCP hosts (after paybond login):
npx -y -p @paybond/kit paybond-mcp-serverFor coding agents and LLMs, the full discovery guide lives at https://paybond.ai/llms.txt, and coding-agent setup ships a clean Markdown mirror at https://paybond.ai/docs/kit/coding-agent-setup.md.
Install
npm install @paybond/kit@paybond/kit is an ESM-only package for Node.js runtimes. Use import from a Node ESM / NodeNext project or a compatible bundler.
Optional framework integrations
The core package is enough for Harbor sessions, spend guards, policy files, and paybond agent sandbox smoke. Install optional peers only when you import a framework subpath:
Subpath | Peer dependency |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| none — no extra peers required |
npm install ai @openai/agents @langchain/core @langchain/langgraph @anthropic-ai/claude-agent-sdk @google/adk @mastra/core agentsThin npm wrappers (@paybond/vercel-ai, @paybond/langgraph, @paybond/openai-agents, @paybond/claude-agents, @paybond/google-adk, @paybond/mastra, @paybond/cloudflare-agents, @paybond/agent, @paybond/mcp) re-export the same subpaths for npm discoverability — install whichever matches your framework instead of the whole peer list above.
Open source and supply chain
@paybond/kit is distributed as open-source software under the Apache 2.0 license. The published npm package includes the full license text in LICENSE. Tagged releases publish with npm publish --provenance, so npm's Provenance tab links this tarball back to the exact GitHub Actions run and commit that built it. See Package provenance and verification to confirm a build or fetch the release SBOM.
Requirements
Node.js 22+
A
paybond_sk_sandbox_...orpaybond_sk_live_...service-account API keyFor intent creation or evidence submission: 32-byte Ed25519 signing seeds owned by your application
Create a sandbox key for local development:
npx -p @paybond/kit paybond loginpaybond login writes a sandbox PAYBOND_API_KEY to .env.local with file mode 0600, adds the default .env.local target to .gitignore when needed, and refuses to overwrite an existing key unless --force is passed. Custom env-file paths inside a git repo must already be ignored. Live production keys are created by tenant admins in Console and stored in deployment secret managers.
CLI
The package ships the paybond CLI (paybond, paybond-init, paybond-kit-login, paybond-mcp-server).
Scaffold a starter project from bundled templates:
npx -p @paybond/kit paybond init --template travel-agent
npm install
npm run smokeEnd-to-end sandbox smoke (bind + execute + evidence) with no app code:
npx -p @paybond/kit paybond agent sandbox smoke \
--policy-file paybond.policy.yaml \
--result-body '{"status":"completed","cost_cents":18700}' \
--format jsonWith --policy-file, Kit sends completion_preset from the tool's evidence_preset and omits evidence_schema and template_id (Gateway rejects conflicting bootstrap fields). Requires @paybond/kit 0.11.11+.
agent sandbox smoke only requires @paybond/kit. Framework demo commands (agent demo vercel-ai smoke, etc.) load their optional peers on demand.
Offline local dev loop and trace dashboard:
npx -p @paybond/kit paybond dev loop --offline
npx -p @paybond/kit paybond dev traceFirst guardrail scaffold
Use this when you have a paid tool and want Paybond guardrails in the sandbox:
npx -p @paybond/kit paybond-init \
--preset paid-tool-guard \
--framework provider-agnostic \
--out paybond-paid-tool-guard.tsThe generated integration opens Paybond from the environment, loads .env.local when PAYBOND_API_KEY is not already present, bootstraps a sandbox guardrail intent, wraps your paid-tool handler, and submits sandbox evidence. It does not generate a paid-tool implementation. Free Developer is sandbox-only; live settlement rails start on paid production plans.
Tenant isolation
Every session is bound to the tenant realm echoed by gateway-authenticated service-account introspection.
Do not pass tenant ids by hand for normal SDK usage.
Construct one
Paybondsession per tenant/service account.Treat any tenant or intent echo mismatch from Harbor as a severity-zero defect.
Quick start
import { Paybond } from "@paybond/kit";
function requiredEnv(name: string): string {
const value = process.env[name];
if (!value) {
throw new Error(`missing ${name}`);
}
return value;
}
const paybond = await Paybond.open({
apiKey: requiredEnv("PAYBOND_API_KEY"),
expectedEnvironment: "sandbox",
});
try {
console.log("tenant realm:", paybond.harbor.tenantId);
} finally {
await paybond.aclose();
}Agent spend controls
Use Paybond Kit when an agent workflow needs delegated spend guardrails, tool-call budget checks, paid API or vendor action approval, evidence, release/refund logic, disputes, or audit-ready receipts.
import { Paybond } from "@paybond/kit";
const paybond = await Paybond.open({
apiKey: process.env.PAYBOND_API_KEY!,
expectedEnvironment: "sandbox",
});
const guardrail = await paybond.guardrails.bootstrapSandbox({
operation: "travel.book_hotel",
requestedSpendCents: 20_000,
currency: "usd",
});
const guard = paybond.spendGuard(guardrail.intent_id, guardrail.capability_token);
const guardedTool = guard.guardTool(
{
operation: guardrail.operation,
requestedSpendCents: guardrail.requested_spend_cents,
},
async (input) => bookHotel(input),
);
const result = await guardedTool({ hotelId: "hotel_123", maxPriceCents: 20_000 });
await paybond.guardrails.submitSandboxEvidence({
intentId: guardrail.intent_id,
payload: { result, sandbox: true },
});The paybond.harbor and paybond.guardrails clients are created by Paybond.open(...) and bound to the tenant resolved from the service-account API key. Production integrations read capability_token from paybond.intents.create(...), or from paybond.intents.fund(...) after an x402_usdc_base payment challenge is satisfied.
What the package includes
Core SDK:
Paybond.open(...)for API-key-only, tenant-derived hosted sessionsHarborClientfor capability verification, intent creation, x402 funding, evidence submission, and ledger readspaybond.signalandpaybond.fraudonPaybondsessions opened from one service-account API keyPaybondIntentshelpers for principal-signed intent creation, x402 funding, payee-signed evidence submission, and settlement confirmationPaybondSpendGuard,authorizeSpend, andguardToolfor spend-named wrappers around capability verificationRuntime-neutral and framework aliases:
paybondAgentToolSpendGuard,paybondRuntimeNeutralToolSpendGuard,paybondLangGraphToolSpendGuard, andpaybondMCPToolSpendGuardpaybondRuntimeToolCallAdapterfor agent SDKs and custom runtimes that expose a tool-call object plus an application-owned executor
Agent middleware (@paybond/kit/agent) and framework subpaths (vercel-ai, openai-agents, langgraph, claude-agents, mcp, policy):
PaybondAgentRun, tool registry, interceptor, and policy-file bindingFramework adapters with optional peer dependencies (see table above)
paybond init,paybond agent run bind,paybond agent tool execute, andpaybond agent sandbox smoke
Gateway and trust helpers:
GatewaySignalClientandServiceAccountSignalSessionfor tenant-scoped Signal reads and signed portfolio artifactsGatewayFraudClientandServiceAccountFraudSessionfor tenant-scoped fraud assessments, review queues, review events, metrics, and release-gate configProtocol-v2 helpers for mandate verification, replay-safe recognition proof verification, receipt reads, and A2A discovery
paybond loginfor sandbox device approval and local.env.localAPI-key setuppaybond-mcp-serverfor tenant-bound MCP tool exposure to any MCP-compatible hostpaybond-initfor generating a Paybond guardrail integration helper
Agent-facing surfaces are model-provider agnostic. Paybond verifies tool operations and tenant scope, not whether a tool call came from OpenAI, Anthropic, Gemini, a local model, or another runtime.
allowedTools values are your own tool or operation names, not a Paybond-owned catalog. Harbor enforces string matching against whatever names you chose when creating the intent.
settlementRail on intent creation is a principal-signed rail request. Stripe destinations and x402 receive addresses stay tenant-owned server-side config and are never supplied by the SDK caller.
The protocol-v2 surface is trust-first: signed mandates, recognition proofs, and receipts work across supported settlement adapters instead of treating any single rail as the product boundary.
Gateway-backed protocol helpers throw ProtocolHttpError with parsed errorCode and errorMessage fields when the gateway returns a JSON error envelope. Recognition-gated flows surface unregistered_key, revoked_key, mandate_agent_key_mismatch, and protocol_binding_mismatch explicitly.
What it does not include
No operator-tier settlement or console workflows
No bundled LLM or model runtime — bring your own agent framework and install optional peers when needed
No model-provider-specific MCP wrapper; the MCP server is host-agnostic and works with any MCP-compatible runtime
Docs
Agent and LLM discovery guide: https://paybond.ai/llms.txt
Coding-agent setup (Markdown mirror): https://paybond.ai/docs/kit/coding-agent-setup.md
Long-form docs: https://paybond.ai/docs/kit
Agent quickstart: https://paybond.ai/docs/kit/quickstart-agent
One-command guardrails: https://paybond.ai/docs/kit/one-command-guardrails
TypeScript quickstart: https://paybond.ai/docs/kit/quickstart-typescript
TypeScript SDK reference: https://paybond.ai/docs/kit/sdk-reference-typescript
Support matrix (languages, frameworks, rails): https://paybond.ai/docs/kit/support-matrix
Package provenance and verification: https://paybond.ai/docs/kit/package-provenance
MCP server guide: https://paybond.ai/docs/kit/mcp-server
Agent runtime tutorial: https://paybond.ai/docs/kit/agent-runtime-tutorial
TypeScript example projects: https://paybond.ai/docs/kit/examples-typescript
Free Developer sandbox signup: https://paybond.ai/signup
Release verification
For maintainers working from a source checkout, release verification lives in this package directory:
npm run verify:releaseThis runs tests, performs a clean build, inspects the packed tarball for stray files, and compiles a temporary consumer app against the packed package.
Available Tools
31 toolspaybond_authorize_agent_spendAuthorize Agent SpendA
Use this when an agent has an intent_id and capability_token and needs a tenant-bound spend gate before calling a side-effecting tool, paid API, vendor action, or settlement workflow. Do not use this for creating, funding, or changing intents; call paybond_create_spend_intent or paybond_fund_intent first when no funded capability token exists.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional capability token override. When omitted, the MCP server uses the token stored for intent_id. | |
| intent_id | Yes | Canonical Harbor intent UUID. | |
| operation | Yes | Delegated operation or tool name. | |
| requested_spend_cents | No | Optional requested spend in cents for this tool call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| allow | No | Whether the requested operation is allowed. |
| tenant | Yes | Tenant echoed by the gateway. |
| message | No | Human-readable decision message when present. |
| audit_id | No | Gateway audit identifier when available. |
| intent_id | Yes | Verified Harbor intent UUID. |
| decision_id | No | Persisted spend decision identifier when authorization creates one. |
| reason_codes | No | Stable spend-policy reason codes from the authorization decision. |
| remaining_cents | No | Remaining spend budget in cents for the evaluated scope, when available. |
| approval_request_id | No | Approval request identifier when human approval is required. |
paybond_bootstrap_sandbox_guardrailBootstrap Sandbox GuardrailA
Use this when building or testing a first paid-tool integration and you need a sandbox-only guardrail intent with no live settlement rails. Do not use this for production live money movement or already-created Harbor intents.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Optional ISO currency code; defaults at the gateway. | |
| metadata | No | ||
| operation | Yes | Delegated operation or paid tool name. | |
| evidence_schema | No | ||
| idempotency_key | No | ||
| requested_spend_cents | Yes | Sandbox spend amount in cents to authorize for the sample tool call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| intent_id | Yes | |
| operation | Yes | |
| tenant_id | Yes | |
| settlement_mode | No | |
| settlement_rail | No | |
| capability_token | Yes | |
| requested_spend_cents | Yes | |
| sandbox_lifecycle_status | Yes |
paybond_create_intentCreate Harbor IntentA
Use this when you already have a fully signed Harbor intent request body and replay-safe recognition proof for the gateway /harbor/intents route. Do not use this for the normal agent spend-control path unless you specifically need the low-level Harbor API; prefer paybond_create_spend_intent.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| idempotency_key | No | ||
| recognition_proof | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| intent_id | No | |
| capability_token | No |
paybond_create_spend_intentCreate Spend IntentA
Use this when an agent workflow needs a new Paybond spend intent with bounded budget, allowed operations, evidence requirements, and settlement review. Do not use this for checking an already funded capability token; use paybond_authorize_agent_spend before the paid action.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| idempotency_key | No | ||
| recognition_proof | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| intent_id | No | |
| capability_token | No |
paybond_explain_policyExplain Spend PolicyARead-only
Use this when you need a read-only explanation of whether a proposed spend would allow, require approval, or deny under the tenant spend-control policy. Do not use this to authorize spend or create approval requests; call paybond_authorize_agent_spend to persist a decision.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | No | Optional task scope hint for policy evaluation. | |
| currency | No | Optional ISO currency code for the proposed spend. | |
| intent_id | Yes | Canonical Harbor intent UUID. | |
| operation | No | Optional delegated operation or tool name. Defaults to * when omitted. | |
| tool_name | No | Optional tool name scope hint for policy evaluation. | |
| vendor_id | No | Optional vendor scope hint for policy evaluation. | |
| workflow_id | No | Optional workflow scope hint for policy evaluation. | |
| tool_call_id | No | Optional tool-call correlation id for policy evaluation. | |
| agent_subject | No | Optional agent subject for agent-scoped caps. | |
| approval_token | No | Optional approval token to evaluate against pending approval state (not consumed). | |
| requested_spend_cents | No | Optional proposed spend in cents for the dry-run evaluation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| outcome | Yes | Normalized policy outcome: allow, approval_required, or deny. |
| explanation | Yes | Human-readable explanation derived from reason codes. |
| reason_codes | No | Stable policy reason codes from the dry-run evaluation. |
| remaining_cents | No | Remaining spend budget in cents for the evaluated scope, when available. |
| approval_threshold_exceeded | No | True when the dry-run indicates the request is at or above the approval threshold. |
paybond_get_a2a_agent_cardGet A2A Agent CardARead-only
Fetch the published Paybond A2A discovery card for protocol-trust delegation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | |
| skills | No | |
| version | No |
paybond_get_a2a_task_contractGet A2A Task ContractARead-only
Fetch one published Paybond A2A task contract by identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| description | No |
paybond_get_agent_receipt_v1Get Agent ReceiptARead-only
Use this when you need the signed paybond.agent_receipt_v1 JSON for one receipt_id (SHA-256 action id or intent-terminal UUID) via tenant-bound Gateway GET. Do not use this for protocol settlement receipts—call paybond_get_settlement_receipt_v1. For agent-to-agent handoff without embedding JSON in prompts, prefer the MCP resource paybond://receipt/{receipt_id} (resources/read verifies at the operational tier). Validity tiers beyond operational, continuity-chain, inclusion proofs, owner disclosure, and ACTA/PEF/SCITT adapters are Kit/CLI/Gateway auditor surfaces—not this tool's job. Read-only and side-effect free.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | Agent receipt id: lowercase SHA-256 hex (action scope) or canonical UUID (intent_terminal). Must belong to the authenticated tenant; do not invent tenant identifiers. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | |
| tenant_id | Yes | |
| receipt_id | Yes |
paybond_get_audit_exportGet Audit ExportARead-only
Fetch one tenant-scoped compliance audit export job detail through the gateway operator view.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Compliance audit export job identifier. | |
| issue_download | No | When true, request a bundle download token for ready exports. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No |
paybond_get_budget_remainingGet Budget RemainingARead-only
Use this when you need a read-only dry-run of remaining spend budget for a tenant-bound intent before authorizing a paid tool. Do not use this to authorize spend or create decisions; call paybond_authorize_agent_spend when you are ready to gate a side-effecting tool.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | No | Optional task scope hint for policy evaluation. | |
| currency | No | Optional ISO currency code for the proposed spend. | |
| intent_id | Yes | Canonical Harbor intent UUID. | |
| operation | No | Optional delegated operation or tool name. Defaults to * when omitted. | |
| tool_name | No | Optional tool name scope hint for policy evaluation. | |
| vendor_id | No | Optional vendor scope hint for policy evaluation. | |
| workflow_id | No | Optional workflow scope hint for policy evaluation. | |
| tool_call_id | No | Optional tool-call correlation id for policy evaluation. | |
| agent_subject | No | Optional agent subject for agent-scoped caps. | |
| approval_token | No | Optional approval token to evaluate against pending approval state (not consumed). | |
| requested_spend_cents | No | Optional proposed spend in cents for the dry-run evaluation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| spend_scope | No | Spend scope used for the budget evaluation (scope_type and scope_key). |
| policy_version | No | Active spend-control policy version when a policy is configured. |
| remaining_cents | No | Remaining spend budget in cents for the evaluated scope, when available. |
paybond_get_fraud_assessmentGet Fraud AssessmentARead-only
Use this when you need the read-only fraud assessment and review posture for one known tenant-scoped operator DID (review state, fraud signals, and compact fraud_assessment). Example: look up operator_did=did:web:vendor.example#booker-agent (optionally score_version=1.0) before deciding whether to continue a spend workflow for that operator. Do not use this for tenant-wide fraud backtesting metrics—call paybond_get_fraud_metrics instead—or for Harbor intent escrow detail—call paybond_get_intent. Idempotent read; returns null when no assessment exists for that operator.
| Name | Required | Description | Default |
|---|---|---|---|
| operator_did | Yes | Tenant-scoped operator DID to assess. Must belong to the authenticated tenant; do not invent tenant identifiers. Examples: did:web:vendor.example#booker-agent, did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK. | |
| score_version | No | Optional Signal score model version to query. Omit to use the gateway default current model. Example: 1.0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tenant_id | No | Tenant echoed by the gateway for the authenticated API key (example: tenant-a). |
| operator_did | No | Operator DID echoed from the assessment response (example: did:web:vendor.example#booker-agent). |
| fraud_assessment | No | Compact fraud assessment for the operator (level, severity, signal counts, summary). Example shape: {"level":"high","highest_severity":"high","signal_count":1,"summary":"level=high"}. |
paybond_get_fraud_metricsGet Fraud MetricsARead-only
Use this when you need tenant-wide Signal fraud backtesting and monitoring metrics over a rolling window (flagged operators, severity counts, review outcomes, precision/false-positive rates, and backtest_summary). Requires PAYBOND_API_KEY with Signal analytics read access and the private-dashboards feature. Do not use this for one operator's fraud posture—call paybond_get_fraud_assessment instead—or for Harbor intent escrow detail—call paybond_get_intent. Idempotent read with no side effects; omit window to default to 24h; unsupported windows fail with HTTP 400 ("window must be one of 24h, 7d, or 30d").
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Rolling metrics window. Allowed values: 24h, 7d, 30d. Omit to use the gateway default 24h. Unsupported values fail with HTTP 400. | |
| score_version | No | Optional Signal score model version to query. Omit to use the gateway default current model (1.0). Example: 1.0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| window | No | Active metrics window label: 24h, 7d, or 30d. |
| tenant_id | No | Tenant echoed by the gateway for the authenticated API key (example: tenant-a). |
| window_ended_at | No | RFC3339 end of the evaluated rolling window. |
| backtest_summary | No | Human-readable backtest summary derived from the window metrics. |
| high_signal_count | No | Count of high-severity fraud signals in the window. |
| review_open_count | No | Operators currently in an open review state. |
| window_started_at | No | RFC3339 start of the evaluated rolling window. |
| score_model_version | No | Score model version used for the metrics (echoes the requested score_version or the gateway default 1.0). |
| confirmed_risk_count | No | Labeled confirmed-risk outcomes in the window. |
| false_positive_count | No | Labeled false-positive outcomes in the window. |
| critical_signal_count | No | Count of critical-severity fraud signals in the window. |
| elevated_signal_count | No | Count of elevated-severity fraud signals in the window. |
| labeled_outcome_count | No | Review outcomes labeled in the window (confirmed risk, false positive, or needs more evidence). |
| flagged_operator_count | No | Operators with at least one fraud signal in the window. |
paybond_get_intentGet Harbor IntentARead-only
Fetch one tenant-scoped Harbor intent detail through the gateway operator view.
| Name | Required | Description | Default |
|---|---|---|---|
| intent_id | Yes | Canonical Harbor intent UUID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| intent_id | No | |
| tenant_id | No |
paybond_get_portfolio_summaryGet Portfolio SummaryARead-only
Use this when you need a read-only, tenant-scoped Signal portfolio aggregate for the authenticated API key (operator_count, average_score, total_terminal_intents, total_receipted_volume_cents, operators_under_review, and checkpoint_last_ledger_seq). Requires PAYBOND_API_KEY with Signal analytics read access and the private-dashboards feature. Do not use this when you need a portable signed operator list for partner or verifier sharing—call paybond_get_signed_portfolio_artifact instead—or for one operator's signed receipt—call paybond_get_reputation_receipt. Idempotent read with no side effects; auth, RBAC, feature, or gateway failures surface as tool errors.
| Name | Required | Description | Default |
|---|---|---|---|
| score_version | No | Optional Signal score model version to query. Omit to use the gateway default current model (1.0). Example: 1.0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tenant_id | No | Tenant echoed by the gateway for the authenticated API key (example: tenant-a). |
| average_score | No | Average operator score across the tenant portfolio for this score model version. |
| scoring_model | No | Scoring model identifier used by Signal for this summary. |
| operator_count | No | Number of operators with reputation data for this score model version. |
| schema_version | No | Portfolio summary schema version (currently 1). |
| score_model_version | No | Score model version used for the aggregate (echoes the requested score_version or the gateway default 1.0). |
| operators_under_review | No | Count of operators currently under Signal review for this score model version. |
| total_terminal_intents | No | Aggregate terminal Harbor intents across operators in the portfolio. |
| checkpoint_last_ledger_seq | No | Last ledger sequence included in the tenant Signal checkpoint. |
| total_receipted_volume_cents | No | Aggregate receipted settlement volume in cents across the portfolio. |
paybond_get_principalGet Paybond PrincipalARead-only
Use this when you need to confirm which tenant-bound service-account principal the configured PAYBOND_API_KEY authenticates as (tenant_id, subject, and roles). Call early as a prerequisite before Harbor escrow, Signal reads, or other tenant-scoped tools when tenant identity is unknown. Not required before every later call once tenant_id is already known from a prior principal response or host config. Do not use this when you need Harbor intent escrow detail; use paybond_get_intent instead when you have an intent_id. Do not use this for A2A discovery; use paybond_get_a2a_agent_card instead. Makes one read-only external GET to the gateway principal endpoint; idempotent identity lookup with no side effects (no mutations, spend reservations, escrow changes, or ledger writes); auth or gateway failures surface as tool errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| roles | No | RBAC roles granted to this principal for the authenticated tenant (example: ["operator"]). |
| subject | No | Service-account subject identifier echoed by the gateway for the authenticated API key (example: service-account-1). |
| tenant_id | No | Tenant bound to the configured Paybond API key. |
paybond_get_reputation_receiptGet Reputation ReceiptARead-only
Use this when you need the signed Signal reputation receipt for one known tenant-scoped operator DID (score, metrics, reason codes, and Ed25519 signing material under receipt). Requires PAYBOND_API_KEY with Signal analytics read access. Do not use this for tenant-wide aggregates—call paybond_get_portfolio_summary—or a portable signed operator list—call paybond_get_signed_portfolio_artifact—or one operator's fraud review posture—call paybond_get_fraud_assessment. Idempotent read with no side effects; returns null when no receipt exists for that operator and score_version.
| Name | Required | Description | Default |
|---|---|---|---|
| operator_did | Yes | Tenant-scoped operator DID whose signed Signal reputation receipt to fetch. Must belong to the authenticated tenant; do not invent tenant identifiers. Examples: did:web:vendor.example#booker-agent, did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK. | |
| score_version | No | Optional Signal score model version to query. Omit to use the gateway default current model (1.0). Example: 1.0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| receipt | No | Signed Signal receipt for the operator (tenant_id, operator_did, score_version, score, metrics, reason_codes, signing_algorithm, message_digest_hex, signing_public_key_hex, signature_hex). |
| updated_at | No | RFC3339 timestamp when the stored receipt row was last updated. |
| schema_version | No | Reputation receipt envelope schema version. |
paybond_get_settlement_receipt_v1Get Settlement ReceiptARead-only
Fetch the signed protocol-v2 settlement receipt for one Harbor intent.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| intent_id | No | |
| tenant_id | Yes | |
| receipt_id | Yes |
paybond_get_signed_portfolio_artifactGet Signed Portfolio ArtifactARead-only
Use this when you need a portable, tenant-scoped signed Signal portfolio snapshot (operator list plus Ed25519 signing material) for offline verifier checks or partner sharing—not a public leaderboard. Requires PAYBOND_API_KEY with Signal analytics read access. Omit score_version to use the gateway default current model (1.0). Do not use this for tenant-wide aggregates without signatures—call paybond_get_portfolio_summary—or for one operator's signed receipt—call paybond_get_reputation_receipt—or for one operator's fraud review posture—call paybond_get_fraud_assessment. Idempotent read with no side effects; auth, RBAC, feature, or gateway failures surface as tool errors.
| Name | Required | Description | Default |
|---|---|---|---|
| score_version | No | Optional Signal score model version to query. Omit to use the gateway default current model (1.0). Example: 1.0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Artifact kind identifier (currently paybond.signal.portfolio_snapshot). |
| tenant_id | No | Tenant echoed by the gateway for the authenticated API key (example: tenant-a). Never invent tenant identifiers. |
| signature_hex | No | Ed25519 signature hex over the canonical portfolio artifact payload. |
| score_model_version | No | Score model version used for the artifact (echoes the requested score_version or the gateway default 1.0). |
| checkpoint_last_ledger_seq | No | Last ledger sequence included in the tenant Signal checkpoint for this artifact. |
paybond_import_agent_mandate_v1Import Agent MandateA
Import a signed AgentMandateV1 through the gateway v2 protocol route and bind it to one Harbor intent using a replay-safe recognition proof.
| Name | Required | Description | Default |
|---|---|---|---|
| intent_id | Yes | ||
| signed_mandate | Yes | ||
| recognition_proof | Yes | ||
| transport_binding | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | No | |
| intent_id | No | |
| authorization_receipt | No | |
| mandate_digest_sha256_hex | No |
paybond_list_a2a_task_contractsList A2A Task ContractsARead-only
Fetch the published catalog of Paybond A2A task contracts for delegated Harbor workflows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| contracts | No |
paybond_list_audit_exportsList Audit ExportsARead-only
List tenant-scoped compliance audit export jobs through the gateway operator view.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobs | No | |
| next_cursor | No | |
| tenant_realm_id | No |
paybond_list_intentsList Harbor IntentsARead-only
List tenant-scoped Harbor intents through the gateway operator view with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No | ||
| operator_did | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | No | |
| next_cursor | No |
paybond_submit_evidenceSubmit Harbor EvidenceA
Use this when you already have a Harbor evidence request body and recognition proof for the gateway /harbor/intents/{id}/evidence route. Do not use this for the high-level spend-control path unless you need the low-level Harbor API; prefer paybond_submit_spend_evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| intent_id | Yes | ||
| idempotency_key | No | ||
| recognition_proof | Yes | ||
| completion_preset_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| intent_id | No | |
| evidence_id | No |
paybond_submit_sandbox_guardrail_evidenceSubmit Sandbox Guardrail EvidenceA
Use this when a sandbox guardrail intent needs evidence to complete simulator settlement or predicate checks. Do not use this for live Harbor spend evidence; use paybond_submit_spend_evidence for production spend intents.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | ||
| metadata | No | ||
| artifacts | No | ||
| intent_id | Yes | Sandbox guardrail intent UUID. | |
| operation | No | Optional operation override for the evidence record. | |
| idempotency_key | No | ||
| completion_preset_id | No | ||
| requested_spend_cents | No | Optional sandbox spend amount override for the evidence record. |
Output Schema
| Name | Required | Description |
|---|---|---|
| intent_id | Yes | |
| operation | Yes | |
| tenant_id | Yes | |
| payload_digest | No | |
| predicate_passed | No | |
| requested_spend_cents | Yes | |
| sandbox_lifecycle_status | Yes |
paybond_submit_spend_evidenceSubmit Spend EvidenceA
Use this when a Paybond spend intent needs signed evidence so release, refund, review, and receipt generation use the same audit-ready record. Do not use this to create or fund intents, and do not use it for sandbox guardrail evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| intent_id | Yes | ||
| idempotency_key | No | ||
| recognition_proof | Yes | ||
| completion_preset_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| intent_id | No | |
| evidence_id | No |
paybond_validate_completion_evidenceValidate Completion EvidenceARead-only
Pre-validates vendor and canonical completion evidence against catalog JSON Schemas and preset forbidden_evidence_fields. Required before evidence submit tools when PAYBOND_MCP_EVIDENCE_POLICY=strict. Harbor remains authoritative at submit time.
| Name | Required | Description | Default |
|---|---|---|---|
| preset_id | Yes | ||
| vendor_payload | No | ||
| canonical_payload | No | ||
| frozen_vendor_api_version | No | ||
| frozen_vendor_schema_digest_hex | No | ||
| frozen_canonical_schema_digest_hex | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| preset_id | Yes | |
| pack_stale | No | |
| drift_kinds | No | |
| vendor_schema_ok | No | |
| canonical_schema_ok | No | |
| quality_fields_missing | No | |
| forbidden_fields_present | No |
paybond_verify_agent_mandate_v1Verify Agent MandateARead-only
Verify a signed AgentMandateV1 envelope through the gateway v2 protocol surface.
| Name | Required | Description | Default |
|---|---|---|---|
| signed_mandate | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | No | |
| mandate_digest_sha256_hex | No |
paybond_verify_agent_receipt_v1Verify Agent ReceiptARead-only
Use this when you already have a signed paybond.agent_receipt_v1 JSON object and need an offline operational-tier (default) Ed25519 signature check—schema, digest, and Gateway signature—matching resources/read on paybond://receipt/{receipt_id}. Optional validity_tier=primary|attested raises the bar (payee digest / operator attestation). Do not use this for protocol authorization/settlement receipts—call paybond_verify_protocol_receipt_v1. Continuity-chain audits, inclusion proofs, owner disclosure, and ACTA/PEF/SCITT are Kit/CLI/Gateway auditor surfaces. Read-only and side-effect free: success returns valid=true with kind, receipt_id, tenant_id, and the normalized receipt; failures raise a clear verification error.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | Complete signed paybond.agent_receipt_v1 object (not a receipt_id string). Obtain from paybond_get_agent_receipt_v1, paybond://receipt/{receipt_id}, audit export (agent_receipts/{id}.json; PEF companions may also appear as *.pef.json), or partner handoff—do not invent digests or signatures. | |
| validity_tier | No | Optional validity bar: operational (default), primary, or attested. Higher tiers are auditor-oriented; MCP handoff only requires operational. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Verified receipt kind (paybond.agent_receipt_v1). |
| valid | No | True when operational (or requested) validity checks passed. Example: true. |
| receipt | No | Normalized verified paybond.agent_receipt_v1 object. |
| tenant_id | No | Tenant id embedded in the verified receipt (not invented by the caller). |
| receipt_id | No | Canonical receipt identifier from the verified receipt. |
| validity_tier | No | Requested validity tier used for this verify (operational, primary, or attested). |
paybond_verify_agent_recognition_proof_v1Verify Agent Recognition ProofARead-only
Verify a replay-safe AgentRecognitionProofV1 against an expected purpose and request envelope. Verifier context (tenant_id, verifier_id) is derived from the authenticated MCP session only.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | Yes | ||
| expected_purpose | Yes | ||
| expected_request | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| proof | No | |
| valid | No |
paybond_verify_capabilityVerify Paybond CapabilityA
Use this when you need raw capability-token verification for one tenant-bound Harbor intent. Do not use this to create, fund, or modify intents; use paybond_authorize_agent_spend as the clearer gate before side-effecting agent tools.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional capability token override. When omitted, the MCP server uses the token stored for intent_id. | |
| intent_id | Yes | Canonical Harbor intent UUID. | |
| operation | Yes | Delegated operation or tool name. | |
| requested_spend_cents | No | Optional requested spend in cents for this tool call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| allow | No | Whether the requested operation is allowed. |
| tenant | Yes | Tenant echoed by the gateway. |
| message | No | Human-readable decision message when present. |
| audit_id | No | Gateway audit identifier when available. |
| intent_id | Yes | Verified Harbor intent UUID. |
| decision_id | No | Persisted spend decision identifier when authorization creates one. |
| reason_codes | No | Stable spend-policy reason codes from the authorization decision. |
| remaining_cents | No | Remaining spend budget in cents for the evaluated scope, when available. |
| approval_request_id | No | Approval request identifier when human approval is required. |
paybond_verify_protocol_receipt_v1Verify Protocol ReceiptARead-only
Use this when you already have a signed protocol-v2 authorization or settlement receipt JSON object and need offline Ed25519 verification (structure, message digest, and signature) through the gateway. Do not use this to verify AgentMandateV1 envelopes—call paybond_verify_agent_mandate_v1—or to check a Harbor capability token before spend—call paybond_verify_capability or paybond_authorize_agent_spend. To load a settlement receipt by intent UUID first, call paybond_get_settlement_receipt_v1 then pass its body here. Read-only and side-effect free: success returns valid=true with kind, receipt_id, tenant_id, and the normalized receipt; unsupported kind, malformed JSON, digest mismatch, or bad signature fail with a gateway error (typically HTTP 400).
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | Complete signed protocol receipt object posted as the verify request body (not a receipt_id string). Discriminate on kind: paybond.protocol_authorization_receipt_v1 requires schema_version=1, receipt_version="1", receipt_id, issued_at, status (authorized), intent_id, tenant_id, verifier_id, transport_binding, mandate_digest_sha256_hex, imported_mandate_signing_public_key_ed25519_hex, authorization, agent, allowed_actions, allowed_tools, spend_ceiling, settlement, constraint, expires_at, nonce, human_presence_mode, plus signing_algorithm=ed25519-sha256-json-v1, message_digest_sha256_hex, signing_public_key_ed25519_hex, and ed25519_signature_hex. paybond.protocol_settlement_receipt_v1 requires schema_version=1, receipt_version="1", receipt_id, issued_at, intent_id, tenant_id, verifier_id, transport_binding, authorization_receipt_id, mandate_digest_sha256_hex, harbor_state, settlement_rail, settlement_mode, principal_did, payee_did, currency, amount_cents, terminal_observed_at, optional predicate_passed, and the same Ed25519 signing fields. Obtain receipts from mandate import, paybond_get_settlement_receipt_v1, audit export, or partner handoff—do not invent digests or signatures. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Verified receipt kind echoed from the normalized receipt. One of paybond.protocol_authorization_receipt_v1 or paybond.protocol_settlement_receipt_v1. |
| valid | No | True when the gateway accepted the receipt structure and Ed25519 signature. Example: true. |
| receipt | No | Normalized verified receipt object matching the input kind (authorization or settlement fields plus signing material). |
| tenant_id | No | Tenant id embedded in the verified receipt (not invented by the caller). |
| receipt_id | No | Canonical receipt identifier from the verified receipt. |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
8 tool updates
- Added
paybond_authorize_agent_spend - Added
paybond_bootstrap_sandbox_guardrail - Added
paybond_explain_policy - Added
paybond_get_budget_remaining - Added
paybond_get_principal - Added
paybond_submit_sandbox_guardrail_evidence - Added
paybond_validate_completion_evidence - Added
paybond_verify_capability
12 tool updates
v0.12.12- Added
paybond_get_a2a_agent_card - Added
paybond_get_audit_export - Added
paybond_get_fraud_assessment - Added
paybond_get_fraud_metrics - Added
paybond_get_intent - Added
paybond_get_portfolio_summary - Added
paybond_get_reputation_receipt - Added
paybond_get_signed_portfolio_artifact - Added
paybond_list_a2a_task_contracts - Added
paybond_list_audit_exports - Added
paybond_list_intents - Removed
paybond_submit_sandbox_guardrail_evidence
4 tool updates
v0.12.12- Removed
paybond_explain_policy - Added
paybond_get_a2a_task_contract - Added
paybond_submit_sandbox_guardrail_evidence - Added
paybond_submit_spend_evidence
20 tool updates
v0.12.11- Removed
paybond_authorize_agent_spend - Removed
paybond_bootstrap_sandbox_guardrail - Removed
paybond_get_a2a_agent_card - Removed
paybond_get_a2a_task_contract - Removed
paybond_get_audit_export - Removed
paybond_get_budget_remaining - Removed
paybond_get_fraud_assessment - Removed
paybond_get_fraud_metrics - Removed
paybond_get_intent - Removed
paybond_get_portfolio_summary - Removed
paybond_get_principal - Removed
paybond_get_reputation_receipt - Removed
paybond_get_signed_portfolio_artifact - Removed
paybond_list_a2a_task_contracts - Removed
paybond_list_audit_exports - Removed
paybond_list_intents - Removed
paybond_submit_sandbox_guardrail_evidence - Removed
paybond_submit_spend_evidence - Removed
paybond_validate_completion_evidence - Removed
paybond_verify_capability
2 tool updates
v0.12.7- Added
paybond_get_agent_receipt_v1 - Added
paybond_verify_agent_receipt_v1
TDQS
Scored across 31 tools
The descriptions contain strong cross-references, but the tool set still has several overlapping families: low-level versus high-level intent creation/evidence submission, multiple receipt get/verify tools, and multiple Signal analytics reads. An agent can pick the wrong tool without carefully reading the lengthy do-not-use guidance.
Every tool follows the same paybond_<verb>_<noun> snake_case pattern, with protocol-versioned tools consistently marked _v1. The high-level and low-level pairs use clear qualifiers like spend_intent versus intent, so the naming convention is uniform and predictable.
Thirty-one tools is well beyond the typical well-scoped range and makes the server feel heavy. Several tools could be consolidated into shared families or split into separate servers by domain, such as Harbor intents, Signal analytics, A2A discovery, and receipt verification.
The descriptions reference paybond_fund_intent as a prerequisite for spend authorization, but that tool is not exposed in this set. The Harbor intent lifecycle also lacks visible update, cancel, release, or refund tools, so an agent cannot complete a full end-to-end spend workflow without hitting dead ends.
Maintenance
Related MCP Connectors
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Agent-native MCP for governed commerce, x402 payments, paid capabilities, and verifiable receipts.
PHANTOM ID MCP payment server: agent-to-agent USDC payments on Base.
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server for AgentPay — the payment gateway for autonomous AI agents. Fund a wallet once, give your agent the key, and it discovers, provisions, and pays for tool APIs on its own. One key, every tool.112 npm1MIT
- AlicenseAqualityDmaintenanceMCP server for l402-kit — enables AI agents (Claude, Cursor, etc.) to autonomously pay Bitcoin Lightning-protected APIs. Tools: l402_fetch, l402_balance, l402_spending_report. Run with: npx l402-kit-mcp4169 npm4MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for Pact, an escrow protocol for agent-to-agent commerce, enabling agents to create pacts, fund escrow, deliver work, and settle with an LLM evaluator as dispute backstop.20 npmMIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI agents to safely interact with a double-entry payments ledger, enforcing idempotency, policy-based access control, and human-in-the-loop approval for high-value actions.-