RocketReach MCP

npx add-mcp 'https://mcp.rocketreach.co/mcp'

Autenticación

El servidor MCP de RocketReach utiliza OAuth 2.1 con PKCE y Registro Dinámico de Clientes (DCR). Los clientes compatibles con MCP manejan este flujo automáticamente — no necesitas implementarlo tú mismo. Esta página documenta el flujo para desarrolladores que construyen sus propios clientes o integraciones MCP.

Cómo funciona

El servidor expone una cadena estándar de descubrimiento OAuth que los clientes compatibles siguen automáticamente:

1. Descubrimiento — el cliente obtiene /.well-known/oauth-protected-resource del servidor MCP para conocer la URL del servidor de autorización.
2. Metadatos del servidor de autorización — el cliente obtiene /.well-known/oauth-authorization-server del servidor de autorización (RocketReach) para descubrir todos los endpoints OAuth.
3. Registro Dinámico de Clientes — el cliente se registra enviando un POST a /mcp-oauth/register y recibe un client_id.
4. Autorización — el cliente redirige el navegador del usuario a /mcp-oauth/authorize con un code_challenge PKCE.
5. Consentimiento del usuario — el usuario inicia sesión en RocketReach y aprueba la solicitud de acceso.
6. Intercambio de tokens — el cliente intercambia el código de autorización por un token de acceso mediante POST /mcp-oauth/token.
7. Llamadas a la API — el cliente envía Authorization: Bearer <token> en cada solicitud a POST /mcp.

Endpoints

Paso	Endpoint	Notas
Descubrimiento	GET https://mcp.rocketreach.co/.well-known/oauth-protected-resource	Devuelve el identificador del recurso y su(s) servidor(es) de autorización
Registro	POST https://rocketreach.co/mcp-oauth/register	Registro Dinámico de Clientes (RFC 7591)
Autorizar	GET https://rocketreach.co/mcp-oauth/authorize	Autorización basada en redirección con PKCE
Token	POST https://rocketreach.co/mcp-oauth/token	Intercambia el código por un token de acceso

Formato del token

Los tokens de acceso son JWTs envueltos en JWE (firmar y luego cifrar). La envoltura exterior es AES-256-GCM (JWE); en el interior hay un JWT firmado con HS256 (JWS) que contiene claims estándar (sub, aud, exp) además de claims específicos de RocketReach, incluida la clave de API. El JWS interno está firmado, no cifrado, por lo que la clave de API se encuentra en texto plano dentro de él — la envoltura JWE exterior es lo que mantiene estas credenciales confidenciales frente a intermediarios.

Pasa los tokens como tokens Bearer:

Authorization: Bearer <access_token>

Los tokens están vinculados a la URL del servidor MCP — un token emitido para mcp.rocketreach.co será rechazado por cualquier otra audiencia. El servidor valida el claim de audiencia en cada solicitud.

Duración de los tokens

Tipo de token	Duración	Notas
Token de acceso	1 hora	Token Bearer enviado con cada solicitud
Token de actualización	30 días	Cadena opaca; rota en cada uso

Los tokens de acceso son de corta duración por diseño. Cuando uno expira, los clientes MCP compatibles intercambian automáticamente el token de actualización por un nuevo par de tokens de acceso + actualización mediante POST /mcp-oauth/token con grant_type=refresh_token. Esto ocurre de forma transparente — no se solicita al usuario reautorizar a menos que el propio token de actualización expire o sea revocado.

Los tokens de actualización son de un solo uso y rotan en cada intercambio. Si un token de actualización se presenta después de haber sido utilizado, todos los tokens para ese usuario+cliente se revocan inmediatamente.

Revocación de tokens

Para desconectar un cliente de IA o revocar un token específico:

POST https://rocketreach.co/mcp-oauth/revoke
Content-Type: application/x-www-form-urlencoded

token=<access_or_refresh_token>

Revocar un token de actualización invalida los tokens de acceso emitidos a partir de él.

Ámbitos

Se utiliza un único ámbito: rocketreach:read. Autorizar esto concede acceso a todas las herramientas (búsqueda, consulta, cuenta). Pásalo en el parámetro scope de la solicitud de autorización, u omítelo — un ámbito vacío se establece por defecto en rocketreach:read.

Notas para implementación de clientes personalizados

Si estás construyendo tu propio cliente MCP contra los endpoints OAuth de RocketReach:

• Genera un parámetro state aleatorio antes de redirigir al usuario a /mcp-oauth/authorize. Verifica que el state devuelto coincida en la devolución de llamada. Esta es tu defensa CSRF para el flujo OAuth — es responsabilidad del cliente, no del servidor.
• El Registro Dinámico de Clientes está abierto según RFC 7591 — no se requiere aprobación previa. Regístrate en POST /mcp-oauth/register.
• Las URIs de redirección están vinculadas en el registro. El redirect_uri en la solicitud de autorización debe coincidir exactamente con una URI registrada para tu client_id. Las redirecciones que no sean localhost deben usar https://. http://localhost y http://127.0.0.1 en cualquier puerto están permitidos para clientes nativos/de escritorio (RFC 8252).

Errores

Estado HTTP	error	Significado
400	invalid_scope	Se solicitó un ámbito distinto de rocketreach:read (o vacío)
401	auth_required	No hay token Bearer en la solicitud
401	invalid_token	El token está expirado, tiene una audiencia incorrecta, o fue emitido por un servidor no reconocido
401	invalid_token (descripción: decryption failed)	El token fue emitido con una clave de cifrado rotada — reautoriza para obtener un token nuevo