Errores

{
  "error": {
    "code": "governance_refused",
    "message": "utm_source must be lowercase: Newsletter → newsletter."
  }
}

• code es una palabra de una lista cerrada, para que tu programa se ramifique sobre ella.
• message es una frase, para que la lea una persona. Es la misma frase que muestra la consola para el mismo rechazo, así que un comercializador y un integrador que ven el mismo problema ven las mismas palabras.
• details aparece en invalid_input: un mapa de nombre de campo a una lista de mensajes cuando la propia validación del espacio de trabajo rechazó, o de puntero JSON (/destination) a un mensaje cuando la solicitud falló la validación de esquema.
• permission aparece en missing_permission: el permiso que le falta al token.
• retry_after_seconds aparece en rate_limited, y en el limit_reached por hora.

​

Los códigos

• La puerta — unauthenticated (401), subscription_required y subscription_ended (402), missing_permission y role_forbids (403), rate_limited (429). Ver Autenticación y tokens y Límites de solicitudes.
• El plan — plan_forbids (403) cuando el plan no incluye la función, limit_reached (429) cuando se alcanza uno de los dos límites de abuso en la página Límites de solicitudes, con Retry-After solo para el que es por hora. Una ventana de informe que el plan no alcanza es invalid_input (422), abajo.
• Las reglas — governance_refused cuando la convención, los valores aprobados o las reglas de dependencia del espacio de trabajo rechazan la entrada, scanner_refused cuando el destino falló el escaneo de seguridad, duplicate_link cuando el espacio de trabajo ya tiene un enlace con exactamente ese destino etiquetado (409, el único conflicto del conjunto: el mensaje nombra el enlace existente, y lo correcto es usarlo en vez de reintentar). Los dos primeros son 422.
• La solicitud — invalid_input (422) con details, y not_found (404). Un recurso de otro espacio de trabajo y uno que no existe son la misma respuesta, a propósito.

​

Cómo reporta el servidor MCP las mismas cosas