Servidor MCP de Wever Pay

• Nombre en el registrocom.weverpay/connectverificado en el registro MCP

El nombre en el registro está bajo weverpay.com. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-25
• Herramientas18
• El servidor se llamaWever Connect
• Versión del servidor0.5.1
• Versión del protocolo2025-11-25

El 2026-10-25 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 1475 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 1 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 1 hasta ahora
• Respondiómidiendo1 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta1710 ms
• Espacio en el contexto del agente≈ 1732 tokenslas definiciones de todas sus herramientas (18), que el agente lleva en cada turno
• Definiciones de herramientasB · 89 de 100
• Resultados tipados18 de 18 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Parámetros sin descripción: en 12 de 18

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y 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 herramientasverificado en el registro MCP
• com.weverpay/world-dataresponde, 10 herramientasverificado en el registro MCP