standup-mr

Notas de standup a partir del estado de merge requests de GitLab o GitHub, con las líneas de error del registro de trabajo de un pipeline fallido.

GitHubPrueba este MCPPatrocinado

Documentación

standup-mr

standup-mr MCP server Listed on mcpservers.org

Notas de standup basadas en el estado de los merge requests, no en los registros de commits.

La mayoría de las herramientas de standup leen tu git log local. Eso responde "qué escribí", que no es lo que nadie pregunta en un standup. Esta lee GitLab o GitHub: qué está listo para fusionar, qué está bloqueado, qué está esperando por ti — y cuando un pipeline está en rojo, abre el registro del trabajo y te dice por qué.

Qué lo hace diferente

herramientas de registro de commitsstandup-mr
Fuentegit log localAPI de GitLab o GitHub
Estado del merge request✗listo / bloqueado / borrador / obsoleto
Cola de revisión✗solo pendientes, aprobaciones filtradas
Pipeline fallido✗líneas de error del rastreo del trabajo o del registro de trabajo de Actions
Autoalojado (GitLab CE/EE, GitHub Enterprise)varíade primera clase

Uso

npx standup-mr fetch                            # JSON, provider auto-detected
npx standup-mr fetch --provider github          # GitHub
npx standup-mr fetch --provider gitlab          # GitLab
npx standup-mr fetch --markdown                 # structured digest
npx standup-mr fetch --lang tr                  # Turkish date labels

npx standup-mr fetch --markdown | npx standup-mr post --google-chat "$URL"

Identidad

GitHubGitLab
Banderas--host / --token--host / --token
EntornoGITHUB_HOST / GITHUB_TOKENGITLAB_HOST / GITLAB_TOKEN
Sesión CLIgh configuración de autenticaciónglab configuración de autenticación

GitHub usa github.com por defecto cuando no se proporciona un host. GitLab no tiene valor predeterminado: el autoalojamiento es la norma allí, por lo que un host debe venir de una bandera, una variable de entorno o la propia configuración de glab.

El proveedor en sí se elige en este orden:

  1. --provider github / --provider gitlab, si se pasan
  2. un --host reconocible (github.com, gitlab.com, o un nombre de host que contenga github/gitlab)
  3. STANDUP_PROVIDER, o cualquiera de los pares de entorno GITHUB_* / GITLAB_* que esté configurado
  4. cualquiera de gh / glab que tenga una sesión iniciada

Si ninguno de estos se resuelve — o ambos lo hacen, de manera ambigua — el comando falla con un error claro en lugar de adivinar.

Así que si ya usas gh o glab, no hay nada que configurar.

Publicarlo en el chat

npx standup-mr fetch --markdown | npx standup-mr post --slack "$SLACK_WEBHOOK_URL"

Las tres superficies

CLI — el núcleo. Emite JSON; cero dependencias en tiempo de ejecución.

Servidor MCP (mcp/) — una herramienta, get_standup_data, para Claude Desktop, Cursor o cualquier cliente MCP. Ver mcp/README.md.

Plugin de Claude Code — el manual de escritura de notas, enviado como la habilidad standup. Desde dentro de Claude Code:

/plugin marketplace add Jubstaaa/standup-mr
/plugin install standup@standup-mr

Luego escribe /standup. Las actualizaciones vienen con /plugin marketplace update standup-mr.

Usarlo desde Cursor, Codex u otro asistente

Si no usas Claude Code, conecta el servidor MCP para datos en vivo y pega las reglas de escritura de notas por separado.

Cursor — agrega a ~/.cursor/mcp.json (global) o .cursor/mcp.json (específico del proyecto):

{
    "mcpServers": {
        "standup": {
            "command": "npx",
            "args": ["-y", "standup-mr", "mcp"],
            "env": {
                "GITHUB_TOKEN": "ghp_..."
            }
        }
    }
}

Codex — agrega a ~/.codex/config.toml:

[mcp_servers.standup]
command = "npx"
args = ["-y", "standup-mr", "mcp"]

[mcp_servers.standup.env]
GITHUB_TOKEN = "ghp_..."

La clave de configuración exacta y la ruta del archivo dependen de la versión para ambos clientes: si un fragmento anterior no funciona, consulta los documentos de MCP de Cursor o la documentación de configuración de Codex para el formato actual en lugar de confiar ciegamente en este archivo.

El servidor expone tres herramientas:

HerramientaQué hace
get_standup_dataLee el proveedor y devuelve el informe como JSON. Opcional provider, host, lang.
get_note_instructionsDevuelve las reglas de escritura de notas, para que el asistente pueda escribir la nota como lo haría la habilidad.
post_standup_notePublica una nota terminada en un webhook de Slack, Discord o Google Chat.

post_standup_note lee la URL del webhook desde STANDUP_WEBHOOK_URL y nunca la toma como argumento: cualquiera que tenga esa URL puede publicar en el canal, por lo que pertenece a los tokens, no a una transcripción. La forma del payload se infiere del host de la URL; kind solo se necesita cuando un proxy la oculta.

Se implementan tres formas: slack y google-chat publican {"text"}, discord publica {"content"}.

Slack y Google Chat no renderizan Markdown estándar, por lo que la nota se reescribe en el camino: **bold** se convierte en *bold* y un encabezado ## se convierte en una línea en negrita. El código en línea, los bloques delimitados y su contenido se dejan intactos. Discord habla Markdown de forma nativa y se envía sin cambios. Cualquier otra cosa que acepte un cuerpo con forma de Slack: Mattermost, Rocket.Chat, un endpoint de n8n o Zapier — funciona hoy pasando kind: "slack", o --slack URL en la CLI.

Fuera de MCP, las mismas reglas están disponibles en la salida estándar:

npx standup-mr instructions >> AGENTS.md

--markdown es un resumen, no una nota escrita

--markdown organiza el material bruto en secciones legibles. No agrupa eventos en temas ni diagnostica bloqueadores — ese es el trabajo del modelo, y vive en el prompt del cliente MCP o en la habilidad de Claude Code.

  • Sin IA: un resumen estructurado.
  • Con IA: una nota que puedes leer en voz alta.

Cómo se ve el resumen

Salida anonimizada de una ejecución real de lunes — nota que viernes y sábado cada uno tiene su propia sección, y que un merge request que GitLab no ha evaluado no se llama listo:

# Monday, 31 August — dev

_Structured digest — not a written note._

## Previous working day: Friday, 28 August

- `acme/ui` pushed to — fix(keyboard): scale keys to viewport (4 commits)
- `acme/ui` accepted — chore(deps): bump @acme/ui to 0.5.18
- `acme/api` opened — feat: package subscription sales

## Previous working day: Saturday, 29 August

- `acme/ui` pushed to — fix(keyboard): close the autofill bar (1 commit)

## Ready to merge (2)

- `acme/api` !196 fix: normalise the +90 trunk prefix
- `acme/web` !194 refactor: loading state — **no pipeline ran**

## Blocked (1)

- `acme/terminal` !49 fix: relative date chips — **1 unresolved comment(s)**

## Reviews (2 pending)

- `acme/mobile` !501 chore: upgrade to RN 0.87 — Teammate

## Blockers

- `acme/mobile` !6 — job `quality`
    - `npm ERR! code E404`
    - `npm ERR! 404 Not Found - GET https://registry.example.com/@acme%2fui`

La última sección es el punto de la herramienta. Cada otra herramienta de standup puede decirte que ese pipeline está en rojo; esta abre el registro del trabajo fallido y te muestra el 404 — y un 404 en lugar de un 403 generalmente significa que el alcance del token es incorrecto, no que el paquete falte.

Limitaciones conocidas

  • El feed de eventos de GitHub es superficial. Está limitado a aproximadamente 300 eventos en los últimos 90 días, por lo que una cuenta muy activa o una brecha antigua puede perder silenciosamente los eventos más antiguos. GitLab no tiene un límite documentado comparable.
  • La actividad de GitHub solo es visible para un token que pertenezca a esa misma cuenta, y los eventos de repositorios privados no aparecen para el token de nadie más, incluso con alcances suficientes.
  • En GitHub, CI que informa solo a través de la API de estados de commits heredada — que es como algunos proveedores se integran — aparece como pipelineMissing. El estado de verificación se lee solo de las ejecuciones de verificación.
  • Un bloqueador cuyo diagnóstico no se pudo obtener aún se informa, como job: "unknown" con una línea de error diagnosis unavailable: …. El merge request está bloqueado de todos modos; solo falta la explicación. Los errores del servidor se reintentan dos veces primero, y un token rechazado aún falla la ejecución.

Actualización desde 0.1.x

0.2.0 cambia la salida JSON, la API de la biblioteca y las opciones de MCP. Si canalizas standup fetch a algo, o importas el paquete, lee CHANGELOG.md antes de actualizar. La versión corta:

  • previous y previousEvents se reemplazan por previousDays[], una entrada por día activo, por lo que un fin de semana ya no se traga el viernes. jq .previous ahora devuelve null sin error.
  • MergeRequest, Review y Blocker llevan un campo provider obligatorio, y Provider.getReviews toma un Identity en lugar de un id numérico.
  • El CollectOptions.provider de MCP ahora es un nombre de proveedor; inyecta una instancia de Provider a través de providerImpl.

Los usuarios del plugin de Claude Code deben ejecutar /plugin marketplace update standup-mr — la habilidad standup cambió junto con la forma del informe.

Requisitos

Node 20 o más reciente. El núcleo de la CLI (fetch, post, instructions) no tiene dependencias en tiempo de ejecución. El servidor MCP (comando mcp) trae una: @modelcontextprotocol/sdk.

Licencia

MIT