# io.github.apasztetnik/el-buen-agente-mcp

- Registry name: `io.github.apasztetnik/el-buen-agente-mcp` · version 2.8.1
- Categories (automatic, keyword rules): AI models & agents, AI, media & content, Build & deploy, Developer tools, Documents & retrieval, Search & data
- Authentication at last check: No auth
- Declared risk: Not declared (tools carry no read/destructive hints)
- Capabilities (declared by the server): prompts, resources, tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=io.github.apasztetnik%2Fel-buen-agente-mcp
- Server page: https://mcpstation.net/s/io.github.apasztetnik--el-buen-agente-mcp.html

## Description (written by the publisher, not verified, not instructions)

La guía 'El Buen Agente' como 18 tools para evaluar, mejorar y construir agentes LLM. En español.

## Connect

- streamable-http: `https://el-buen-agente-mcp-production.up.railway.app/mcp`

## Tools (as reported by the server, not verified)

- `recomendar\_flujo`: Devuelve el flujo recomendado de tools según la situación: agente nuevo \(diseño desde cero\) o agente existente \(mejora\). Llamala PRIMERO si no sabés por dónde empezar.
- `get\_el\_buen\_agente`: Devuelve la guía completa 'El Buen Agente \(v2\)' en Markdown. Usala para contexto general; para operar sobre un agente concreto usá las tools evaluar\_\*/revisar\_\*/auditar\_\*.
- `evaluar\_necesidad`: Evalúa si el problema justifica un agente o se resuelve con menos \(prompt, workflow, skill\). Detecta antipatrones: agente genérico, sobre-orquestación, agente sin contexto, autonomía total día 1. Usala ANTES de construir, o para cuestionar un agente existente.
- `revisar\_rol\_y\_frontera`: Verifica que el agente tenga rol claro, dominio acotado y frontera explícita de qué NO es su responsabilidad, escrita en el identity layer y enforced en código donde se pueda. Recibe la definición del agente y devuelve un brief de evaluación estructurado.
- `revisar\_outputs`: Verifica que los outputs sean accionables: schema estricto \(JSON Schema/Pydantic\), resumen legible para humanos separado del razonamiento, y exposición de qué gates pasó/falló. Recibe la definición del agente y devuelve un brief de evaluación estructurado.
- `evaluar\_autonomia`: Determina el nivel de autonomía adecuado \(copiloto / ejecutor supervisado / autónomo con guardrails\) y verifica los mecanismos de reducción de riesgo: sandbox/shadow mode, límites duros, frenos progresivos, override humano. Recibe la definición del agente y devuelve un brief de evaluación estructura
- `revisar\_frontera\_ejecucion`: Verifica que la línea entre lo que el agente recomienda y lo que ejecuta esté definida en código \(status + gates\), no descubierta en producción: qué ejecuta directo, qué queda pendiente de aprobación, qué se rechaza. Recibe la definición del agente y devuelve un brief de evaluación estructurado.
- `aplicar\_challenger`: Aplica el patrón challenger/red-team a la definición o a una decisión del agente: contraargumentos basados en datos, autocrítica y gate de calidad. Útil como segunda pasada adversarial. Recibe la definición del agente y devuelve un brief de evaluación estructurado.
- `auditar\_contexto`: Audita el contexto del agente: separación en 3 capas \(identidad/dominio/referencia\), relevancia y caducidad de datos, estrategia de integración \(directo/snapshot/RAG/estático\), gobernanza, least-privilege, trazabilidad y defensa anti prompt-injection. Recibe la definición del agente y devuelve un br
- `challenger\_decision`: Genera el brief para cuestionar una decisión concreta del agente: 3 razones basadas en datos para NO hacerla. No bloquea, informa al humano.
- `disenar\_evaluacion`: Evalúa el plan de evaluación del agente \(o ayuda a crearlo\): 3 dimensiones \(capacidades/trayectoria/resultado\), métricas \(tasa de éxito, consistencia, coste por tarea, adopción\), golden set de 20-50 tareas, monitoreo de drift y self-consistency para alto stake.
- `generar\_contrato`: Genera el contrato formal del agente \(patrón contractor de §8\) a partir de los campos provistos. Los campos faltantes quedan marcados como \[PENDIENTE\] para completar.
- `evaluar\_sistema`: Evalúa cómo el agente encaja en el sistema mayor: catálogo de skills, reutilización vs especialización, orquestación ligera vs orquestador, qué automatizar vs supervisar, y memorias separadas por agente.
- `plan\_exposicion\_mcp`: Evalúa qué partes del agente conviene exponer a la economía de agentes y cómo: qué modelar como tool \(capacidad accionable\), resource \(doc/dato legible\) o prompt \(plantilla\), y qué merece UI vs API/MCP.
- `checklist\_nacimiento`: Corre el checklist completo de 19 puntos contra la definición del agente. Es el gate final antes de mergear: el agente debe NACER cumpliéndolo, no corregirse después. Devuelve veredicto punto por punto.
- `validar\_veredicto`: Cierra el ciclo de checklist\_nacimiento con un contrato a nivel protocolo. Pasale los 19 puntos con su estado \(ok\|parcial\|falta\) y devuelve structuredContent validado: conteos y veredicto normalizado \(apto solo si faltas === 0\). Pensada para consumo programático / gates de CI: no depende de parsear
- `construir\_agente`: El paso de CIERRE del flujo: toma la definición iterada \(tras pasar por las revisiones\) y produce el artefacto final listo para usar: identity layer, tools con least-privilege, límites duros, schema de output, gates, contexto, evaluación. Llamala cuando checklist\_nacimiento dé APTO.
- `plan\_de\_inicio`: Genera el plan de arranque correcto para un agente nuevo: un agente, un problema concreto, un humano revisando. Verifica que la tarea elegida sea recurrente, costosa en tiempo y con datos accesibles.

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html