openreview-mcp: la revisión por pares como recurso consultable para LLMs

El ecosistema de servidores Model Context Protocol cubre ya casi todo el día a día de un investigador académico. Hay servidores MCP para arXiv, Semantic Scholar, datasets de Hugging Face, Crossref y Google Scholar. No existe ninguno para el corpus más valioso de todos: la revisión por pares.

Ese hueco es el que cierra openreview-mcp, y la razón por la que lo publicamos hoy en código abierto.

Por qué la revisión por pares

La mayoría de servidores MCP académicos tratan los artículos como unidad de información: título, resumen, citas, PDF. Eso vale para descubrir literatura, pero ignora lo que probablemente sea la señal más densa que produce el ML académico: el razonamiento de revisores expertos explicando por qué un artículo tiene éxito o fracasa.

La revisión por pares es única en tres aspectos. Primero, es densa. Una sola revisión empaqueta entre cinco y ocho críticas específicas en unos cientos de palabras: cada una es una afirmación falsable sobre el paper, normalmente anclada a una sección, ecuación o tabla concreta. Segundo, es consecuente. La decisión que toma el revisor tiene efectos reales sobre carreras y sobre la propia literatura; los revisores lo saben y escriben en consecuencia. Tercero, está oculta. La mayoría de la revisión por pares todavía sucede tras puertas cerradas, accesible solo para autores y plataforma.

OpenReview aloja ese razonamiento de forma pública para casi todos los grandes venues de ML: ICLR, NeurIPS, COLM, TMLR, ACL ARR y decenas de workshops. Las revisiones, las réplicas de los autores, las meta-revisiones del area chair y las decisiones finales están ahí, accesibles vía API oficial. Pero no son alcanzables hoy desde ningún LLM conectado por MCP.

Hasta ahora.

Qué hace openreview-mcp

El servidor expone once herramientas MCP que mapean directamente a las entidades de OpenReview:

• Venues: lista de venues filtrada por año o serie, estadísticas de envíos y aceptación.
• Envíos: búsqueda por venue, query, autor o keywords; recuperación de un envío con su resumen y PDF; listado de todo lo que un perfil ha enviado.
• Revisiones: todas las revisiones oficiales de un envío con sus puntuaciones, confianza, soundness, presentación, contribución, resumen, fortalezas, debilidades y preguntas.
• Meta-revisiones y decisiones: la meta-revisión del area chair y la decisión de aceptación/rechazo, por separado.
• Réplicas: respuestas de los autores enlazadas a la revisión a la que responden.
• Perfiles: nombres, afiliaciones e identificadores DBLP/ORCID/Scholar.
• Agregación de debilidades (la herramienta diferenciadora): clusteriza las críticas recurrentes de los revisores entre los rechazos de un venue.

Instalación:

pip install "openreview-mcp[analysis]"

Conexión con Claude Code:

claude mcp add openreview -- openreview-mcp

O Claude Desktop:

{
  "mcpServers": {
    "openreview": { "command": "openreview-mcp" }
  }
}

Los venues públicos funcionan sin configuración. Para los privados, las credenciales se leen de OPENREVIEW_USERNAME y OPENREVIEW_PASSWORD. Veinte tests offline cubren la capa de parser y de schemas; el paquete corre sobre Python 3.11+ y se publica bajo MIT en PyPI.

La herramienta diferenciadora, en detalle

openreview_aggregate_weaknesses es lo que separa al servidor de un envoltorio REST. Saca a la luz patrones estructurales sobre miles de críticas de revisores de una manera que ninguna consulta paper a paper puede.

La pipeline corre en siete pasos:

1. Fetch de todos los envíos del venue con sus respuestas en una única llamada masiva a la API.
2. Filtro a los envíos cuya decisión final contiene reject.
3. Muestreo de N envíos con semilla fija (por defecto, 100).
4. Extracción del campo weaknesses de cada respuesta de tipo Official_Review en los envíos muestreados.
5. Partición de cada párrafo en items individuales por sus delimitadores de viñeta o numeración. Este es el paso que la mayoría de papers sobre análisis de revisión asistido por LLM ignoran: el campo weaknesses de un revisor lista típicamente entre cinco y ocho críticas distintas, y clusterizar a nivel de párrafo colapsa el 90% de los items en un único cluster dominante por el vocabulario compartido. Particionar a nivel de item recupera la estructura.
6. Vectorización con TF-IDF (uni-grama y bi-grama, frecuencia sublineal, normalización L2) y reducción a 64 dimensiones latentes con Truncated SVD (la aproximación LSA de Deerwester et al. 1990). Renormalización a la esfera unidad.
7. Clustering con KMeans (n_init=20, semilla fija). Para cada cluster, devolvemos los términos TF-IDF más frecuentes entre sus miembros y los tres ejemplares más cercanos al centroide.

La decisión interesante es que no devuelve etiquetas legibles para los clusters. Devuelve los términos TF-IDF más frecuentes, tres ejemplares cercanos al centroide y la lista de envíos contribuyentes. Es el LLM consumidor el que etiqueta los clusters a partir de la evidencia.

Esto importa. Una taxonomía pre-cocinada congelaría categorías que varían entre venues y entre años. Un revisor de NeurIPS rechaza por motivos distintos a uno de ACL. Las modas cambian. Devolviendo clusters crudos, dejamos que el agente que llama produzca etiquetas apropiadas al venue y a la franja de literatura que esté estudiando.

¿Funciona? Un caso de estudio en ICLR 2024

La prueba honesta para una herramienta así es si saca a la luz algo no obvio sobre un venue que el lector ya conoce de primera mano. Así que la apuntamos a ICLR 2024.

analysis.aggregate_weaknesses(
    client,
    venue_id="ICLR.cc/2024/Conference",
    sample_size=100,
    n_clusters=14,
    seed=7,
)

Cien envíos rechazados produjeron 1.361 críticas individuales agrupadas en 14 temas. Tres resultados destacan, y cada uno lleva una lección accionable para los autores que planean su próximo envío.

La evaluación, no la novedad, es el principal motor de los rechazos

Los tres clusters más grandes (197, 194 y 180 items) tienen que ver con el diseño experimental: evaluación demasiado limitada o sesgada, decisiones de modelado poco claras y experimentos o teoría superficiales. Suman el 42% de todas las críticas. El cluster genérico de "le falta novedad", que suele citarse como la crítica canónica, es el quinto en tamaño con 104 items.

Esto desmiente el folclore que dice que la novedad es la batalla principal. Si estás optimizando tu paper para satisfacer al revisor, la mejora marginal en tu sección de evaluación va a pesar más que un párrafo extra defendiendo la novedad.

Una crítica representativa del cluster más grande:

La evaluación se limita a dos benchmarks ya saturados. Sin escenarios fuera de distribución o más difíciles, las mejoras sobre los baselines podrían simplemente reflejar overfitting a los test sets que el campo lleva años optimizando.

La acción concreta: elige tres datasets diversos, incluye al menos uno que rompa los supuestos de tu método, y reporta intervalos de confianza, no estimadores puntuales.

Los detalles de manufactura siguen hundiendo papers

Typos y referencias cruzadas rotas (78 items), figuras y captions confusos (50), citas que faltan (71) y críticas explícitas sobre la calidad de la escritura (44) suman más de 240 ítems que afectan a unos 70 de los 100 papers muestreados. Son problemas mecánicos que una revisión cuidadosa de pruebas atraparía, y aun así son razones rutinarias de rechazo.

Es el tipo de hallazgo que sería difícil de admitir si no estuviera cuantificado. Cada autor se dice a sí mismo que su paper está bien escrito; los datos dicen que los revisores no están de acuerdo, a menudo con granularidad de línea:

Línea 307, "one week The" → "one week. The". Algoritmo 1 línea 4: el índice debería ser t-1 dada la recurrencia.

La acción concreta: en las últimas 48 horas antes del deadline, haz una pasada solo de typos. No es glamuroso pero la densidad es altísima. Acompáñala de una pasada de "consistencia": misma paleta de colores entre figuras, misma notación para el mismo objeto entre secciones.

Modos de fallo específicos por dominio

Dos clusters son estrictamente temáticos: federated y semi-supervised learning (88 items) y time series (50 items). Reflejan probablemente alta densidad de envíos en esas áreas y modos de fallo específicos. Los autores que envíen en esas áreas harían bien en leer los ejemplares y pre-rebatir las objeciones estándar; por ejemplo, los trabajos en federated reciben una y otra vez la misma queja sobre supuestos no-i.i.d. poco realistas.

Una queja real de uno de esos clusters, copiada sin retocar del registro de OpenReview:

Aunque los autores afirman proponer un marco unificado, los métodos considerados son principalmente AM y POMO, es decir, métodos auto-regresivos. Hasta donde sé, también existen otros métodos (...).

Este nivel de concreción es lo que aggregate_weaknesses saca como evidencia. No categorías abstractas: el lenguaje y el detalle exactos a los que se enfrentaron los papers rechazados.

Para qué sirve

Cuatro casos de uso vienen inmediatamente a la cabeza, y para los cuatro tenemos prototipos ligeros funcionando.

Auto-revisión pre-envío. Lanza la herramienta sobre tu venue objetivo. Pídele al LLM que identifique a qué clusters está más expuesto tu borrador y endurece esas secciones antes de que las encuentre un revisor. Funciona especialmente bien combinada con las meta-revisiones del año anterior del mismo venue.

Agentes de crítica al estilo revisor. Ancla un agente "revisor severo" en el lenguaje real del venue objetivo, no en una rúbrica genérica. La ventaja es la verosimilitud: el LLM ya no alucina objeciones plausibles; saca del vocabulario real de los revisores del venue.

Docencia. Los directores de tesis suelen transmitir folclore sobre lo que rechaza su venue. Con esta herramienta, el mismo director puede mostrar evidencia: abre la página del cluster, elige un ejemplar por categoría, lo recorre con el doctorando. La lección cala mucho más que un "ten cuidado con tus baselines".

Análisis de réplicas. Combina get_rebuttal con get_decision para estudiar qué patrones de réplica voltearon rechazos borderline en aceptaciones. No hemos hecho ese análisis a escala todavía, pero las primitivas ya están disponibles; publicaremos resultados a medida que los corramos.

Por qué lo construimos sobre MCP, no como un script

Tres razones.

Primero, componibilidad. Un agente de auto-revisión pre-envío debería poder combinar openreview-mcp con academia-mcp (búsqueda en arXiv), con una sandbox de ejecución de código, y con un slot para el borrador del usuario. MCP hace esa composición mecánica.

Segundo, separación de responsabilidades. El servidor MCP captura el conocimiento específico de OpenReview (diferencias entre v1 y v2 de la API, schemas de decisión, variantes de los campos: TMLR, por ejemplo, usa recommendation en vez de decision y combina fortalezas y debilidades en un solo campo). Los consumidores del servidor no tienen que aprender nada de eso.

Tercero, durabilidad. MCP se está convirtiendo en el sustrato sobre el que otros proyectos de research tooling construyen. Producir una herramienta de revisión por pares sobre MCP hoy significa que agentes futuros, incluidos los que no nos hemos imaginado todavía, van a poder cablearla sin nuestra intervención.

Limitaciones honestas

La herramienta no es magia, y queremos que el usuario lea la salida con confianza calibrada.

• TF-IDF agrupa por similitud léxica, no semántica. Dos críticas que dicen lo mismo con vocabulario distinto pueden caer en clusters separados. Una pipeline opt-in basada en sentence embeddings sacaría estructura más fina al precio de una dependencia adicional. La exponemos como flag de futuro, no por defecto.
• El muestreo dentro de los rechazados es uniforme. Los rechazos borderline (decisión "Reject (close)") llevan patrones de crítica distintos a los rechazos claros; los tratamos por igual. Pesar por confianza del revisor o margen de decisión está en el roadmap.
• Cada venue expone una porción distinta de su proceso. NeurIPS solo expone públicamente los envíos que llegaron a fase de decisión, lo que infla la tasa de aceptación visible. COLM solo expone los aceptados, lo que hace imposible el clustering de debilidades. Avisamos de estas limitaciones en la página de cada venue y recomendamos al usuario leerlas antes de sacar conclusiones.

Qué viene después

openreview-mcp es el primer servidor MCP que publica OpenCódice Research. Otros dos están en preparación:

• Un tracker de plazos para CFPs académicos (NeurIPS, ICLR, ACL ARR, COLM, EMNLP, CHI, etc.), para que un agente pueda preguntar "qué venues cierran en los próximos 60 días" y recibir una respuesta estructurada.
• Un puente a Zenodo para depósitos de datasets y código con DOI, de modo que los artefactos de investigación puedan empujarse y recuperarse programáticamente.

Más allá del servidor, hemos construido Venues, una capa de analítica abierta sobre los datos que produce: páginas navegables para ICLR 2024, ICLR 2025, NeurIPS 2024 y TMLR, con una vista de comparación año a año. El servidor es el motor; Venues es el dashboard. Ambos abiertos y gratuitos.

El repositorio está en github.com/OpenCodice-Research/openreview-mcp. Issues y pull requests son bienvenidos. Nos interesa especialmente recibir contribuciones que añadan clustering basado en embeddings de frase como alternativa a TF-IDF, normalización específica por venue para plantillas de revisión no estándar (TMLR, ciclos de ARR), y un dashboard público refrescado semanalmente para los venues más grandes.

Si construyes algo encima, escríbenos. Lo enlazaremos.

La justificación de diseño completa, la pipeline de análisis y el caso de estudio están documentados en el Informe Técnico de OpenCódice OC-TR-2026-007 (Zenodo, DOI 10.5281/zenodo.19758460).