/.well-known/oauth-protected-resource: descubrimiento de recursos protegidos
El primer documento que lee un cliente. Responde a una pregunta: ¿qué servidor de autorización protege este recurso?
https://example.com/.well-known/oauth-protected-resourceGET, público, devuelve JSON.
Qué contiene
Dos campos:
| Campo | Valor |
|---|---|
resource |
El endpoint MCP de este sitio |
authorization_servers |
Una lista que contiene el emisor de este sitio |
La resource es la URL MCP canónica, y el emisor es la URL raíz del propio sitio sin barra diagonal final. Ambas se derivan de la URL de inicio del sitio.
Cómo llega hasta él un cliente
No está configurado en ninguna parte. El cliente llama al endpoint MCP sin credenciales, recibe 401 y lee la cabecera WWW-Authenticate, que nombra esta URL. Luego sigue el puntero.
Por eso un cliente solo necesita la URL MCP. Consulta Cómo funciona el descubrimiento.
Por qué importa el valor del recurso
La resource aquí es el mismo valor que el cliente debe enviar como parámetro resource durante la autorización y el intercambio de token. El servidor compara el esquema, el host, el puerto y la ruta de forma exacta, y rechaza cualquier discrepancia con invalid_resource.
Así que este documento es también la declaración autoritativa de la URL que hay que configurar. Si un cliente falla en el paso del token, compara la URL del servidor configurada con la resource que aparece aquí carácter por carácter: una diferencia de www o un segmento de ruta final es suficiente para fallar.
Los clientes que omiten el parámetro resource son aceptados, ya que algunos clientes MCP no lo envían.
Es una regla de reescritura
Las rutas .well-known se sirven mediante reglas de reescritura de WordPress, no archivos reales. Dos consecuencias:
- Se requieren enlaces permanentes bonitos. Con enlaces permanentes simples esta URL devuelve la página 404 de tu sitio mientras que el endpoint MCP sigue funcionando: una combinación confusa que detiene el descubrimiento por completo.
- Un directorio físico
.well-knownpuede ocultarlo. Si el servidor web sirve un archivo real en esa ruta, WordPress nunca ve la petición. Algunos proveedores de TLS crean uno; compruébalo si el descubrimiento falla en un sitio con enlaces permanentes correctos.
Sitios multilingües
Cuando POM Translate antepone un código de idioma a las URLs, el servidor también responde a la forma localizada — /es/.well-known/oauth-protected-resource — mientras sigue anunciando la URL canónica sin prefijo.
Esto existe para que una redirección a través de una URL traducida no rompa el flujo. Configura los clientes con la forma canónica.
Caché y CORS
La respuesta se envía con cabeceras de caché no-store y un tipo de contenido JSON. Las peticiones de origen cruzado solo se responden para los orígenes de tu lista de permitidos; la comprobación previa OPTIONS devuelve 204.
Excluye la ruta de la caché de la CDN. Una copia en caché de antes de un cambio de dominio apuntará a los clientes al recurso equivocado.
Comprobarlo
Ábrelo en un navegador. Deberías ver un pequeño objeto JSON que nombra tu endpoint MCP y tu sitio.
| Lo que ves | Significa |
|---|---|
| El JSON esperado | Funciona |
| La página 404 de tu sitio | Los enlaces permanentes bonitos no están configurados |
| HTML | Algo aguas arriba está interceptando, o un archivo real oculta la ruta |
| El host equivocado | La URL de inicio del sitio difiere del host que estás usando |
Ese último caso merece la pena comprobarlo en sitios accesibles tanto en example.com como en www.example.com: el documento informa de cuál considera WordPress canónico, y ese es el que deben usar los clientes.
Los diagnósticos del panel de ajustes de MCP obtienen este documento del propio servidor e informan del estado, el tipo de contenido y si se analizó como JSON.
Siguiente
Metadatos del servidor de autorización, el documento al que apunta este.