What can you do with this server?

This MCP server searches, profiles, scores, and ranks GitHub developers for technical recruiting, with outreach and comparison tools. * Search developers by language, location, min followers/repos (up to 100 results) * Get enriched developer profiles with activity score, languages, stars, OSS contributions, and per-dimension breakdown * Rank candidates against a job description using combined activity + relevance scores * Score candidates against a JD with per-dimension breakdown (tech stack, experience, OSS signal, leadership) and interview questions * Compare 2–5 candidates side-by-side, optionally JD-aware * Bulk‑score up to 100 usernames into a ranked markdown table or CSV * Generate personalized recruiter outreach messages (casual/formal, referencing actual repos) * Fetch top repo contributors for topic‑based sourcing (owner/repo or full URL) * Plan a search (interview step) to gather role criteria and job description before sourcing * Interactive dashboard (optional) built via assistant artifacts after a search produces a shortlist

Which integrations are available for this server?

Integrates with GitHub to search, score, and rank developers for technical recruiting by analyzing profiles, contributions, and job description relevance.

How do I use github-talent-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@github-talent-mcp Find top React developers in New York active in the last 90 days" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

github-talent-mcp

by carolinacherry

Overview Schema Related Servers Score Discussions

Python

Remote

github-talent-mcp

License: Apache 2.0 Python 3.10+ MCP Claude GitHub Copilot Cursor Grok Bot GitHub API

MCP server that searches, scores, and ranks GitHub developers for technical recruiting.

Works with Claude (Code & Desktop), GitHub Copilot (CLI & desktop app), and Cursor (IDE & Grok Bot) — any MCP client that speaks stdio.

Brand

Related MCP server: mcp-github-server

Demo

https://github.com/user-attachments/assets/b2dbe9e0-26ee-4849-861a-4b5cb268facc

Sourcing candidates for a real Anthropic JD, live in Claude Cowork.

https://github.com/user-attachments/assets/2dfd82b4-3eb5-4f2b-bc0a-2580b95043e4

Profile deep dive

Get the full developer profile and activity score for torvalds on GitHub

Claude calls get_developer_profile("torvalds") and returns:

Field	Value
Activity Score	150 (reputation floor applied)
Location	Portland, OR
Followers	293,321
Stars Received	235,068
Primary Language	C (98.1%)
Commits (90d)	0
PRs (90d)	0
Notable Repos	linux (183K stars), libdc-for-dirk, subsurface-for-dirk, uemacs, pesern-resolve
Profile README	No
Hireable	No

Torvalds has zero recent GitHub activity because kernel development flows through mailing lists, not GitHub PRs. The reputation floor (293K followers) overrides the behavioral score and sets it to 150.

Repo contributor ranking

Get the top contributors to huggingface/transformers and rank them for a founding ML engineer role at an AI startup

Claude calls get_repo_contributors("huggingface/transformers") → rank_candidates on the top 24 contributors:

Rank	Developer	Combined Score	Activity	Relevance	Strengths
1	stas00	83.4	150	72	4,553 stars, contributes to major OSS, MIT-licensed repos
2	cyyever	80.8	120	64	1,217 followers, active contributor, profile README
3	Cyrilvallez	77.2	120	56	Active: 13 commits + 57 PRs in 90 days, strong OSS presence
4	ArthurZucker	74.4	120	48	37 PRs in 90 days, contributes to huggingface/transformers
5	ydshieh	72.0	120	40	Active: 9 commits + 40 PRs in 90 days

Combined score = activity × 0.4 + relevance × 0.6. Relevance is keyword overlap with the job description (ML, AI, startup, engineer, etc.).

Installation

1. Install `uv`

The server runs through uvx, which downloads and launches it for you — no clone, no virtualenv, and you get updates automatically.

brew install uv

No Homebrew? curl -LsSf https://astral.sh/uv/install.sh | sh

2. Create a GitHub personal access token

Without a token GitHub allows 60 requests per hour, and a single candidate profile costs 6-15 of them. You will run out mid-search and profiles will come back empty. With a token you get 5,000/hour.

Go to github.com/settings/tokens and create a fine-grained or classic token with these scopes:

Scope	Why
`read:user`	Read user profiles and search users
`public_repo`	Read public repo data, languages, contributors

Copy the token — you cannot view it again after leaving the page.

3. Connect it

GitHub Copilot (CLI and desktop app)

Important: Put the token itself in the config, not ${GITHUB_TOKEN}. Desktop apps are launched by the operating system, not by your shell, so they never read .zshrc and an environment variable reference expands to nothing. The server then starts fine, runs unauthenticated, and quietly fails a few candidates in. A .env file has the same problem unless the config also sets cwd to the project directory, because it is read relative to the working directory.

Both share one config. Paste this in a terminal — it fills in your token for you:

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.json

Quit Copilot completely and reopen it, then run /mcp show — you should see 9 tools under github-talent. The app also accepts servers under Settings → MCP if you would rather not touch a file.

If uvx is not found, give its full path as command (which uvx prints it).

Claude Code

claude mcp add github-talent --env GITHUB_TOKEN=github_pat_xxxxxxxx -- uvx github-talent-mcp

Restart Claude Code and verify with /mcp.

Claude Desktop

Important: Same token-in-config rule as Copilot applies here.

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "github-talent": {
      "command": "uvx",
      "args": ["github-talent-mcp"],
      "env": {
        "GITHUB_TOKEN": "github_pat_xxxxxxxx"
      }
    }
  }
}

Restart Claude Desktop.

Cursor IDE and Cloud Agents (Grok Bot)

Note: A marketplace application has been submitted and is currently in review. ${GITHUB_TOKEN} in this repo's mcp.json and .cursor-plugin/plugin.json is a plugin variable for that install path. Cloud Agents and a hand-written mcp.json do not expand it. Paste the PAT.

After marketplace listing (Cursor IDE one-click):

Install uv if not already on your machine:
```
brew install uv
```
No Homebrew? curl -LsSf https://astral.sh/uv/install.sh | sh
In Cursor IDE, go to Plugins → Add, search for GitHub Talent Search, and install it.
When prompted, enter your GitHub personal access token (fine-grained with read:user and public_repo scopes).

Until marketplace approval — Cursor IDE:

Symlink this repository to ~/.cursor/plugins/local/github-talent-mcp/, then reload Cursor (Cmd/Ctrl+Shift+P → Reload Window).

mkdir -p ~/.cursor/plugins/local
ln -s /path/to/github-talent-mcp ~/.cursor/plugins/local/github-talent-mcp

Or add a user/project mcp.json (~/.cursor/mcp.json or .cursor/mcp.json) with command uvx, args ["github-talent-mcp"], and GITHUB_TOKEN set to the PAT itself. Desktop interpolation, if you use it, is ${env:GITHUB_TOKEN} — not ${GITHUB_TOKEN}. If spawn fails, set command to the full path from which uvx (often /opt/homebrew/bin/uvx on Apple Silicon Homebrew).

Until marketplace approval — Cloud Agents (cursor.com/agents):

There is no MCP dropdown on the agents home page (Environment, Secrets, and Set Up Cloud Agents are not this). The control is the + button to the left of the model picker.

Put uvx on the Cloud Agent VM's default PATH. Stdio MCP spawn does not read .bashrc. If uvx is only in ~/.local/bin, the server fails with spawn uvx ENOENT and loads 0 tools. Add this to the environment Install script, Save, then start a new agent:
```
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/uvx
```
On cursor.com/agents, click + → MCP Servers. Edit github-talent if it is already listed; otherwise Add MCP.
In Edit MCP server:
- Name: github-talent
- Type: Command (not URL). This server is stdio, not HTTP. Cloud Agents do not support SSE.
- Command: uvx
- Arguments: github-talent-mcp (leave extra empty Argument rows blank)
- Secrets: Key GITHUB_TOKEN, Value your PAT (ghp_ or github_pat_). Paste the token. An Environment-panel secret named GITHUB_TOKEN does not copy into MCP env.
- Do not set Command to /home/box/bin/github-talent-mcp.sh. That path is not on Cloud Agent VMs; the namespace attaches and still loads 0 tools.
Save. Toggle github-talent on. Start a new Cloud Agent — existing runs keep the old launcher. You should see 9 tools under github-talent.

Grok Build

Note: This plugin has NOT been submitted to the xAI plugin marketplace yet. These are the install instructions for when that happens.

Prerequisites:

uvx on PATH — Install via brew install uv or curl -LsSf https://astral.sh/uv/install.sh | sh
GitHub Personal Access Token — Fine-grained PAT with read:user and public_repo scopes. Create at github.com/settings/tokens. Required for API rate limits (5,000/hr vs 60/hr unauthenticated).

Direct install from repository:

Install the plugin from GitHub:

grok plugin install carolinacherry/github-talent-mcp --trust

Set GITHUB_TOKEN in Grok's MCP environment configuration:
- The plugin requires this environment variable to authenticate with GitHub
- Set it where Grok configures MCP server environments
- Without the token, the server runs unauthenticated and will fail mid-search
Verify installation:
```
grok plugin list
```
You should see github-talent-mcp in the list.

After official marketplace listing:

Once the plugin is accepted into the xAI marketplace catalog, you'll be able to browse and install it from within Grok Build:

Type /marketplace in Grok Build
Search for "GitHub Talent Search"
Press i to install
Configure GITHUB_TOKEN in Grok's MCP settings

Marketplace submission path (not yet done):

To submit this plugin to the official marketplace:

Fork xai-org/plugin-marketplace
Add a plugin entry to .grok-plugin/marketplace.json pinned to a full 40-character commit SHA
Run validation: python3 scripts/validate-catalog.py
Regenerate the plugin index: python3 scripts/generate-plugin-index.py
Open a PR to xai-org/plugin-marketplace

See docs/grok-marketplace-submission.md for the draft entry and detailed submission steps.

Checking it actually works

Call get_developer_profile (the MCP tool, not python / gh / curl). A real profile is 120-170 lines. Three lines means the call failed — almost always a missing or unreadable token. Every tool returning three lines while the server still shows as connected is the signature of running unauthenticated.

A formatted Torvalds table is not proof of MCP. Cloud Agents can import github_talent_mcp from this repo and print the same ~149-line profile while MCP discovery is still failing (spawn uvx ENOENT). Confirm the 9 tools loaded and that the call went through the MCP tool.

Running from source

Only needed if you want to modify the server:

git clone https://github.com/carolinacherry/github-talent-mcp.git
cd github-talent-mcp
uv sync

Then use uv run --directory /path/to/github-talent-mcp github-talent-mcp as the command in any config above.

Try It

Once installed, paste these prompts to verify everything works:

Basic search:

Find Python developers in Raleigh active in the last 60 days

Profile deep dive:

Get the full developer profile and activity score for torvalds on GitHub

Full workflow:

Find 10 ML engineers in San Francisco active in the last 30 days, then rank them for a senior LLM inference engineer role

Repo contributors:

Get the top contributors to huggingface/transformers and rank them for a founding ML engineer role at an AI startup

JD scoring:

Score these candidates against this job description: [paste JD]. Candidates: tiangolo, karpathy, hwchase17

Compare candidates:

Compare tiangolo and hwchase17 for a Senior Python AI Engineer role

Bulk scoring:

Score these 10 GitHub usernames and give me a ranked table: [paste list]

Outreach:

Generate a casual recruiter message for tiangolo about a Senior Python role at Acme. My name is Daniel.

Interview-first sourcing

Vague prompts produce vague shortlists, so the server is built to interview you before it searches. Ask it to "find candidates for a role" and it calls plan_search first — it detects the role family and asks targeted follow-ups (seniority, must-have skills, location, dealbreakers) and, most importantly, for the job description: paste the full text, or share a public link and paste what it shows. It only sources once it has real criteria.

Try it: "Find me senior security engineers." → the assistant should ask for the JD and your must-haves before running anything.

Want a fast, repeatable run instead? Give it everything up front — "Rank these 15 usernames against this JD: …" — or pin the sourcing to specific repos, and it'll skip the interview.

Tools

Tool	Description
`plan_search`	Intake step — parses a sourcing request, detects the role family, and returns targeted follow-up questions (including: paste the JD or share a public link) to ask before searching. Call this first.
`search_developers`	Search GitHub users by language, location, activity, followers. For topic-based sourcing, use `get_repo_contributors` on relevant repos instead.
`get_developer_profile`	Deep profile enrichment: languages, stars, commits + PRs, OSS contributions, license breakdown, profile README, and activity score with breakdown.
`rank_candidates`	Rank usernames against a job description. Returns sorted candidates with combined score, strengths, gaps, and reasoning.
`score_against_jd`	Score candidates against a JD with per-dimension breakdown (tech stack, experience level, OSS signal, leadership). Returns gaps and personalized interview questions.
`compare_candidates`	Side-by-side comparison of 2-5 candidates. Shows dimension winners and a recommendation. Optionally scored against a JD.
`bulk_score`	Score up to 100 GitHub usernames in one call. Returns a ranked markdown table or CSV. Supports optional JD matching.
`generate_outreach`	Generate personalized recruiter messages (short/medium/detailed) that reference the candidate's actual repos and contributions. Requires your company name and sender name. Casual or formal tone.
`get_repo_contributors`	Top contributors for any repo. Accepts `owner/repo` or full URL. The fastest way to source for a specific domain.

Scoring

The activity score combines two layers: behavioral signals (what you did recently) and a reputation floor (what you've built over time).

Behavioral Score (0-205)

Signal	Max Points	How
Commits + PRs (last 90 days)	60	Push commits + PR opens (PRs weighted x3). Captures both push-based and PR-based workflows.
Stars on repos	40	Personal repo stars + stars on repos you contribute to. Org repo maintainers get credit.
Profile README	20	Presence of a profile README (github.com/username/username).
Followers	20	Capped at 20.
Repos with descriptions	20	Ratio of repos that have descriptions. Signal of care and polish.
Permissive license repos	15	Has at least one repo with MIT, Apache-2.0, BSD, ISC, or Unlicense.
Major OSS contributions	30	PRs, pushes, or issues on repos you don't own. Capped at 3 repos (10 pts each).

Reputation Floor

The behavioral score alone penalizes developers whose work doesn't produce GitHub events — Torvalds works through mailing lists, senior maintainers merge via org bots, and many engineers work in private repos.

The reputation floor ensures cumulative impact isn't erased by a quiet quarter:

Threshold	Floor
10K+ followers or 50K+ stars	150
1K+ followers or 5K+ stars	120
500+ followers or 1K+ stars	100
100+ followers or 200+ stars	80

The final score is max(behavioral_score, reputation_floor). If the floor is applied, the breakdown includes a reputation_floor field so you know.

Score Tiers

150+ — exceptional (top OSS maintainers, well-known engineers)
120-149 — strong signal, worth reaching out
80-119 — solid developer with meaningful public work
40-79 — active but limited public signal
<40 — low signal (likely private work or junior)

Ranking

rank_candidates combines the activity score with a relevance score (0-100) based on keyword overlap between the job description and the candidate's profile (bio, languages, repo topics, README). The combined score weights relevance at 60% and activity at 40% — a high-activity developer with no overlap to the job shouldn't outrank a relevant one.

Interactive dashboard

After a search produces a shortlist, the server asks whether you want an interactive dashboard — search, skill filters, ranking, evidence, and GitHub profile links. Answer yes and your assistant builds it with its own artifact tooling (Copilot's canvas, Claude's artifacts) from the scored candidate data.

It only ever offers; nothing is built unless you say yes, and the offer is skipped when a search produced no usable profiles. Set GITHUB_TALENT_DASHBOARD_PROMPT=0 to turn it off.

If the page opens in an inline canvas, note that those panes sandbox their content and block outbound links, so the assistant is also asked to open the saved file in your browser where the GitHub links work.

Rate Limits

GitHub REST API: 5,000 requests/hour with a token, 60 without one. A single enriched profile costs 6-15 calls and a typical workflow (search + enrich 5 candidates + rank) uses ~60-100, so an unauthenticated server runs out inside one search. Profile results are cached within a session to avoid redundant calls during ranking.

Two limits are separate from that hourly budget and worth knowing:

Search endpoints (/search/commits, /search/issues) allow only 30 requests/minute even with a token. The server treats a failure there as an unknown activity count rather than a failed profile, so a shortlist still comes back — the commit counts may just read 0.
Secondary rate limits fire on bursts of concurrent requests and return an explicit Retry-After. The server waits exactly that long, up to 30 seconds, then gives up rather than retrying into a window that has not lifted.

Limitations & responsible use

This tool scores public GitHub activity as one signal for technical sourcing. Know its limits before you rely on it:

Results vary between runs. It's AI-driven — the assistant decides which repos and searches to explore, so the same prompt can surface a different shortlist each time. The scoring itself is deterministic for a given set of candidates; the variation comes from sourcing. For repeatable runs, constrain the sourcing: name the repos to pull contributors from, or hand it an explicit list of usernames to rank.
GitHub is not the whole engineer. Public activity is strong evidence of technical work but blind to private-repo and internal/enterprise contributions, and to non-GitHub ecosystems (mailing lists, GitLab, etc.). It cannot verify people-management or leadership history — confirm those off-GitHub. (The reputation floor exists precisely because low recent activity ≠ low capability.)
Use it as a lead generator, not a filter. Public OSS visibility correlates with free time, tenure, and circumstance — not just skill — and that skews across demographics. Treat scores as a starting point for outreach and human judgment. Don't use them to automatically exclude candidates, and always pair them with equitable, role-relevant evaluation.
Data is live and rate-limited. Scores reflect GitHub at query time and shift as activity changes; an unauthenticated server is capped at 60 requests/hour.

License

Available Tools

8 tools

bulk_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	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	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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

nü people Job Server A
io.github.nu-people
Public MCP server for discovering open jobs. Search, filter, and get application links.
Search
52
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
Arlet
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361

Related MCP Servers

GitHub MCP Serverofficial
Version Control Developer Tools File Systems
modelcontextprotocol
-
license
Not graded
quality
A
maintenance
MCP Server for the GitHub API, enabling file operations, repository management, search functionality, and more.
Updated 16 hours ago (2026-09-03 01:42 UTC)
117,296
90,042
MIT
mcp-github-server
Version Control Developer Tools
Mervecaliskann
F
license
Not graded
quality
D
maintenance
A 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.
Updated 3 months ago (2026-06-13 17:16 UTC)
LibrAIum
Version Control Developer Tools Search
nel-neru
A
license
Not graded
quality
B
maintenance
MCP server for searching, retrieving details, suggesting, and adding curated GitHub repositories from a personal library.
Updated 7 days ago (2026-08-27 20:45 UTC)
MIT
mcp-github
nhevers
F
license
Not graded
quality
D
maintenance
MCP server for GitHub operations, providing tools for repository management, issues, pull requests, and code search.
Updated 7 months ago (2026-01-26 16:47 UTC)

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

github-talent-mcp

Brand

Demo

Profile deep dive

Repo contributor ranking

Installation

1. Install uv

2. Create a GitHub personal access token

3. Connect it

GitHub Copilot (CLI and desktop app)

Claude Code

Claude Desktop

Cursor IDE and Cloud Agents (Grok Bot)

Grok Build

Checking it actually works

Running from source

Try It

Interview-first sourcing

Tools

Scoring

Behavioral Score (0-205)

Reputation Floor

Score Tiers

Ranking

Interactive dashboard

Rate Limits

Limitations & responsible use

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API

1. Install `uv`