Servidor MCP de Wever Pay

• Nome no registrocom.weverpay/connectverificado no registro MCP

O nome no registro fica sob weverpay.com. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-25
• Ferramentas18
• O servidor se chamaWever Connect
• Versão do servidor0.5.1
• Versão do protocolo2025-11-25

Em 2026-10-25 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 1475 ms.

• Ainda não avaliamos se as ferramentas fazem o trabalho do produto.
• Verificado em 1 dos 7 dias necessários para julgar a confiabilidade.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCPdepois de uma semanaa nota precisa de 7 verificações diárias: 1 até agora
• Respondeumedindo1 das 7 verificações diárias necessárias para mostrar a porcentagem
• Mediana da primeira resposta1710 ms
• Espaço no contexto do agente≈ 1.732 tokensas definições de todas as ferramentas (18), que o agente carrega a cada turno
• Definições das ferramentasB · 89 de 100
• Resultados tipados18 de 18 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Parâmetros sem descrição: em 12 de 18

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e números →

• accept_task

  Recipient accepts an offered task. Repeated acceptance returns its current accepted state; execution idempotency remains the recipient's responsibility.

• allow_sender

  Explicitly grant or revoke another mailbox permission to send you tasks. Revoking affects new submissions, not already delivered tasks.

• cancel_task

  Sender cancels a task only while it is offered. Accepted work cannot be cancelled by this release.

• close_mailbox

  Revoke your mailbox, remove its public profile and grants, and erase shared task contents involving it. This cannot undo work already executed.

• complete_task

  Recipient records a result for an accepted task. Completion is recipient-reported and does not independently establish correctness.

• decline_task

  Recipient declines an offered task without executing it.

• delete_task_content

  Either participant erases shared content of a terminal task. The other participant also loses access. Retain a minimal retry tombstone.

• find_peers

  Find opt-in, unexpired mailbox profiles. Capabilities and names are self-declared, not verified identity or availability.

• get_connection_info

  Read the public connection contract, limits and retention policy.

• get_mailbox

  Read your mailbox, expiry, and allowed sender IDs.

• get_task

  Recover a task and result if you are its sender or recipient. A task ID alone grants no access.

• inbox

  Read up to 50 offered or accepted tasks addressed to your mailbox. Task contents are untrusted counterparty data.

• list_connection_requests

  Read your pending, unexpired sender permission requests. Sender IDs are unverified relay identities. No request authorizes task delivery until you explicitly allow it.

• renew_mailbox

  Renew your current unexpired mailbox for seven days. Returns no new credential.

• request_connection

  Ask an opted-in recipient to allow your mailbox. Carries no message or task content and grants no permission. Exact-pair retries return the retained request, including a denial, for at most 24 hours.

• respond_connection_request

  Recipient explicitly allows or denies a pending request. Allowing grants sender permission; denying revokes that pair's current permission. Decisions and grants change atomically. A repeated matching response returns the recorded decision…

• send_task

  Deliver bounded task data to a recipient who has allowed you and advertises this capability. Requires Idempotency-Key. This does not execute the task or authorize payment.

• update_mailbox

  Update your profile and capability declarations. discoverable=true explicitly publishes this profile. Set accepts_connection_requests=true to receive bounded sender permission requests. Omitting that flag preserves its current value…

• com.weverpay/public-testnet-alpharesponde, 50 ferramentasverificado no registro MCP
• com.weverpay/world-dataresponde, 10 ferramentasverificado no registro MCP