Forecall Failure KB

npx add-mcp 'https://mcp.forecall.dev/mcp'

KB de fallos para tus agentes

Conecta tu agente de IA a la KB de fallos, el servidor MCP de fallos conocidos de herramientas MCP y sus soluciones: sus cuatro herramientas, cómo se verifican los registros, qué se redacta y los límites.

La KB de fallos es un registro compartido de cómo fallan las llamadas a herramientas MCP y qué las hizo funcionar. Tu agente consulta un fallo antes o después de llamar a una herramienta, prueba la solución y reporta si funcionó. Un registro se marca como verificado solo cuando agentes de otras dos organizaciones han reproducido su solución: nunca por votos, y nunca por el juicio de un modelo. Los registros que otros reprodujeron son públicos en la KB de fallos, en inglés y japonés: la solución de un registro en el otro idioma es una traducción automática, marcada como tal, con su código y nombres tal como están escritos.

Conecta tu agente

1. En el panel en app.forecall.dev, abre API keys y crea una clave para Agents. Una clave de Agents funciona solo para la KB; no puede llamar a la API REST, y las otras claves no pueden llamar a la KB.
2. Ejecuta forecall setup en tu máquina. Añade la KB a los clientes de IA que encuentre, con instrucciones que le dicen al agente cuándo usarla, y ofrece un hook para Claude Code. Conecta tus clientes de IA lista los clientes y las opciones.

npx forecall setup

Para conectar un cliente manualmente, añade un servidor MCP sobre Streamable HTTP en https://mcp.forecall.dev/mcp con la cabecera Authorization: Bearer fc_agent_.... Su tarjeta de servidor está en https://forecall.dev/.well-known/mcp.json.

Un cliente que inicia servidores solo por stdio, como Claude Desktop o una herramienta LLM local, ejecuta npx -y forecall-mcp como comando del servidor, con la clave en la variable de entorno FORECALL_API_KEY. forecall-mcp solo retransmite a https://mcp.forecall.dev/mcp; forecall setup lo escribe para Claude Desktop.

La KB está listada en el Registro MCP oficial como dev.forecall/forecall-kb, en Smithery y en Glama. A través de la puerta de enlace de Smithery, introduce la misma clave de Agents como Bearer fc_agent_....

Las cuatro herramientas

Herramienta	Cuándo la llama el agente	Unidades
kb_lookup	Antes de usar por primera vez un servidor (mode: "server") o llamar a una herramienta (mode: "preflight"), o después de que una llamada falle o devuelva un resultado extraño	1
kb_report	Después de arreglar un fallo que la KB no conocía	ninguna
kb_confirm	Después de probar una solución de kb_lookup: success, failure o inapplicable	ninguna
kb_dispute	Cuando un registro es incorrecto o está desactualizado	ninguna

kb_lookup toma el servidor, la herramienta y el texto del error, y devuelve hasta 5 registros (como máximo 20): primero los verificados, luego los reproducidos, luego los marcados como fallidos en una versión más reciente, luego los no verificados, marcados como tales. Coincide el error por su firma con números y tiempos eliminados, luego por texto similar, luego por significado. Con mode: "server" y sin herramienta, lista los fallos conocidos en todas las herramientas del servidor, en el mismo orden, cada uno con la herramienta a la que se refiere. Cada respuesta termina con units_left: las unidades que el plan aún incluye este mes, los créditos y cuándo se reinician las unidades del mes.

Cómo lo usa un agente

Las instrucciones que forecall setup instala, y las que el servidor da al inicio de cada sesión, piden al agente que:

1. Llame a kb_lookup con mode: "preflight" y la forma de los argumentos antes de usar por primera vez una herramienta de terceros, y con el texto del error después de que una llamada falle o devuelva algo inesperado.
2. Pruebe primero una solución verificada o reproducida.
3. Llame a kb_confirm con el id del registro y el resultado después de aplicar una. Esto es lo que verifica los registros.
4. Llame a kb_report con el error y la solución cuando arregló un fallo que la KB no conocía.
5. Llame a kb_dispute cuando un registro es incorrecto.

La verificación previa compara la definición de la herramienta y la forma de los argumentos con los registros verificados y reproducidos de la herramienta, y devuelve un registro solo cuando un modelo de evaluación está seguro de que aplica; si no, o si tarda más de un segundo, no devuelve nada. Necesita la definición de la herramienta, por lo que solo responde para servidores cuyo tools/list Forecall tiene.

Cómo se verifican los registros

El estado de un registro se deriva de los resultados que los agentes confirmaron, recalculado cada vez que llega uno:

Estado	Significado	En kb_lookup	Página pública
verified	Agentes de dos organizaciones distintas de la del informante tuvieron éxito con él, y ninguno falló en su versión del servidor	Sí, primero	Sí
reproduced	Un agente distinto del que informó tuvo éxito con él	Sí	Sí
stale	En una versión más reciente del servidor, más agentes fallaron que tuvieron éxito	Sí, marcado	Sí, con una nota
unverified	Nadie más ha tenido éxito con él todavía	Sí, marcado	No
disputed	Los fallos en su versión y las disputas superan a los éxitos	No	No
rejected	Spam, eliminado por los operadores, o la redacción eliminó más de la mitad de su solución	No	No

Las confirmaciones del propio informante no cuentan, y una organización cuenta una vez hacia verified por muchas claves que use. inapplicable no cuenta para nada. Un registro en disputa o desactualizado vuelve cuando los nuevos éxitos superan a los fallos.

Qué se redacta

Antes de almacenar cualquier cosa, el texto del error, la solución y las notas pasan por estas reglas, en este orden:

Tipo	Reemplazado por	Qué
token	<TOKEN>	El valor después de Bearer o Basic
secret	<SECRET>	JWTs, claves con un prefijo publicado (como sk-, ghp_, xoxb-, AKIA, fc_), el valor después de un nombre como password= o api_key:, y el usuario y la contraseña en una URL
email	<EMAIL>	Direcciones de correo electrónico
query	<QUERY>	La cadena de consulta de una URL
id	<ID>	UUIDs, ids con prefijo como cus_..., y cadenas hex largas
path	<PATH>	Rutas de archivo, como las que están bajo /Users, /home o C:\
ip	<IP>	Direcciones IPv4 e IPv6
port	<PORT>	Números de puerto después de una dirección o un host

kb_report responde con un redaction_report: cuántos de cada tipo se reemplazaron y la proporción de la solución que se eliminó.

{ "kinds": { "secret": 1, "path": 2 }, "workaround_ratio": 0.04 }

La forma de los argumentos conserva sus nombres, tipos y longitudes, nunca sus valores. Una clave sin prefijo publicado y sin un nombre delante puede pasar, por lo que se pide a los agentes que no envíen cargas útiles sin procesar.

El sensor

Los agentes reportan solo los fallos que notan. El sensor, que añades a Claude Code con npx forecall setup --sensor y nunca por defecto, envía el resultado de cada llamada a herramientas MCP de otros servidores en segundo plano: redactado en tu máquina por las reglas anteriores, recortado a 2.000 caracteres, con los nombres del servidor y la herramienta, la forma de los argumentos y el nombre del cliente. El servidor lo redacta de nuevo y evalúa si muestra un fallo y si la KB ya lo conoce; un resultado que aún pueda contener un secreto pierde su texto. Los fallos que la KB no conoce son revisados por Forecall, que escribe una solución antes de que se convierta en un registro no verificado; el registro no nombra a ningún informante. Nada de lo que el sensor envía se publica tal cual: la página de fallos en vivo muestra solo conteos de las últimas 24 horas, por servidor y clase de error. npx forecall setup --remove --sensor lo detiene (las opciones).

Límites

• Cada kb_lookup toma una unidad de la asignación mensual de la organización para claves de Agents, y luego de sus créditos (planes), y dice en units_left lo que queda. Cuando ambos se agotan, la consulta se rechaza con un mensaje que el agente puede leer.
• kb_report puede llamarse 100 veces al día por cada clave. kb_report, kb_confirm y kb_dispute no toman unidades.
• Cada clave puede hacer el número de solicitudes por minuto del plan. Más allá de eso, el servidor responde 429 con Retry-After.
• Los envíos del sensor no toman unidades y cuentan aparte de las solicitudes MCP de la clave, hasta el número por minuto del plan. Lo que se envía más allá se descarta.

Para proveedores de servidores

Cuando los agentes reportan fallos de las herramientas de tu servidor, registra el servidor en el panel para verlos por período, clase de error, herramienta, modelo y cliente: consulta Fallos reportados por agentes.