F
licenseNot graded
qualityC
maintenanceGenerate tailored job descriptions, hire senior developers and pull technical interview questions without leaving the conversation.
2
-
DevMatch
Server Details
DevMatch — evidence-based engineer hiring for mission-driven teams.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
3 toolsfind_candidatesARead-onlyIdempotentInspect
Find engineers who uniquely fit a role or project from open-source contributions and other public work, with evidence.
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 produces a tighter mission fit. Optional location narrows to a city, country, or ISO country code.
Returns up to limit candidates (default 20, max 20) 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 / top_domains / top_languages / top_subtopics are optional until software-topic backfill).
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.
Defense (SBIR), NRC filings, and mining QP consents are matched by lexical FTS over award titles, accessions, and consent letters — not abstract similarity. Publication, NTRS, repo, and TechPort roles still use description vectors. Do not claim a semantic abstract match for an NRC accession or a QP consent.
ParametersJSON Schema
| 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 20. | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| view | No | Payload discriminator for MCP App hosts |
| degraded | No | True when this shortlist is not full quality: FTS-only retrieval, last-known-good (cache_source=stale), or discovery corpus fallback. Hosts should say so; do not invent extra candidates. |
| query_ms | No | End-to-end query time in milliseconds |
| candidates | Yes | Shortlist of engineers who uniquely fit the role, with evidence. When presenting to the user, format each item using FindCandidatesPresentationTemplate from server instructions — list every contact.urls entry and every email verbatim. Do not present them as a numbered ranking. |
| total_count | Yes | Count of candidates returned (≤ requested limit) |
| cache_source | No | hit=fresh cache; miss=live retrieval; stale=last known-good shortlist after the engine timed out or was unavailable (degraded=true). |
| degrade_reason | No | Why degraded is true: embedding/FTS fallback, upstream_timeout / upstream_unreachable with cache_source=stale, or discovery_fallback. |
| precision_gate | No | Whether the LLM precision screen ran on this response. "on" means results were filtered for relevance; "off" means raw retrieval order. When the screen was requested but unavailable, the tool returns an error (HTTP 503, reason=precision_gate_unavailable) instead of un-gated results. |
| discovery_source | No | Which software repository index supplied 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. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses real behavioral traits: bots/CI/service accounts are auto-filtered, limit defaults to 20 and maxes at 20, results arrive as inline profiles in structuredContent, and matching for certain document types uses lexical FTS rather than semantic vectors. This substantially exceeds what annotations alone provide.
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 long but densely informative, with a clear front-loaded purpose followed by structured, non-redundant sections for inputs, outputs, filtering, agent/human behavior, and matching caveats. Every section earns its place given the tool's complexity.
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?
For a complex search tool with 4 parameters and an output schema, the description covers input modes, result shape, limits, exclusions, location behavior, mode-specific consumption, and caveats about lexical vs. semantic matching. Nothing essential for correct invocation or interpretation is missing.
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?
Although schema coverage is 100%, the description adds meaningful semantics: richer input produces tighter fit, location is hard-filtered and shrinks the candidate pool, and exclude matches both login and repo owner/org, with a concrete example. This goes well beyond the raw property descriptions.
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 opens with a specific verb-resource pairing: 'Find engineers who uniquely fit a role or project from open-source contributions and other public work, with evidence.' It clearly distinguishes the tool from the sibling get_profile by explicitly instructing agents not to call get_profile for handles already in results unless deeper detail is requested.
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?
The description gives explicit when-to-use guidance, including accepted input forms (full JD, repo-derived brief, public repo URL, informal brief), preference ordering ('preferred over a bare URL'), and handling of private repos. It also names the alternative interaction pattern by instructing not to call get_profile for returned handles, which helps route agent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_projectsARead-onlyIdempotentInspect
Find open-source projects similar to a seed GitHub repo, closest in description, topics, and README. Each result includes top contributors as leads — not a hiring shortlist. 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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| seed | No | The owner/name searched against |
| projects | Yes | Similar projects, closest to the seed repo by vector similarity. |
| query_ms | No | |
| total_count | No | |
| cache_source | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds meaningful behavioral context: results include top contributors as non-shortlist leads, and agents should consume structuredContent only. This clarifies output semantics and usage expectations without contradicting the read-only/idempotent annotations.
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?
Three sentences deliver purpose, output behavior, and usage guidance with no filler. The most important information is front-loaded, and each sentence earns its place.
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?
With an output schema present and complete annotations, the description covers what the tool does, how results should be interpreted, and how it relates to sibling tools. Nothing essential for correct invocation is missing.
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?
Schema description coverage is 100%, so the schema fully documents repo and limit. The description reinforces that repo is a seed repo and notes comparison criteria, but it does not need to compensate for missing schema details.
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 uses a specific verb and resource: 'Find open-source projects similar to a seed GitHub repo, closest in description, topics, and README.' It clearly differentiates the tool from find_candidates by stating that results are leads, not a hiring shortlist.
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?
It explicitly states when to use the tool ('for landscape mapping or to discover anchor repos') and when to follow with an alternative ('follow with find_candidates for hiring matches'). This gives an agent unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileARead-onlyIdempotentInspect
Fetch 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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| 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. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and open-world hints, so the safety profile is established. The description adds crucial interpretation context: recent_activities is limited to the 2025–2026 ingestion window, ~20 events per project, not a full career history, and empty/older activity does not imply inactivity. This directly prevents misreading returned data.
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?
Three purposeful paragraphs, front-loaded with the core function and identifier options. The usage contrast with find_candidates, the structuredContent consumption note, and the recent_activities interpretation warning all earn their place. No filler or repetition.
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 the tool's purpose, accepted identifier forms, when to use it versus find_candidates, how to consume output, and a subtle data-interpretation pitfall. With an output schema and rich annotations present, nothing an agent needs to call it correctly is missing.
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 coverage is 100%, so the baseline is 3. The description reinforces the three accepted input forms (GitHub login, ORCID iD/URL, find_candidates id) and adds the rule 'Do not invent a GitHub handle for research or deep-tech people — pass their id,' which adds meaningful selection guidance beyond the schema descriptions.
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?
States a specific verb ('Fetch') and resource ('one contributor's profile card'), enumerates accepted identifier forms, and explicitly contrasts with find_candidates. An agent can tell it apart from siblings immediately without opening the schema.
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 says when to use this tool: for ids outside find_candidates results or when the user asks for deeper detail. It also warns against inventing GitHub handles for research or deep-tech people, giving a clear exclusion rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
- First observed
find_candidates - First observed
find_similar_projects - First observed
get_profile
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
AI screening interviews, resume matching, and evidence-linked scorecards for recruiting teams.
Hiring developers? Find and source software engineers by what they build on GitHub.
- mcpOAuthcom.linatora
AI-powered hiring for recruiters & candidates - video interviews, transcripts, scores, profiles.
Job platform for AI agents. Track tech jobs from companies that match your stack.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides engineering leadership benchmarks, developer value calculation, and mentoring playbooks based on real 1:1 sessions with 300+ engineering leaders.1MIT
- AlicenseAqualityAmaintenanceLive tech-hiring intelligence for AI agents. Search 130K+ open jobs collected daily from ~500 tech companies' own career sites â plus company hiring profiles, tech stacks, salary benchmarks, and skill trends. Five tools work with no account.31168MIT
QueryQuarryofficial
AlicenseNot gradedqualityBmaintenanceConsent-based, double-blind talent marketplace. Recruiters' AI assistants search an anonymous corpus of opted-in candidates in natural language, evaluate match cards, and request contact — identity is revealed only when the candidate chooses to respond. Hosted remote server (streamable HTTP + OAuth) at queryquarry.com/api/mcp.MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.7/5.0
Disambiguation5/5
Each tool has a distinct role: find_candidates searches for people, find_similar_projects maps repos, and get_profile retrieves a single known profile. The only potential overlap (find_candidates already returns profiles) is explicitly resolved with guidance not to call get_profile unless deeper detail is needed.
Naming Consistency5/5
All tool names follow a consistent find_/get_ verb-noun pattern. The naming clearly communicates the action (search vs retrieve) and the object (candidates, similar_projects, profile).
Tool Count5/5
Three tools is a tight, focused set for this server's purpose: candidate discovery, project landscape mapping, and individual profile lookup. Each tool is independently useful and there are no redundant or filler tools.
Completeness4/5
The core workflow is covered: find candidates, discover similar projects, and fetch deeper profile details. A minor gap is the lack of direct project-detail retrieval or broader project search, but agents can work around this via find_similar_projects and get_profile.