-
licenseNot graded
qualityA
maintenanceMCP Server for the GitHub API, enabling file operations, repository management, search functionality, and more.
117,296
90,042
MIT
github-talent-mcp
github-talent-mcp
Servidor MCP que busca, puntúa y clasifica desarrolladores de GitHub para reclutamiento técnico.
Funciona con Claude (Code y Desktop), GitHub Copilot (CLI y aplicación de escritorio) y Cursor (IDE y Grok Bot) — cualquier cliente MCP que hable stdio.
Marca
Related MCP server: mcp-github-server
Demo
https://github.com/user-attachments/assets/b2dbe9e0-26ee-4849-861a-4b5cb268facc
Buscando candidatos para una descripción de puesto real de Anthropic, en vivo en Claude Cowork.
https://github.com/user-attachments/assets/2dfd82b4-3eb5-4f2b-bc0a-2580b95043e4
Inmersión en el perfil
Obtén el perfil completo del desarrollador y la puntuación de actividad de torvalds en GitHub
Claude llama a get_developer_profile("torvalds") y devuelve:
Campo | Valor |
Puntuación de actividad | 150 (se aplica el mínimo de reputación) |
Ubicación | Portland, OR |
Seguidores | 293,321 |
Estrellas recibidas | 235,068 |
Lenguaje principal | C (98.1%) |
Commits (90d) | 0 |
PRs (90d) | 0 |
Repos notables | linux (183K estrellas), libdc-for-dirk, subsurface-for-dirk, uemacs, pesern-resolve |
README del perfil | No |
Contratable | No |
Torvalds tiene cero actividad reciente en GitHub porque el desarrollo del kernel fluye a través de listas de correo, no de PRs de GitHub. El mínimo de reputación (293K seguidores) anula la puntuación de comportamiento y la establece en 150.
Clasificación de contribuyentes de repos
Obtén los principales contribuyentes de huggingface/transformers y clasifícalos para un rol de ingeniero ML fundador en una startup de IA
Claude llama a get_repo_contributors("huggingface/transformers") → rank_candidates sobre los 24 principales contribuyentes:
Rango | Desarrollador | Puntuación combinada | Actividad | Relevancia | Fortalezas |
1 | stas00 | 83.4 | 150 | 72 | 4,553 estrellas, contribuye a OSS importante, repos con licencia MIT |
2 | cyyever | 80.8 | 120 | 64 | 1,217 seguidores, contribuyente activo, README de perfil |
3 | Cyrilvallez | 77.2 | 120 | 56 | Activo: 13 commits + 57 PRs en 90 días, fuerte presencia en OSS |
4 | ArthurZucker | 74.4 | 120 | 48 | 37 PRs en 90 días, contribuye a huggingface/transformers |
5 | ydshieh | 72.0 | 120 | 40 | Activo: 9 commits + 40 PRs en 90 días |
Puntuación combinada = actividad × 0.4 + relevancia × 0.6. La relevancia es la superposición de palabras clave con la descripción del puesto (ML, IA, startup, ingeniero, etc.).
Instalación
1. Instalar uv
El servidor se ejecuta a través de uvx, que lo descarga y lo lanza por ti — sin clonar, sin virtualenv, y recibes actualizaciones automáticamente.
brew install uv¿No tienes Homebrew? curl -LsSf https://astral.sh/uv/install.sh | sh
2. Crear un token de acceso personal de GitHub
Sin un token, GitHub permite 60 solicitudes por hora, y un solo perfil de candidato cuesta 6-15 de ellas. Te quedarás sin solicitudes a mitad de la búsqueda y los perfiles volverán vacíos. Con un token obtienes 5,000 por hora.
Ve a github.com/settings/tokens y crea un token de grano fino o clásico con estos ámbitos:
Ámbito | Por qué |
| Leer perfiles de usuario y buscar usuarios |
| Leer datos de repos públicos, lenguajes, contribuyentes |
Copia el token — no podrás verlo de nuevo después de salir de la página.
3. Conectarlo
GitHub Copilot (CLI y aplicación de escritorio)
Importante: Pon el token en la configuración, no ${GITHUB_TOKEN}. Las aplicaciones de escritorio son lanzadas por el sistema operativo, no por tu shell, por lo que nunca leen .zshrc y una referencia a variable de entorno se expande a nada. El servidor entonces arranca bien, se ejecuta sin autenticación y falla silenciosamente a algunos candidatos. Un archivo .env tiene el mismo problema a menos que la configuración también establezca cwd al directorio del proyecto, porque se lee relativo al directorio de trabajo.
Ambos comparten una configuración. Pega esto en una terminal — rellena tu token por ti:
mkdir -p ~/.copilot
TOKEN=$(gh auth token) # or: TOKEN=github_pat_xxxxxxxx
cat > ~/.copilot/mcp-config.json <<EOF
{
"mcpServers": {
"github-talent": {
"type": "local",
"command": "uvx",
"args": ["github-talent-mcp"],
"env": { "GITHUB_TOKEN": "$TOKEN" },
"tools": ["*"]
}
}
}
EOF
chmod 600 ~/.copilot/mcp-config.jsonSal de Copilot por completo y vuelve a abrirlo, luego ejecuta /mcp show — deberías ver 9 herramientas bajo github-talent. La aplicación también acepta servidores en Configuración → MCP si prefieres no tocar un archivo.
Si uvx no se encuentra, da su ruta completa como command (which uvx la imprime).
Claude Code
claude mcp add github-talent --env GITHUB_TOKEN=github_pat_xxxxxxxx -- uvx github-talent-mcpReinicia Claude Code y verifica con /mcp.
Claude Desktop
Importante: La misma regla de token en la configuración aplica aquí.
Añade a ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"github-talent": {
"command": "uvx",
"args": ["github-talent-mcp"],
"env": {
"GITHUB_TOKEN": "github_pat_xxxxxxxx"
}
}
}
}Reinicia Claude Desktop.
Cursor IDE y Cloud Agents (Grok Bot)
Nota: Se ha enviado una aplicación de marketplace y actualmente está en revisión. ${GITHUB_TOKEN} en mcp.json y .cursor-plugin/plugin.json de este repositorio es una variable de plugin para esa ruta de instalación. Cloud Agents y un mcp.json escrito a mano no la expanden. Pega el PAT.
Después del listado en marketplace (Cursor IDE con un clic):
Instala
uvsi aún no está en tu máquina:brew install uv¿No tienes Homebrew?
curl -LsSf https://astral.sh/uv/install.sh | shEn Cursor IDE, ve a Plugins → Añadir, busca GitHub Talent Search e instálalo.
Cuando se te solicite, introduce tu token de acceso personal de GitHub (de grano fino con ámbitos
read:userypublic_repo).
Hasta la aprobación del marketplace — Cursor IDE:
Crea un enlace simbólico de este repositorio a ~/.cursor/plugins/local/github-talent-mcp/, luego recarga Cursor (Cmd/Ctrl+Shift+P → Recargar ventana).
mkdir -p ~/.cursor/plugins/local
ln -s /path/to/github-talent-mcp ~/.cursor/plugins/local/github-talent-mcpO añade un mcp.json de usuario/proyecto (~/.cursor/mcp.json o .cursor/mcp.json) con el comando uvx, argumentos ["github-talent-mcp"] y GITHUB_TOKEN establecido al PAT en sí. La interpolación de escritorio, si la usas, es ${env:GITHUB_TOKEN} — no ${GITHUB_TOKEN}. Si el spawn falla, establece command a la ruta completa de which uvx (a menudo /opt/homebrew/bin/uvx en Apple Silicon Homebrew).
Hasta la aprobación del marketplace — Cloud Agents (cursor.com/agents):
No hay menú desplegable de MCP en la página de inicio de agents (Environment, Secrets y Set Up Cloud Agents no son esto). El control es el botón + a la izquierda del selector de modelo.
Pon
uvxen el PATH predeterminado de la VM del Cloud Agent. El spawn de MCP stdio no lee.bashrc. Siuvxsolo está en~/.local/bin, el servidor falla conspawn uvx ENOENTy carga 0 herramientas. Añade esto al script de Install del entorno, guarda, luego inicia un nuevo agente:curl -LsSf https://astral.sh/uv/install.sh | sh sudo install -m 0755 "$HOME/.local/bin/uv" /usr/local/bin/uv sudo install -m 0755 "$HOME/.local/bin/uvx" /usr/local/bin/uvxEn cursor.com/agents, haz clic en + → MCP Servers. Edita
github-talentsi ya está listado; de lo contrario, Añadir MCP.En Editar servidor MCP:
Nombre:
github-talentTipo: Comando (no URL). Este servidor es stdio, no HTTP. Cloud Agents no soportan SSE.
Comando:
uvxArgumentos:
github-talent-mcp(deja las filas de Argumento extra vacías)Secretos: Clave
GITHUB_TOKEN, Valor tu PAT (ghp_ogithub_pat_). Pega el token. Un secreto del panel de Environment llamadoGITHUB_TOKENno se copia al entorno MCP.No establezcas Comando a
/home/box/bin/github-talent-mcp.sh. Esa ruta no está en las VMs de Cloud Agent; el namespace se adjunta y aún así carga 0 herramientas.
Guarda. Activa
github-talent. Inicia un nuevo Cloud Agent — las ejecuciones existentes mantienen el lanzador antiguo. Deberías ver 9 herramientas bajogithub-talent.
Comprobar que realmente funciona
Llama a get_developer_profile (la herramienta MCP, no python / gh / curl). Un perfil real tiene 120-170 líneas. Tres líneas significa que la llamada falló — casi siempre un token faltante o ilegible. Cada herramienta que devuelve tres líneas mientras el servidor aún muestra como conectado es la firma de ejecutarse sin autenticación.
Una tabla formateada de Torvalds no es prueba de MCP. Cloud Agents pueden importar github_talent_mcp de este repositorio e imprimir el mismo perfil de ~149 líneas mientras el descubrimiento de MCP aún falla (spawn uvx ENOENT). Confirma que las 9 herramientas se cargaron y que la llamada pasó por la herramienta MCP.
Ejecutar desde el código fuente
Solo es necesario si quieres modificar el servidor:
git clone https://github.com/carolinacherry/github-talent-mcp.git
cd github-talent-mcp
uv syncLuego usa uv run --directory /path/to/github-talent-mcp github-talent-mcp como comando en cualquier configuración anterior.
Pruébalo
Una vez instalado, pega estos prompts para verificar que todo funciona:
Búsqueda básica:
Encuentra desarrolladores de Python en Raleigh activos en los últimos 60 días
Inmersión en el perfil:
Obtén el perfil completo del desarrollador y la puntuación de actividad de torvalds en GitHub
Flujo de trabajo completo:
Encuentra 10 ingenieros de ML en San Francisco activos en los últimos 30 días, luego clasifícalos para un rol de ingeniero senior de inferencia LLM
Contribuyentes de repos:
Obtén los principales contribuyentes de huggingface/transformers y clasifícalos para un rol de ingeniero ML fundador en una startup de IA
Puntuación de descripción de puesto:
Puntúa a estos candidatos contra esta descripción de puesto: [pega la descripción]. Candidatos: tiangolo, karpathy, hwchase17
Comparar candidatos:
Compara a tiangolo y hwchase17 para un rol de Ingeniero Senior de IA en Python
Puntuación masiva:
Puntúa estos 10 nombres de usuario de GitHub y dame una tabla clasificada: [pega la lista]
Contacto:
Genera un mensaje casual de reclutador para tiangolo sobre un rol Senior de Python en Acme. Mi nombre es Daniel.
Sourcing con entrevista primero
Las indicaciones vagas producen listas cortas vagas, por lo que el servidor está diseñado para entrevistarte antes de buscar. Pídele que "encuentre candidatos para un rol" y llamará a plan_search primero: detecta la familia de roles y hace preguntas de seguimiento específicas (seniority, habilidades imprescindibles, ubicación, factores excluyentes) y, lo más importante, pide la descripción del puesto: pega el texto completo o comparte un enlace público y pega lo que muestre. Solo busca una vez que tiene criterios reales.
Pruébalo: "Encuéntrame ingenieros de seguridad senior." → el asistente debería pedirte la descripción del puesto y tus requisitos imprescindibles antes de ejecutar nada.
¿Prefieres una ejecución rápida y repetible? Dale todo de antemano — "Clasifica estos 15 nombres de usuario contra esta descripción de puesto: …" — o fija la búsqueda a repositorios específicos, y omitirá la entrevista.
Tools
Tool | Descripción |
| Paso de entrada: analiza una solicitud de búsqueda, detecta la familia de roles y devuelve preguntas de seguimiento específicas (incluyendo: pegar la descripción del puesto o compartir un enlace público) para hacer antes de buscar. Llama a esto primero. |
| Busca usuarios de GitHub por idioma, ubicación, actividad, seguidores. Para búsqueda basada en temas, usa |
| Enriquecimiento profundo de perfil: idiomas, estrellas, commits + PRs, contribuciones OSS, desglose de licencias, README de perfil y puntuación de actividad con desglose. |
| Clasifica nombres de usuario contra una descripción de puesto. Devuelve candidatos ordenados con puntuación combinada, fortalezas, carencias y razonamiento. |
| Puntúa candidatos contra una descripción de puesto con desglose por dimensión (stack tecnológico, nivel de experiencia, señal OSS, liderazgo). Devuelve carencias y preguntas de entrevista personalizadas. |
| Comparación lado a lado de 2-5 candidatos. Muestra ganadores por dimensión y una recomendación. Opcionalmente puntuados contra una descripción de puesto. |
| Puntúa hasta 100 nombres de usuario de GitHub en una sola llamada. Devuelve una tabla markdown ordenada o CSV. Admite coincidencia opcional con descripción de puesto. |
| Genera mensajes de reclutador personalizados (cortos/medianos/detallados) que hacen referencia a los repositorios y contribuciones reales del candidato. Requiere el nombre de tu empresa y el nombre del remitente. Tono informal o formal. |
| Principales contribuyentes de cualquier repositorio. Acepta |
Scoring
La puntuación de actividad combina dos capas: señales de comportamiento (lo que hiciste recientemente) y un suelo de reputación (lo que has construido con el tiempo).
Puntuación de comportamiento (0-205)
Señal | Puntos máximos | Cómo |
Commits + PRs (últimos 90 días) | 60 | Commits push + aperturas de PR (PRs ponderados x3). Captura tanto flujos de trabajo basados en push como en PR. |
Estrellas en repositorios | 40 | Estrellas de repositorios personales + estrellas en repositorios a los que contribuyes. Los mantenedores de repositorios de organizaciones reciben crédito. |
README de perfil | 20 | Presencia de un README de perfil (github.com/username/username). |
Seguidores | 20 | Limitado a 20. |
Repositorios con descripciones | 20 | Proporción de repositorios que tienen descripciones. Señal de cuidado y pulido. |
Repositorios con licencia permisiva | 15 | Tiene al menos un repositorio con MIT, Apache-2.0, BSD, ISC o Unlicense. |
Contribuciones OSS importantes | 30 | PRs, pushes o issues en repositorios que no posees. Limitado a 3 repositorios (10 pts cada uno). |
Suelo de reputación
La puntuación de comportamiento por sí sola penaliza a los desarrolladores cuyo trabajo no produce eventos de GitHub: Torvalds trabaja a través de listas de correo, los mantenedores senior fusionan mediante bots de organización, y muchos ingenieros trabajan en repositorios privados.
El suelo de reputación garantiza que el impacto acumulado no se borre por un trimestre tranquilo:
Umbral | Suelo |
10K+ seguidores o 50K+ estrellas | 150 |
1K+ seguidores o 5K+ estrellas | 120 |
500+ seguidores o 1K+ estrellas | 100 |
100+ seguidores o 200+ estrellas | 80 |
La puntuación final es max(behavioral_score, reputation_floor). Si se aplica el suelo, el desglose incluye un campo reputation_floor para que lo sepas.
Niveles de puntuación
150+ — excepcional (principales mantenedores de OSS, ingenieros conocidos)
120-149 — señal fuerte, vale la pena contactar
80-119 — desarrollador sólido con trabajo público significativo
40-79 — activo pero con señal pública limitada
<40 — señal baja (probablemente trabajo privado o junior)
Clasificación
rank_candidates combina la puntuación de actividad con una puntuación de relevancia (0-100) basada en la superposición de palabras clave entre la descripción del puesto y el perfil del candidato (bio, idiomas, temas de repositorio, README). La puntuación combinada pondera la relevancia al 60% y la actividad al 40%: un desarrollador con alta actividad pero sin superposición con el puesto no debería superar a uno relevante.
Panel interactivo
Después de que una búsqueda produce una lista corta, el servidor pregunta si quieres un panel interactivo: búsqueda, filtros de habilidades, clasificación, evidencia y enlaces a perfiles de GitHub. Responde que sí y tu asistente lo construye con su propia herramienta de artefactos (el lienzo de Copilot, los artefactos de Claude) a partir de los datos de candidatos puntuados.
Solo ofrece; no se construye nada a menos que digas que sí, y la oferta se omite cuando una búsqueda no produjo perfiles utilizables. Establece GITHUB_TALENT_DASHBOARD_PROMPT=0 para desactivarlo.
Si la página se abre en un lienzo en línea, ten en cuenta que esos paneles aíslan su contenido y bloquean enlaces salientes, por lo que también se le pide al asistente que abra el archivo guardado en tu navegador donde los enlaces de GitHub funcionan.
Límites de tasa
API REST de GitHub: 5,000 solicitudes/hora con token, 60 sin uno. Un solo perfil enriquecido cuesta 6-15 llamadas y un flujo de trabajo típico (búsqueda + enriquecer 5 candidatos + clasificar) usa ~60-100, por lo que un servidor no autenticado se agota en una sola búsqueda. Los resultados de perfil se almacenan en caché dentro de una sesión para evitar llamadas redundantes durante la clasificación.
Dos límites son separados de ese presupuesto por hora y vale la pena conocerlos:
Endpoints de búsqueda (
/search/commits,/search/issues) permiten solo 30 solicitudes/minuto incluso con token. El servidor trata un fallo allí como un recuento de actividad desconocido en lugar de un perfil fallido, por lo que la lista corta aún regresa: los recuentos de commits pueden simplemente leerse como 0.Límites de tasa secundarios se activan en ráfagas de solicitudes concurrentes y devuelven un
Retry-Afterexplícito. El servidor espera exactamente ese tiempo, hasta 30 segundos, y luego se rinde en lugar de reintentar en una ventana que no se ha levantado.
Limitaciones y uso responsable
Esta herramienta puntúa la actividad pública de GitHub como una señal para la búsqueda técnica. Conoce sus límites antes de confiar en ella:
Los resultados varían entre ejecuciones. Está impulsado por IA: el asistente decide qué repositorios y búsquedas explorar, por lo que la misma indicación puede mostrar una lista corta diferente cada vez. La puntuación en sí es determinista para un conjunto dado de candidatos; la variación proviene de la búsqueda. Para ejecuciones repetibles, restringe la búsqueda: nombra los repositorios de los que extraer contribuyentes, o dale una lista explícita de nombres de usuario para clasificar.
GitHub no es todo el ingeniero. La actividad pública es una fuerte evidencia de trabajo técnico, pero es ciega a las contribuciones de repositorios privados e internos/empresariales, y a ecosistemas no GitHub (listas de correo, GitLab, etc.). No puede verificar el historial de gestión de personas o liderazgo: confirma eso fuera de GitHub. (El suelo de reputación existe precisamente porque baja actividad reciente ≠ baja capacidad.)
Úsala como generador de leads, no como filtro. La visibilidad pública en OSS se correlaciona con tiempo libre, antigüedad y circunstancias, no solo con habilidad, y eso sesga entre demografías. Trata las puntuaciones como un punto de partida para el contacto y el juicio humano. No las uses para excluir automáticamente a candidatos, y siempre acompáñalas con una evaluación equitativa y relevante al rol.
Los datos son en vivo y con límite de tasa. Las puntuaciones reflejan GitHub en el momento de la consulta y cambian a medida que la actividad varía; un servidor no autenticado está limitado a 60 solicitudes/hora.
Licencia
Apache License 2.0 © 2026 Daniel An. Las versiones publicadas hasta la 0.4.0 inclusive permanecen bajo la Licencia MIT; desde 0.4.1 en adelante es Apache-2.0.
Available Tools
8 toolsbulk_scoreA
Score a batch of GitHub usernames and return a ranked table.
Enriches each profile and ranks by activity score (or JD fit if a job description is provided). Returns a markdown table or CSV.
Args: usernames: List of GitHub usernames (max 100) job_description: Optional JD for relevance scoring export_format: Output format - "markdown" (default) or "csv" top_n: Max candidates in output (default 100)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| usernames | Yes | ||
| job_description | No | ||
| export_format | No | markdown | |
| top_n | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It discloses enrichment, ranking, and output format, but does not mention side effects, rate limits, authentication needs, or whether it is read-only. Adequate but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and uses a structured Args format. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and that an output schema exists, the description adequately explains return format and main parameters. However, it lacks details on error handling, scoring methodology, and sorting behavior, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by describing each parameter: usernames (max 100), job_description (optional), export_format (markdown/csv), top_n (default 100). Adds constraints and enum guidance not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scores a batch of GitHub usernames and returns a ranked table. It specifies batch processing and enrichment with activity score or JD fit, distinguishing it from siblings like score_against_jd which likely handles single users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch scoring (explicitly says 'batch') but does not explicitly name when to use this versus alternatives like rank_candidates or score_against_jd. It provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_candidatesA
Compare 2-5 GitHub candidates side-by-side.
Shows each candidate's languages, activity, stars, strengths, and gaps. If a job description is provided, also scores each candidate against it and picks winners per dimension.
Args: usernames: 2-5 GitHub usernames to compare job_description: Optional job description for JD-aware comparison
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| usernames | Yes | ||
| job_description | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what the tool shows and does (scoring, picking winners), but does not mention data sources, side effects, or whether it fetches data. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded, every sentence adds value. Bullet-like list and Args section are clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: what is compared, optional JD, output format implied by attributes. Output schema exists, so no need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: specifies usernames must be 2-5, job_description is optional. The schema only has titles, so description compensates for 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it compares 2-5 GitHub candidates side-by-side, listing displayed attributes (languages, activity, stars, strengths, gaps) and optional job description scoring. Distinguishes from siblings like score_against_jd and rank_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case (comparing multiple candidates with optional JD) and sibling context, but does not explicitly state when not to use or compare to specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_outreachA
Generate personalized recruiter outreach messages for a GitHub candidate.
Creates three message variants (short, medium, detailed) that reference the candidate's actual repos, contributions, and tech stack.
IMPORTANT: Always ask the user for their company_name and sender_name before calling this tool. If not provided, placeholders will be used.
Args: username: GitHub username of the candidate job_description: The role description company_name: Your company name (ask the user) sender_name: Your name as the recruiter/hiring manager (ask the user) tone: Message tone - "casual" (default) or "formal"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| job_description | Yes | ||
| company_name | No | [Your Company] | |
| sender_name | No | [Your Name] | |
| tone | No | casual |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that three variants are created, references candidate's repos/contributions/tech stack, and warns about placeholders if company_name/sender_name are not provided. This covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and front-loads the purpose. The all-caps warning is prominent. It could be slightly more concise, but it remains readable and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to detail return values. It covers purpose, usage, parameters, and behavioral notes comprehensively for a 5-parameter tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides clear explanations for all five parameters, including defaults and the behavior if omitted (e.g., placeholders for company_name and sender_name). The tone parameter specifies allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates personalized recruiter outreach messages for a GitHub candidate, creating three message variants. This is distinct from sibling tools like bulk_score or search_developers, which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to ask the user for company_name and sender_name before calling the tool, providing clear usage context. It does not, however, specify when not to use the tool or mention alternatives, but the purpose is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developer_profileA
Get enriched GitHub developer profile with activity scoring.
Returns languages, stars, commit activity, OSS contributions, profile README, license breakdown, and a 0-205 activity score with per-dimension breakdown.
Args: username: GitHub username to analyze
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It details the return content including an activity score with per-dimension breakdown. However, it does not mention potential side effects (none expected), authentication needs, or rate limits, which would increase transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-sentence purpose, a bulleted list of return contents, and an Args line. Every sentence provides value with no redundancy or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and the description already enumerates the returned data (languages, stars, commit activity, etc.), the description is complete. It includes the unique activity score range and breakdown, covering all key aspects without needing further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explicitly lists the 'username' parameter with a clear explanation: 'GitHub username to analyze'. This adds essential meaning beyond the type 'string' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get enriched GitHub developer profile with activity scoring', which is a specific verb+resource combination. It clearly distinguishes from sibling tools like 'search_developers' (search) and 'rank_candidates' (ranking), as this tool focuses on a single enriched profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for individual developer profiles by listing single username and rich return data. While no explicit 'when to use vs alternatives' is stated, the context from sibling tool names suggests this is for detailed single-profile analysis, not for bulk or comparative operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_repo_contributorsA
Get top contributors for a GitHub repository as candidate leads.
Accepts 'owner/repo' format or full GitHub URL.
Args: repo: Repository in 'owner/repo' format or GitHub URL limit: Max contributors to return (default 25)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It does not mention authentication needs, rate limits, or error handling. The description only states the basic function without transparency on limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose, a format note, and args. Every sentence is essential and front-loaded. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. However, it lacks information on authentication, error scenarios, and usage context, making it adequately complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'repo' parameter by specifying accepted formats, but for 'limit' it only repeats the default from the schema. With 0% schema coverage, more parameter details would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves top contributors for lead generation, with a specific verb and resource. It distinguishes itself from siblings like search_developers or get_developer_profile by focusing on repository contributors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for lead generation but provides no explicit guidance on when to use this tool over siblings or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_candidatesA
Rank GitHub users against a job description.
Enriches each profile, scores activity + relevance, and returns candidates sorted by combined score with strengths, gaps, and reasoning.
Args: usernames: GitHub usernames to evaluate job_description: The role description to rank candidates against top_n: Number of top candidates to return (default 10)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| usernames | Yes | ||
| job_description | Yes | ||
| top_n | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states that the tool enriches profiles and scores them, implying a read-only operation. However, it does not disclose potential side effects (e.g., if external API calls are made), authentication requirements, or any rate limiting. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the main purpose, followed by a brief process summary and then bullet-point-like parameter explanations. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description reasonably explains the output: sorted candidates with strengths, gaps, and reasoning. It covers the key aspects of the tool's behavior and parameters. However, it could be more complete by clarifying what 'enriches each profile' entails or how the scoring accounts for activity and relevance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by defining each parameter: usernames as 'GitHub usernames to evaluate', job_description as 'The role description to rank candidates against', and top_n with default 10. These definitions are clear and add value beyond the schema's type and title information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Rank GitHub users against a job description.' It also explains the process: enriches profiles, scores activity+relevance, returns sorted candidates with strengths, gaps, and reasoning. This effectively communicates the core function, though it does not explicitly differentiate from similar sibling tools like 'score_against_jd' or 'compare_candidates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as 'score_against_jd' or 'compare_candidates'. There is no mention of prerequisites, limitations, or scenarios where this tool is preferred. The user is left to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_against_jdA
Score GitHub candidates against a job description with per-dimension breakdown.
Unlike rank_candidates (keyword matching), this extracts structured requirements from the JD and scores each candidate on: tech stack match, experience level, OSS signal, and leadership signals. Returns dimension scores, gaps, and personalized interview questions.
Args: job_description: Full job description text usernames: GitHub usernames to evaluate top_n: Number of top candidates to return (default 10)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_description | Yes | ||
| usernames | Yes | ||
| top_n | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not mention safety traits (read-only, destructive, auth needs). However, it describes outputs and operation, which is adequate for a scoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three purposeful sentences plus a structured args list. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema (not shown), the description covers key aspects: purpose, differentiation, and return contents. Could mention prerequisites like having candidate profiles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter's purpose (job description, usernames, top_n) beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores candidates against a job description with per-dimension breakdown. It distinguishes itself from rank_candidates by contrasting keyword matching with structured requirement extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use versus an alternative (rank_candidates), but does not cover exclusions or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_developersA
Search GitHub developers by technical and geographic filters.
Returns a list of matching usernames sorted by followers. Use get_developer_profile on interesting candidates for full enrichment and to verify recent activity.
For topic-based sourcing (e.g. "LLM", "inference"), use get_repo_contributors on relevant repos instead — GitHub user search doesn't support topic/bio search.
Args: languages: Filter by programming languages, e.g. ["python", "rust"] location: Filter by location, e.g. "San Francisco" or "Germany" min_followers: Minimum follower count min_repos: Minimum public repo count limit: Max results to return (default 20, max 100)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| languages | No | ||
| location | No | ||
| min_followers | No | ||
| min_repos | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output format (usernames sorted by followers) and limit constraints. Lacks details on case sensitivity or matching behavior, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then results, usage guidance, and args. Every sentence adds value; no fluff. Well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no required ones, and output schema exists, description covers all needed aspects: filters, results, usage guidance, and alternatives. Complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains all five parameters with types and examples (e.g., languages as array of strings, location string, default and max for limit), adding meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches GitHub developers by technical and geographic filters, returns usernames sorted by followers, and distinguishes itself from sibling tools like get_repo_contributors and get_developer_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use and when not to use: for topic-based sourcing, recommends get_repo_contributors instead, and for full enrichment, suggests get_developer_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.1/5.0
Disambiguation4/5
Tools are mostly distinct, but bulk_score, rank_candidates, and score_against_jd have overlapping ranking/scoring functionality that could confuse an agent. compare_candidates also overlaps with these for small sets. Still, each tool has a clear primary purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores (e.g., bulk_score, compare_candidates, generate_outreach). No mixing of conventions.
Tool Count5/5
8 tools is well-scoped for a developer sourcing server, covering search, enrichment, comparison, ranking, and outreach without being excessive.
Completeness4/5
Covers the main workflow (search, enrich, compare, rank, message), but lacks a direct topic-based search and saving/follow-up tools, which are minor gaps.
Maintenance
ActivityMaintained
ResponsivenessSlow
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Public MCP server for discovering open jobs. Search, filter, and get application links.
A MCP server built for developers enabling Git based project management with project and personal…
Create, deploy, and operate MCP servers directly from your GitHub repositories.
An MCP server that gives your AI access to the source code and docs of all public github repos
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA simple MCP server that provides repository information (list repos, get repo details) using GitHub's public REST API, without needing any API keys or tokens.
- AlicenseNot gradedqualityBmaintenanceMCP server for searching, retrieving details, suggesting, and adding curated GitHub repositories from a personal library.MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for GitHub operations, providing tools for repository management, issues, pull requests, and code search.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/carolinacherry/github-talent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server