AI recruiting for mission-aligned engineers — verified across GitHub, X, YouTube, Medium, and more
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 3 of 3 tools scored.
Each tool targets a distinct step: candidate ranking, similar-project discovery, and profile retrieval. The descriptions explicitly warn against overlapping usage, such as not calling get_profile for candidates already returned by find_candidates.
All tools follow a consistent verb_resource pattern in snake_case: find_candidates, find_similar_projects, and get_profile. This creates a predictable mental model for agents.
Three tools is a lean but well-scoped set for the server's recruiting/discovery purpose. Each tool earns its place and the count feels intentional rather than incomplete or padded.
The core workflow of discover similar projects, find candidates, and fetch deeper profile details is well covered. Minor gaps exist around broader sourcing actions like organization-level search or direct contact management, but the stated discovery purpose is functional.
find_candidatesARank engineers for a role or project by their verified open-source contributions and other public work.
Input: pass the richest context you have — (1) a full job description (most common), (2) a synthesized brief after reviewing a company's public repo (README + stack + role needs — preferred over a bare URL when you've evaluated the project), (3) a public github.com repo URL (server fetches README/topics; private repos → paste README as text), or (4) an informal role brief. Longer, more specific input ranks better. Optional location narrows to a city, country, or ISO country code.
Returns up to limit ranked candidates (default 20, max 50) with full inline profiles in structuredContent (view=candidates): login, name, bio, location, followers, reach (cross-platform audience percentile + reach), html_url, top_repos, signals, matched_projects, location_match, and contact (top_topics is optional and usually absent).
Results never include bots, CI, or service accounts — they are filtered out automatically. Use the optional exclude array (GitHub logins or org names) to drop additional accounts.
AGENT MODE: consume structuredContent only. HUMAN MODE: MCP App panel shows candidate cards; use server instructions for text-only hosts.
Do not call get_profile for handles already in these results unless the user asks for deeper detail.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Search brief: full JD, repo-derived summary (preferred when you've reviewed the project), README excerpt, informal role brief, or a PUBLIC github.com repo URL. Private repos: paste README content as text. | |
| limit | No | Max candidates to return. Default 20, max 50. | |
| exclude | No | Optional. GitHub logins or org names to exclude from results (case-insensitive). Matches a candidate's login AND the owner/org of every repo they matched on — so passing a company's GitHub org (e.g. "livekit", which also covers "livekit-cloud") keeps that company's own engineers out of a shortlist you're building FOR them. Also use it to suppress specific handles you've already contacted. Bots and CI/service accounts are excluded automatically and need not be listed. | |
| location | No | Optional. Restrict results to a place — a city ("Bozeman"), US state ("MT" / "Montana"), country name ("Germany"), or ISO country code ("US"). Matched against the candidate's stated and normalized location. Only pass it when the user explicitly requires a location; results are then hard-filtered to matches. Note many profiles omit location, so a strict location search returns a smaller pool. For laser/photonics roles, combine location with a domain-specific job description so the photonics specialist corpus can contribute too. |
| Name | Required | Description |
|---|---|---|
| view | No | Payload discriminator for MCP App hosts |
| query_ms | No | End-to-end query time in milliseconds |
| candidates | Yes | Ranked engineer candidates, strongest fit first. When presenting to the user, format each item using FindCandidatesPresentationTemplate from server instructions — list every contact.urls entry and every email verbatim. |
| total_count | Yes | Count of candidates returned (≤ requested limit) |
| cache_source | No | |
| precision_gate | No | Whether the LLM precision screen ran. "on" means results were filtered for relevance; "off" means raw retrieval order; "failed_open" means the screen was requested but unavailable, so results are un-gated — treat those with the same caution as "off". |
| discovery_source | No | Which software repository index ranked GitHub candidates: work_artifacts (artifact-first) or serving.projects (legacy). Omitted when the query did not use the GitHub software lane. |
| discovery_fallback | No | True when auto mode fell back from work_artifacts to serving.projects because searchable embedding coverage was below threshold. Explicit env overrides are not fallbacks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful runtime behavior context: automatic bot/CI/service-account filtering, the hard-filter semantics of location search that may shrink the pool, the default-20/max-50 limit, and the AGENT vs HUMAN consumption modes. Only minor deduction for slight overlap with the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose in the first sentence, then flows input → output → filtering → mode guidance → sibling routing. At roughly 200 words, there is some redundancy with the already-rich schema (input formats, location values, exclude semantics are restated), but each paragraph carries a distinct load, so it's effective density rather than bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 params (1 required), an output schema, and sibling relationships, the description covers the full decision space: which input forms to use and how specificity affects ranking, output shape and field list, exclusions, location behavior, mode-specific consumption, and when not to trigger a sibling. I cannot identify any fact needed for a correct invocation that is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema: the ranking-quality heuristic 'longer, more specific input ranks better', the practical use case for exclude suppressing 'handles you've already contacted', and the concrete livekit org example that clarifies prefix matching semantics. Much of the rest restates the schema's own param descriptions, but the additions justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource: 'Rank engineers for a role or project by their verified open-source contributions and other public work.' This is clearly distinct from both siblings — find_similar_projects returns projects, not people — and the explicit note to not call get_profile on returned handles reinforces the purpose boundary. An agent can tell apart this tool from the listed alternatives without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description spells out when to use it — full JD, repo-derived brief, GitHub URL, or informal brief — and doesn't rule out when-not-to: the 'preferred over a bare URL when you've evaluated the project' ordering, 'Only pass it when the user explicitly requires a location', and the direct routing instruction 'Do not call get_profile for handles already in these results unless the user asks for deeper detail.' This is explicit and not left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_projectsAFind open-source projects similar to a seed GitHub repo, ranked by semantic similarity to its description/topics/README. Each result includes top contributors as leads — not JD-ranked candidates. Returns structuredContent (view=similar_projects). Agents: consume structuredContent only.
Use for landscape mapping or to discover anchor repos; follow with find_candidates for hiring matches.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Seed repo in `owner/name` form (e.g. 'karpathy/llm.c'). A full github.com URL is also accepted; the server strips the prefix. | |
| limit | No | Number of similar projects to return. Defaults to 10, max 25. |
| Name | Required | Description |
|---|---|---|
| seed | No | The owner/name searched against |
| projects | Yes | Similar projects, ranked by vector similarity to the seed repo. |
| query_ms | No | |
| total_count | No | |
| cache_source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that results include top contributors as leads (not JD-ranked candidates), which is behavioral context beyond annotations. It also mentions the output is structuredContent for consumption. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 purpose sentences and a brief usage line. No unnecessary words. Front-loaded with main action and result format. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, rich annotations, and an output schema (mentioned but not shown), the description covers all necessary aspects: purpose, usage guidelines, result content, and instruction for consumption. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; it only restates the 'owner/name' form from the schema. No additional semantic clarification needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds open-source projects similar to a seed GitHub repo, ranked by semantic similarity. It specifies the input (seed repo), the ranking method (description/topics/README), and what results include (top contributors as leads). It distinguishes from sibling tools like find_candidates, which is for hiring matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: landscape mapping or discovering anchor repos. Provides a clear alternative: 'follow with find_candidates for hiring matches'. Also instructs agents to consume structuredContent only, which guides proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileAFetch one contributor's profile card by GitHub login, ORCID iD (or orcid.org URL), or a find_candidates id (source:name such as ntrs:Ada Lovelace). Do not invent a GitHub handle for research or deep-tech people — pass their id. find_candidates already returns full inline profiles; use get_profile only for ids outside those results or when the user asks for deeper detail.
Returns structuredContent (view=profile). Agents: consume structuredContent only.
IMPORTANT — interpreting recent_activities: indexed GitHub activity in the current ingestion window (2025–2026), up to ~20 events per recent project. NOT a complete career history. Empty or older activity does not mean inactive.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Alias for handle. Pass a find_candidates `id` (GitHub login, ORCID iD, or source:name). | |
| handle | Yes | Person to look up: a GitHub login (no '@'), an ORCID iD or https://orcid.org/<id> URL, or a find_candidates id (source:name such as ntrs:Ada Lovelace). Do not invent a GitHub handle for research or deep-tech people. |
| Name | Required | Description |
|---|---|---|
| bio | No | |
| name | No | |
| No | ||
| company | No | |
| html_url | No | Profile URL (GitHub or https://orcid.org/<id>) |
| location | No | |
| followers | No | |
| person_id | No | Stable lookup key: GitHub login, ORCID iD, or source:name. |
| avatar_url | No | |
| login_name | Yes | GitHub handle. Empty for ORCID and source:name people — use person_id. |
| display_name | No | |
| public_repos | No | |
| top_projects | No | Highest-contribution projects this user worked on |
| profile_readme | No | User's profile README content if present |
| social_accounts | No | Social URLs (twitter, linkedin, etc.) |
| recent_activities | No | Indexed GitHub events from current ingestion window (2025–2026). NOT a full career timeline. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, but the description adds critical context beyond that: recent_activities is scoped to a small ingestion window, is not a complete career history, and empty activity does not imply inactivity. It also instructs the agent to consume only structuredContent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then gives a clear usage rule, then adds an important behavioral caveat in a separate block. It is economical but complete, with every sentence carrying decision-relevant information for an agent selecting or invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input/output schema, the description covers the full calling context: accepted identifier forms, the required fallback behavior with find_candidates, how to read structuredContent, and the critical interpretation screen for the recent_activities field. No important behavioral context is missing for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with defaults explaining accepted formats, alias semantics, and the 'do not invent a GitHub handle' rule. The description reinforces these semantics but does not meaningfully add to what the schema already carries, so it stays at the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Fetch one contributor's profile card by GitHub login, ORCID iD, or a find_candidates id.' It explicitly contrasts itself with find_candidates, so an agent can distinguish it from the sibling tool without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to use this tool: 'use get_profile only for ids outside those results or when the user asks for deeper detail.' It also tells the agent not to invent GitHub handles and to pass find_candidates ids, giving concrete selection criteria versus find_candidates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
