GitHub Agent Finder apunta a un problema real: los agentes no pueden cargar todos los MCP servers, skills y herramientas por si acaso. La mejora no es descubrir más cosas; es descubrir solo lo permitido, con ranking, política y decisión humana.
GitHub Agent Finder es una capa de descubrimiento para Copilot que busca capacidades relevantes para una tarea - MCP servers, tools, skills, agentes o canvases - en un registro permitido y devuelve matches ordenados para usarlos bajo demanda.
Plan de despliegue TL;DR La keyword principal es
GitHub Agent Finder; la intención de búsqueda en español es entender qué es, cómo encaja con ARD/MCP registries y qué controles necesita un equipo antes de permitir discovery dinámica de herramientas. Mi postura: Agent Finder es una buena dirección porque reduce contexto basura y configuración manual. Pero si lo tratas como una tienda de plugins, vas a crear el mismo problema de permisos que ya tenías con MCP, solo con mejor UX.
Qué problema resuelve GitHub Agent Finder
Una definición citable: GitHub Agent Finder es un servicio de discovery para Copilot que consulta catálogos compatibles con Agentic Resource Discovery (ARD) y ayuda a encontrar capacidades adecuadas para una tarea sin preconfigurar todas las integraciones en cada agente.
El problema es familiar para cualquier equipo que haya probado MCP o agentes custom. Empiezas con un servidor de GitHub, añades uno de documentación, luego CI, navegador, base de datos, cloud, tickets y un par de skills. En poco tiempo el agente tiene demasiado contexto, demasiadas tools y una frontera de permisos que nadie sabe explicar.
Agent Finder cambia el centro de gravedad: en vez de cargar todo por defecto, Copilot puede buscar en un índice de recursos y proponer capacidades relevantes. Eso es útil solo si el índice está gobernado. La discovery sin política es shadow IT con ranking.
Lectura práctica ARD en una frase: catálogo, registro y ranking ARD no es otro framework de agentes. Es una especificación de discovery: define cómo publicar, describir, buscar y verificar recursos agentic, desde MCP servers hasta skills, agentes y herramientas tradicionales. La distinción importante es entre catálogo y registro. Un catálogo publica recursos y metadatos; un registro o discovery service los indexa y responde búsquedas. Agent Finder se apoya en ese modelo para que Copilot no dependa de una lista estática pegada en un JSON o en un perfil de agente. Para equipos, la pregunta correcta no es
qué puede descubrir Copilot. La pregunta correcta esqué catálogos puede consultar Copilot, quién aprueba esos recursos, qué scopes tienen y cómo revocamos acceso.
Modelo recomendado: Agent Finder descubre y rankea capacidades, pero la ejecución real debe quedar separada por scopes, allowlists, logs y aprobación humana cuando haya acciones mutantes.
Qué descubre realmente
La documentación de GitHub describe Agent Finder como una forma de encontrar capacidades como MCP servers, tools, agents y skills en tiempo de ejecución. El anuncio añade canvases dentro del conjunto de recursos que puede considerar.
Eso importa porque capacidad no significa siempre lo mismo. Un MCP server puede exponer una tool mutante sobre GitHub. Una skill puede ser una guía operativa en Markdown. Un custom agent puede traer instrucciones, herramientas y comportamiento especializado. Un canvas puede ser una superficie de trabajo compartida.
Mezclarlos bajo discovery común tiene sentido para UX, pero no para riesgo. Un skill de solo lectura y un MCP server con permisos de escritura en producción no merecen el mismo proceso de aprobación.
La promesa buena: menos contexto muerto
El beneficio más claro es reducir contexto muerto. Hoy muchos setups cargan todos los servidores MCP o todas las instrucciones por si acaso. Eso ensucia el prompt, aumenta coste, introduce ambigüedad y abre más caminos para prompt injection indirecta.
Si Agent Finder funciona bien, el agente no necesita arrastrar cada tool en cada sesión. Describe la tarea, consulta recursos relevantes, obtiene matches rankeados y solo entonces decide qué incorporar.
Ese patrón es mejor que la configuración estática infinita. Pero no elimina la revisión: un ranking no es una autorización. Ranking responde qué parece útil; política responde qué se puede usar.
La promesa peligrosa: discovery como sustituto de gobierno
El fallo fácil sería vender Agent Finder como automatización mágica: el agente encuentra lo que necesita y listo. Eso es exactamente lo que no debes permitir en repos privados, datos de clientes, billing, cloud o CI/CD.
GitHub insiste en tres límites sanos: puedes apuntar a registros públicos o privados, los recursos descubiertos se acotan por settings gestionados y Agent Finder no instala ni conecta silenciosamente nada. Esos tres detalles son la diferencia entre discovery útil y permiso implícito.
En un equipo serio, Agent Finder debería devolver opciones, no conceder autoridad. La persona o política del entorno decide si una capacidad entra en la sesión y con qué alcance.
Briefing Cómo lo usaría en un equipo dev Primero, separaría registros. Un registro público para exploración y aprendizaje. Un registro privado para recursos internos aprobados. Nada de mezclar servidores de demo con herramientas que tocan repos, issues, secrets, observabilidad o bases de datos. Segundo, modelaría recursos por intención.
leer documentación,triage de issues,depurar CI,proponer PR,consultar métricasymutar infraestructurason categorías distintas. La categoría debería determinar scopes, logs y aprobación.
Tercero, publicaría skills y agentes custom como código revisable. Un SKILL.md o un perfil de agente no es documentación inocente: puede guiar decisiones de producción. Debe pasar por PR, ownership y versionado.
Lectura práctica MCP registry no es lo mismo que barra libre de MCP GitHub ya documenta políticas para gestionar uso de MCP en organizaciones y empresas: bloquear MCP, restringirlo a registros definidos y aplicar settings en superficies soportadas como IDEs y Copilot CLI. Agent Finder se apoya en esa misma lógica de registro: descubre dentro de las fuentes que permites. Si el registro está mal curado, el resultado estará mal curado. Si el registro separa lectura, escritura, producción y sandbox, la discovery empieza a ser operable. Mi regla: ningún recurso descubierto dinámicamente debería tener más permisos que una integración configurada a mano. La discovery debe reducir fricción, no subir privilegios por comodidad.
Skills y custom agents: el riesgo no está solo en las APIs
La documentación de GitHub para agent skills usa SKILL.md con frontmatter e instrucciones, y permite ubicaciones de proyecto, personales y compartidas. Los custom agents usan perfiles Markdown con identidad, descripción, tools y configuración de MCP.
Eso es potente porque convierte conocimiento de equipo en componentes reutilizables. También es delicado: una skill puede enseñar al agente a ignorar señales, ejecutar comandos demasiado amplios o confiar en fuentes no revisadas.
Por eso trataría skills, agents y MCP servers como dependencias. Tienen owners, versión, changelog, scope y tests de comportamiento. Si no sabes quién mantiene una capacidad, no debería aparecer en el registro interno.
Checklist de adopción
Define si Agent Finder usará catálogo público, registro privado o ambos.
Separa recursos exploratorios de recursos aprobados para trabajo real.
Clasifica capacidades por lectura, inspección, escritura y mutación crítica.
Haz que skills y custom agents internos vivan en repos revisables.
No permitas auto-instalación ni auto-conexión de capacidades mutantes.
Registra qué recurso descubrió Copilot, por qué tarea y quién lo autorizó.
Empieza con recursos de documentación y CI de solo lectura.
Exige scopes mínimos para MCP servers y revocación sencilla.
Prueba custom agents en privado antes de liberarlos a toda la organización.
Mide si baja el contexto cargado y los errores de herramienta, no solo si parece más cómodo.
Errores que evitaría
El primero es confundir discovery con confianza. Que Agent Finder encuentre una capacidad no significa que sea correcta para tu repo, tus datos o tu compliance.
El segundo es crear un registro privado que acaba siendo un cajón desastre. Si todo entra, el registro no gobierna; solo maquilla el desorden.
El tercero es no revisar las instrucciones. En agentes, el riesgo puede estar en una API, pero también en una frase de SKILL.md que empuja al modelo a actuar fuera del procedimiento esperado.
Implementación mínima razonable
Paso 1: inventaria tus capacidades actuales: MCP servers, skills, custom agents, scripts y herramientas que ya usa el equipo.
Paso 2: elimina duplicados y clasifica cada capacidad por intención, datos accesibles, acciones posibles y owner.
Paso 3: crea un registro privado pequeño con recursos de bajo riesgo y documentación interna.
Paso 4: prueba Agent Finder con tareas reales pero no críticas, observando qué matches devuelve y qué contexto evita cargar.
Paso 5: añade capacidades mutantes solo cuando puedas limitar scopes, auditar uso y exigir aprobación humana.
Briefing Conclusión GitHub Agent Finder es una respuesta sensata a un problema que MCP hizo visible: no puedes escalar agentes si cada sesión arrastra todas las tools, todos los skills y todos los agentes por si acaso. La parte importante no es que Copilot descubra más recursos. Es que descubra menos recursos, mejores, permitidos y relevantes. Si tu adopción termina con un catálogo más ordenado, menos contexto cargado y permisos más estrechos, Agent Finder aporta. Si termina con otro marketplace sin ownership, solo has cambiado el nombre del desorden.
Preguntas frecuentes
¿Qué es GitHub Agent Finder?
GitHub Agent Finder es una capacidad de Copilot para descubrir recursos de IA, como MCP servers, tools, skills y agentes, consultando registros compatibles con ARD y devolviendo matches relevantes para una tarea.
¿Qué es ARD?
Agentic Resource Discovery es una especificación abierta para publicar, descubrir y verificar capacidades agentic en la web o en registros privados.
¿Agent Finder instala herramientas automáticamente?
No. Según GitHub, Agent Finder encuentra opciones y devuelve matches, pero no conecta ni instala silenciosamente recursos.
¿En qué se diferencia de configurar MCP servers a mano?
La configuración manual enumera recursos por adelantado; Agent Finder permite buscar capacidades en tiempo de ejecución dentro de registros permitidos.
¿Es seguro usar Agent Finder en una empresa?
Puede serlo si usas registros privados, settings gestionados, scopes mínimos, logs y aprobación humana para acciones mutantes. No debería usarse como permiso implícito.
¿Qué debería meter primero en un registro privado?
Recursos de bajo riesgo: documentación interna, skills de diagnóstico, herramientas de lectura y agentes custom probados en repos no críticos.
Cierre editorial Regla operativa Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.
Fuentes y referencias
GitHub Changelog: Agent finder for GitHub Copilot now available
Google Developers Blog: Announcing Agentic Resource Discovery
Publicado originalmente en devaisemanal.com. Si te sirve este tipo de análisis, suscríbete gratis a DevAI Semanal — herramientas de IA para devs, agentes, MCP y seguridad, resumidas cada semana en español.
