Paybond MCP Server

Ferramentas MCP vinculadas a inquilinos para autorização de gastos, evidências, recibos e liquidação de agentes no Cursor, Codex e Claude Code.

Ver em paybond.aiExperimente este MCPPatrocinado

Documentação

Um host MCP entrega ao seu agente ferramentas que podem cobrar dinheiro real. Um limite por transação não ajuda muito: doze chamadas de ferramenta de $399 sob um limite de $500 ainda totalizam $4.788, porque cada aprovação não tem memória da anterior — e uma cobrança aprovada não é prova de que o trabalho foi realizado.

O Paybond fornece um servidor MCP vinculado ao tenant que elimina essa lacuna. Ele vincula gastos delegados a uma intenção assinada, libera ou reembolsa com base em evidências de conclusão enviadas e retorna um recibo que o financeiro pode reproduzir — preservando o mesmo limite de tenant dos SDKs e APIs. Use-o para runtimes de agentes internos e sistemas de orquestração que preferem MCP a wrappers HTTP personalizados.

Superfície de adaptador de primeira classe. Hosts MCP são um caminho de integração de framework suportado, juntamente com adaptadores in-process — consulte Middleware de agente, Configuração de agente de codificação e a Matriz de suporte do Kit.

Para configuração de agente de codificação, incluindo Codex e trechos MCP stdio genéricos usando npx -y -p @paybond/kit paybond-mcp-server, comece com Configuração de agente de codificação.

Para uma primeira integração de guardrail fora do MCP, comece com o scaffold de sandbox:

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

Para hosts nativos MCP, as ferramentas de sandbox correspondentes são paybond_bootstrap_sandbox_guardrail e paybond_submit_sandbox_guardrail_evidence.

O servidor é stdio-first por padrão — a maioria dos hosts de desktop o inicia como um processo filho local. Hosts que precisam de uma URL de rede podem usar o endpoint HTTP Streamable hospedado ou auto-hospedar o mesmo transporte HTTP; consulte HTTP remoto (Streamable HTTP) abaixo.

O Paybond não assume um provedor de modelo ou framework de agente específico. A única suposição é que seu host possa falar chamadas de ferramenta MCP, seja via stdio ou Streamable HTTP.

Instalação

npm install @paybond/mcp

Importe de @paybond/mcp

import { createPaybondMcpToolSurface } from "@paybond/mcp";

Subcaminho equivalente no pacote principal: @paybond/kit/mcp\ — use @paybond/kit\ quando precisar de vários adaptadores em um único aplicativo.
Para hosts MCP stdio, execute npx -y -p @paybond/kit paybond-mcp-server — consulte Configuração de agente de codificação na documentação.
Python: paybond agent demo mcp smoke\ requer o extra opcional mcp\. Use pip install "paybond-kit\[mcp\]"\, pipx install 'paybond-kit\[mcp\]'\ ou pipx inject paybond-kit mcp\ (quando o paybond-kit base já estiver instalado).
Smoke: paybond agent demo mcp smoke --operation paid-tool --requested-spend-cents 100 --evidence-preset cost\_and\_completion --format json\ (MCP in-process).

Ambiente obrigatório

Sempre obrigatório. Para configuração de sandbox, use um dos CLIs de login primeiro:

npx -p @paybond/kit paybond login
paybond-kit-login
npx -p @paybond/kit paybond login
paybond-kit-login

Os CLIs gravam PAYBOND_API_KEY em .env.local; os servidores MCP empacotados carregam .env.local por padrão quando PAYBOND_API_KEY não está presente. Defina PAYBOND_ENV_FILE para um arquivo de segredos local diferente, ou passe PAYBOND_API_KEY no ambiente de inicialização do host MCP. Chaves de produção são criadas no Console e armazenadas em gerenciadores de segredos de implantação.

Chaves MCP restritas (recomendado para hosts)

Para Cursor, Claude Desktop, Codex e outros hosts MCP, prefira uma chave restrita (paybond_rk_*) em vez de uma chave padrão de conta de serviço (paybond_sk_*). Chaves restritas carregam uma concessão de escopo MCP explícita; tools/list e tools/call expõem apenas as ferramentas que esses escopos desbloqueiam, e o gateway aplica os mesmos escopos nas rotas subjacentes. Chaves padrão mantêm RBAC baseado em função e PAYBOND_MCP_TOOL_POLICY opcional para desenvolvimento local.

Crie uma no Console (Acesso de máquina → Chaves de API → Chave MCP restrita) ou no 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

Predefinições (liquidação / escrita de dinheiro real nunca é incluída — adicione --scope mcp.settlement:write somente quando precisar intencionalmente de fundo/confirmação):

Predefinição	Escopos
`mcp-readonly`	discovery, signal, compliance, receipts (leitura)
`mcp-spend-operator`	readonly + spend + evidence (escrita)
`mcp-sandbox-agent`	discovery + sandbox + spend (escrita)

Liste o catálogo (offline):

paybond mcp scopes list
paybond mcp scopes list --format json
paybond mcp scopes list
paybond mcp scopes list --format json

Quando mcp install detecta uma chave restrita no arquivo de ambiente, ele omite PAYBOND_MCP_TOOL_POLICY da configuração de host gerada — os escopos vêm da chave. Parear --tool-policy / --tool-allowlist com uma chave restrita é rejeitado.

Opcional:

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_POLICY padrão é strict. No modo estrito, as ferramentas de envio de evidências recusam chamadas até que paybond_validate_completion_evidence tenha sucesso para o mesmo preset e payload. Defina off apenas para depuração local. A validação de predicado e esquema do Harbor permanece autoritativa no momento do envio.

Recarga opcional de política para processos MCP de longa duração:

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"

Quando PAYBOND_POLICY_FILE está definido, paybond_authorize_agent_spend e paybond_verify_capability aplicam o registro de políticas antes da verificação do Harbor. Os limites de gastos são resolvidos a partir do arquivo de política quando requested_spend_cents é omitido. A recarga aguarda a conclusão das chamadas de ferramenta MCP em andamento antes de trocar o registro; recargas com falha mantêm o snapshot anterior. Use poll com políticas de sobreposição de tenant para atualizar a política efetiva do Gateway.

Execução

Python

paybond-mcp-server
paybond-mcp-server

TypeScript

npx paybond-mcp-server
npx paybond-mcp-server

HTTP remoto (Streamable HTTP)

Stdio continua sendo o padrão para hosts de desktop (Cursor, Claude Desktop, Codex CLI). Para hosts que precisam de uma URL de rede em vez de um subprocesso local — runtimes de agentes remotos, modo HTTP do MCP Inspector ou qualquer orquestrador que não possa iniciar processos filhos — o Paybond também executa a mesma superfície de ferramentas via Streamable HTTP, o transporte remoto atual do MCP (um único POST /mcp com resposta JSON; sem HTTP+SSE legado).

Endpoint hospedado: 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"}'

Cada requisição fornece sua própria chave de conta de serviço ou chave MCP restrita como Authorization: Bearer paybond_sk_... ou Bearer paybond_rk_... — o endpoint hospedado é multi-tenant e sem estado: o escopo do tenant vem apenas da chave (nunca de um tenant_id fornecido pelo cliente), e cada requisição é tratada de forma independente, sem nada em cache ou compartilhado entre chamadores. Chaves restritas filtram a superfície de ferramentas por requisição a partir de principal.mcp_scopes. Como não há sessão por conexão, sempre passe capability_token explicitamente para paybond_authorize_agent_spend / paybond_verify_capability em vez de confiar que o token será lembrado de uma chamada anterior no mesmo processo (essa conveniência se aplica apenas a uma única sessão stdio de longa duração).

Exemplo de configuração de cliente MCP para um host com capacidade HTTP (prefira uma chave restrita em produção):

{
  "url": "https://mcp.paybond.ai/mcp",
  "headers": {
    "Authorization": "Bearer paybond_rk_sandbox_..."
  }
}
{
  "url": "https://mcp.paybond.ai/mcp",
  "headers": {
    "Authorization": "Bearer paybond_rk_sandbox_..."
  }
}

Auto-hospedagem do mesmo contrato: ambos os CLIs do Kit podem executar o contrato idêntico Bearer/Origin//healthz localmente em vez de depender do endpoint hospedado:

# 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

O CLI Python vincula-se a um tenant durante a vida do processo: defina PAYBOND_API_KEY no ambiente do processo e cada token Bearer recebido é verificado contra essa única chave (um portão de segredo compartilhado no acesso à rede, não uma forma de atender vários tenants a partir de um processo). O CLI TypeScript é multi-tenant como o endpoint hospedado — ele deriva o escopo do tenant por requisição a partir da chave que o chamador apresenta. Ambos aceitam as mesmas variáveis de ambiente PAYBOND_MCP_HTTP_*:

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 /healthz retorna 200 sem autenticação para verificações de saúde de balanceadores de carga e contêineres. PAYBOND_POLICY_RELOAD=watch|poll (recarga de política) é rejeitado na inicialização HTTP — depende de uma instância de processo de longa duração e só é suportado para stdio; use PAYBOND_POLICY_RELOAD=off (o padrão) ou omita-o ao executar HTTP.

Categorias de ferramentas

Descoberta somente leitura e conformidade (permitidas sob --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

Ferramentas de gasto e mutação (padrão --tool-policy spend-write; ferramentas de dinheiro real como paybond_fund_intent e paybond_confirm_settlement permanecem bloqueadas a menos que explicitamente permitidas):

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

Para hosts de produção, crie uma chave restrita (consulte Chaves MCP restritas) para que a própria credencial limite a superfície de ferramentas. Para instalações locais com chave padrão, uma política de ambiente somente leitura ainda funciona:

# 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

Verificação local de pacote de auditoria (paybond audit exports verify <path> ou paybond.audit.exports.verify(...)) é apenas SDK/CLI. Hosts MCP não podem verificar caminhos ZIP baixados no disco. Pacotes de conformidade que incluem agent_receipts também podem conter arquivos companheiros PEF (*.pef.json) junto com cada recibo assinado.

As ferramentas nomeadas para gastos são aliases sobre as mesmas rotas Harbor e Gateway vinculadas ao tenant. Elas existem para que hosts de agentes possam atender solicitações de usuários como "controlar gastos do agente", "adicionar limites de gastos por chamada de ferramenta" ou "autorizar ações pagas de fornecedores" sem adivinhar a partir de nomes de capacidades de nível inferior.

paybond_get_budget_remaining e paybond_explain_policy chamam a rota de gateway sem efeitos colaterais POST /v1/spend/preflight. Elas avaliam a mesma política de controle de gastos que authorize sem criar decisões, reservas ou solicitações de aprovação. Use-as antes de paybond_authorize_agent_spend quando um agente precisar de orçamento restante ou uma explicação legível de allow / approval_required / deny. Comandos CLI correspondentes: paybond spend budget-remaining e paybond spend explain-policy.

paybond_verify_protocol_receipt_v1 é uma verificação offline somente leitura de um recibo de autorização ou liquidação assinado em protocolo v2 (POST /protocol/v2/receipts/verify). Passe o objeto de recibo completo (não um receipt_id). Use paybond_verify_agent_mandate_v1 para envelopes de mandato e paybond_verify_capability / paybond_authorize_agent_spend para portões de capacidade do Harbor. Busque um recibo de liquidação primeiro com paybond_get_settlement_receipt_v1 quando você tiver apenas um UUID de intenção.

paybond_get_agent_receipt_v1 busca um paybond.agent_receipt_v1 assinado por receipt_id (GET /protocol/v2/agent-receipts/{receipt_id} vinculado ao tenant). paybond_verify_agent_receipt_v1 executa a mesma verificação de assinatura de nível operacional offline que resources/read em paybond://receipt/{receipt_id}; passe validity_tier=primary|attested opcional quando precisar de um padrão mais forte. Cadeia de continuidade, provas de inclusão, divulgação de proprietário e adaptadores ACTA/PEF/SCITT permanecem superfícies do Kit TypeScript/Python e CLI/Gateway auditor — não o trabalho completo do MCP.

paybond_get_principal retorna o principal de conta de serviço vinculado ao tenant para o PAYBOND_API_KEY configurado (tenant_id, subject, roles) via um GET de gateway somente leitura. Use-o quando precisar confirmar a identidade de autenticação; chame cedo como pré-requisito antes de chamadas de ciclo de vida de intenção, leituras de Signal ou outras ferramentas com escopo de tenant quando a identidade do tenant for desconhecida. Não é necessário antes de cada chamada posterior uma vez que tenant_id já é conhecido. Não use quando precisar de detalhes de intenção — use paybond_get_intent quando tiver um intent_id. Não use para descoberta A2A — use paybond_get_a2a_agent_card.

paybond_get_portfolio_summary retorna um agregado de Signal com escopo de tenant (contagens, pontuação média, volume, operadores em revisão). Omita score_version para usar o padrão do gateway (1.0). Prefira paybond_get_signed_portfolio_artifact quando precisar de uma lista assinada portátil de operadores para compartilhamento com parceiros ou verificadores, e paybond_get_reputation_receipt para um único operador.

paybond_get_signed_portfolio_artifact retorna um snapshot de portfólio Signal assinado com escopo de tenant (lista de operadores mais material de assinatura Ed25519) para verificações offline de verificadores ou compartilhamento com parceiros. Omita score_version para usar o padrão do gateway (1.0). Prefira paybond_get_portfolio_summary para agregados não assinados, paybond_get_reputation_receipt para um único operador e paybond_get_fraud_assessment para postura de revisão de fraude.

paybond_get_fraud_metrics retorna métricas de backtesting de fraude em todo o tenant para uma janela móvel (padrão 24h, ou 7d / 30d). Janelas não suportadas falham com HTTP 400. Use paybond_get_fraud_assessment quando precisar da postura de fraude de um único operador em vez de agregados do tenant. paybond_get_reputation_receipt busca o recibo de reputação de Signal assinado para um DID de operador (GET /reputation/{operator_did}). Omita score_version para usar o padrão do gateway (1.0). Retorna null quando não existe recibo. Prefira paybond_get_portfolio_summary para agregados de tenant, paybond_get_signed_portfolio_artifact para uma lista assinada portátil de operadores e paybond_get_fraud_assessment para postura de revisão de fraude.

As ferramentas de proteção de sandbox são auxiliares separadas apenas para desenvolvedores. Elas chamam /v1/sandbox/guardrails/..., derivam o escopo do tenant da chave de API da conta de serviço configurada e não substituem as ferramentas de criação/financiamento/evidência do Harbor em produção.

Fluxo de gasto típico

Chame paybond_create_spend_intent para criar a intenção de gasto assinada.
Se a intenção não for financiada imediatamente, chame paybond_fund_intent.
Opcionalmente, chame paybond_get_budget_remaining ou paybond_explain_policy para uma verificação prévia somente leitura do orçamento restante e do resultado da política.
Use o intent_id e o capability_token retornados com paybond_authorize_agent_spend antes de qualquer chamada de API paga, ação de fornecedor, etapa de liquidação ou outra ferramenta com efeitos colaterais.
Chame paybond_validate_completion_evidence com o preset de conclusão e o payload que você planeja enviar.
Após a conclusão do trabalho protegido, chame paybond_submit_spend_evidence com o mesmo preset e payload.

Se você estiver escrevendo código SDK em vez de expor ferramentas MCP, use paybond.spendGuard(intentId, capabilityToken) em TypeScript ou paybond.spend_guard(intent_id, capability_token) em Python. PaybondCapabilityBinding só é necessário para adaptadores de framework Python que exigem um objeto de contexto de execução.

Fluxo de teste de fumaça de proteção de sandbox

Chame paybond_bootstrap_sandbox_guardrail com uma operação e um valor de gasto de sandbox.
Use o intent_id e o capability_token retornados com paybond_authorize_agent_spend antes que a ferramenta paga de exemplo execute.
Chame paybond_validate_completion_evidence ao usar um preset de conclusão (por exemplo, api_response_ok).
Chame paybond_submit_sandbox_guardrail_evidence com o intent_id de sandbox, completion_preset_id e payload de evidência.

Comando de teste de fumaça integrado

Valide o caminho de autorização e evidência do MCP sem iniciar um subprocesso stdio ou um 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

O teste de fumaça usa PaybondMCPServer.callTool() em processo (TypeScript) ou build_mcp_server().call_tool() (Python): bind de sandbox, paybond_authorize_agent_spend, conclusão de efeito colateral simulada e paybond_submit_sandbox_guardrail_evidence. Python requer o extra opcional mcp (pip install "paybond-kit[mcp]").

Modelo de segurança

O servidor está vinculado a um tenant derivado da chave de API da conta de serviço configurada.
Não passe IDs de tenant manualmente por argumentos de ferramenta para fluxos normais.
Ferramentas de alteração de estado apoiadas pelo gateway exigem o material de prova correto e falham de forma fechada quando as provas estão ausentes, obsoletas, repetidas ou incompatíveis.
Os corpos de solicitação assinados do Harbor permanecem de responsabilidade do chamador. O servidor MCP não gerencia chaves de assinatura de longa duração em nome do modelo.
O endpoint HTTP hospedado (https://mcp.paybond.ai/mcp) aceita:
- Chaves restritas (paybond_rk_*) — preferidas para agentes e automação; os escopos na chave são o modelo de permissão.
  - Chaves padrão (paybond_sk_*) — direitos de função completos; use apenas quando você intencionalmente quiser uma credencial de máquina sem restrições.
  - Tokens de acesso OAuth do MCP (paybond_oat_*) — concessões com escopo de usuário do fluxo de consentimento do Console para hosts interativos (Cursor, Claude, VS Code). Curta duração; renove com paybond_ort_* via POST /v1/oauth/token.
Prefira uma chave restrita de sandbox para testes; para hosts de produção, crie uma chave restrita com os escopos MCP mínimos no Console, ou use o consentimento OAuth para hosts interativos.

Verifique qual credencial uma configuração de host realmente usará:

paybond doctor --mcp --host claude
paybond doctor --mcp --host claude

--mcp falha quando a configuração resolve para uma chave paybond_sk_* sem restrições (o gateway não pode limitar sua superfície MCP) e novamente quando essa chave não é nem mesmo restringida por PAYBOND_MCP_TOOL_POLICY. Passe --config <path> para avaliar uma configuração de host em disco em vez daquela que paybond mcp install geraria.

MCP OAuth (hosts interativos)

Hosts MCP interativos podem obter um bearer com escopo sem incorporar uma chave de API de longa duração:

O host redireciona o navegador para GET /v1/oauth/authorize (PKCE S256, response_type=code).
O Console abre /console/authorize/mcp?request=… para um humano tenant_admin.
O administrador revisa os escopos solicitados / ferramentas visíveis, opcionalmente restringe a concessão e aprova (mcp.settlement:write ao vivo exige etapa adicional de MFA).
O host resgata o código em POST /v1/oauth/token e chama https://mcp.paybond.ai/mcp com Authorization: Bearer paybond_oat_….

Os administradores de tenant gerenciam o kill switch MCP por ambiente, sessões OAuth ativas e URIs de redirecionamento personalizadas em Console → Machine access → MCP access. Desabilitar o MCP bloqueia novas concessões e rejeita bearers paybond_oat_* existentes para esse ambiente.

Exemplo de configuração de cliente MCP

Exemplo de entrada stdio local usando o .env.local padrão escrito por paybond 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"
  }
}

Entrada avançada de chave direta para hosts que não conseguem ler arquivos de ambiente:

{
  "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_..."
  }
}

Recursos de recibos de agente (MCP)

O papel do ARS do MCP é a transferência de recibos entre agentes via URI de recurso paybond://receipt/{receipt_id} — os hosts passam a URI entre agentes sem incorporar JSON completo em prompts.

Item	Valor
Template de URI	`paybond://receipt/{receipt_id}`
Tipo MIME	`application/json`
Fonte	`GET /protocol/v2/agent-receipts/{receipt_id}` vinculado ao tenant
Verificar na leitura	Verificação de assinatura de nível operacional (esquema, digest, Gateway Ed25519)

Servidores stdio TypeScript e Python:

resources/templates/list — publica o template paybond://receipt/{receipt_id}
resources/read — busca o JSON assinado paybond.agent_receipt_v1 e verifica no nível operacional antes de retornar; falha de verificação retorna um erro claro (os conteúdos não são entregues sem assinatura)

Ferramentas somente leitura (mesma superfície das ferramentas de recibo de liquidação):

paybond_get_agent_receipt_v1 — busca por receipt_id
paybond_verify_agent_receipt_v1 — verificação offline de um objeto de recibo; validity_tier opcional (padrão operational, ou primary / attested)

Níveis de validade além de uma verificação rápida de transferência, auditorias de cadeia de continuidade, provas de inclusão / cabeça de árvore Merkle, divulgação confidencial do proprietário e adaptadores de exportação ACTA / PEF / SCITT são superfícies de auditoria do Kit TypeScript/Python, CLI e Gateway — não o trabalho completo do MCP. Use as bibliotecas de cliente do Kit para esses fluxos.

Exportações de auditoria de conformidade que incluem recibos de agente também podem enviar companheiros PEF (*.pef.json) ao lado de cada JSON de recibo assinado.