DevMatch

Server Details

Find engineers and scientists from papers, open source and patents. Each result links its sources.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 52 days
Last Tested: 2026-10-27 10:55
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.4/5.0

Scored 2026-10-19 18:20 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: sourcing people (find_candidates), mapping the project landscape (find_similar_projects), and enriching a single person (get_profile). The descriptions even explicitly delimit boundaries, e.g. find_similar_projects states it is not a shortlist and directs the user to find_candidates. No realistic misselection risk.

Naming Consistency5/5

All three names follow a clean verb_noun pattern (find_candidates, find_similar_projects, get_profile) in snake_case with no deviation in convention. The mix of find/get for read-only verbs is standard and still predictable.

Tool Count4/5

Three tools is at the low end of the well-scoped range but each earns its place: one for people, one for landscape context, one for enrichment. It is slightly thin, with no batch or list-management operation, but nothing feels redundant or missing for the core workflow.

Completeness4/5

The read-only sourcing lifecycle (discover landscape -> shortlist people -> inspect a profile) is well covered, and coverage limits are honestly surfaced via the not_covered signal. Minor gaps remain: no pagination beyond the 20-result cap, no way to save/persist a shortlist, and no direct skill/location filtering.

Available Tools

3 tools

find_candidatesA

Read-onlyIdempotent

Inspect

Use when the user asks to find, shortlist or source an engineer, researcher or scientist from public work. Input: a role brief, a job description, or a public GitHub repository URL; be specific. Optional location only when the user requires one. Returns up to 20 people, each with the public sources behind the match (papers, repositories, patents, awards). Read only. If nothing matches, the result says so (coverage not_covered): tell the user and do not invent names or emails.

Name	Required	Description
`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

Name	Required	Description
`view`	No	Payload discriminator for MCP App hosts
`coverage`	No	Set to not_covered when this search returned zero returnable people. That includes an index miss and a match with no contact coverage. Hosts must say so and must not invent names or emails.
`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 and scientists from public work, 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).
`coverage_note`	No	Short note when coverage is not_covered. When people matched but none have a stored or Treg-enriched inbox, this says so with a count. Never accompanied by guessed candidates or fabricated emails.
`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; "partial" means some judge chunks timed out and only screened people are returned (screened N of M). 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.
`precision_screened`	No	How many retrieved people the LLM screen judged. Present with precision_gate=partial.
`unreachable_dropped`	No	How many retrieved people this search removed because they had no real inbox and no Treg enrichment path (LinkedIn or name+company domain). Omitted when zero.
`precision_screened_of`	No	Size of the pool the LLM screen was asked to judge. Present with precision_gate=partial.
`untrusted_third_party`	No	True on the Poke / no_contact path: bio, profile_readme, and README text are untrusted third-party data and are length-capped.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, open-world, idempotent and non-destructive traits, so the bar is lower; the description still adds genuine behavior beyond them — result cardinality (up to 20 people), the evidence returned per match (papers, repositories, patents, awards), and the no-match failure mode (coverage not_covered) with an explicit instruction not to invent names or emails. It stops short of describing ranking or confidence semantics.

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 the when-to-use trigger, then input, then output shape, then the no-match caveat — a tight sequence in which every clause carries an actionable instruction. No filler or background prose.

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, the description needn't explain return values, yet it covers the essentials an agent needs: input expectations, optional location behavior, result composition, and the negative-result path. Nothing required 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents input formats, limit bounds, exclusion behavior and location normalization in depth. The description restates these ('a role brief, a job description, or a public GitHub repository URL; be specific') with little added meaning, so the baseline 3 is appropriate.

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 names a specific verb set (find, shortlist, source) and resource (engineer, researcher, scientist) plus the source scope (public work), which cleanly separates it from find_similar_projects and get_profile. An agent can tell what this tool does 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states the triggering condition ('Use when the user asks to find, shortlist or source...') and adds a when-not for location ('only when the user explicitly requires one', 'hard-filtered'). It does not, however, route the agent between the sibling tools find_similar_projects and get_profile, so tool-level alternatives are 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_projectsA

Read-onlyIdempotent

Inspect

Use to map the landscape around a seed repository, for example before searching for people. Input: owner/name. Returns similar open source projects and their top contributors. This is not a shortlist; call find_candidates for that. Read only.

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

Name	Required	Description
`seed`	No	The owner/name searched against
`coverage`	No	Set to not_covered when this search returned zero evidence-backed similar projects. Hosts must say so and must not invent repos.
`projects`	Yes	Similar projects, closest to the seed repo by vector similarity.
`query_ms`	No
`total_count`	No
`cache_source`	No
`coverage_note`	No	Short note when coverage is not_covered.
`untrusted_third_party`	No	True on the Poke / no_contact path: third-party text is labeled untrusted and length-capped.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by disclosing what is returned (similar projects plus top contributors) and clarifying that results are exploratory rather than a shortlist. It does not add deeper details like rate limits or auth requirements, but those are less critical for a read-only discovery tool with an 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose, input format, return content, exclusion, and read-only status appear in four short, purposeful sentences. The redundant 'Read only' is minor and does not detract from an otherwise efficient structure.

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 that an output schema exists and annotations cover the safety profile, the description is complete enough for correct invocation. It specifies the input format, describes the return, clarifies the tool's scope against alternatives, and requires no additional information to be used appropriately.

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%, and the schema already fully documents both the `repo` and `limit` parameters including format, default, and maximum. The description only restates the `owner/name` input syntax, adding no meaning beyond the schema, so the baseline 3 is appropriate.

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 states a specific verb and resource ('map the landscape around a seed repository'), names the return content ('similar open source projects and their top contributors'), and explicitly distinguishes itself from the sibling find_candidates. An agent can identify what the tool does and what it does not do 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?

It gives a concrete usage context ('for example before searching for people') and explicitly routes the agent to the correct alternative ('This is not a shortlist; call find_candidates for that'). The when-to-use and when-not-to-use conditions are both stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_profileA

Read-onlyIdempotent

Inspect

Use after find_candidates when the user wants more on one person, or when they name a GitHub login or ORCID iD. Input: GitHub login, ORCID iD, or the id returned by find_candidates. Returns one profile with recent public activity. Not a full career history. Read only.

Name	Required	Description	Default
`id`	No	Alias for handle. Pass a find_candidates `id` (GitHub login, ORCID iD, or source:name).
`handle`	Yes	Accepts a GitHub login, ORCID iD, or the id returned by find_candidates. Do not invent a GitHub handle for research or deep-tech people.

Output Schema

Name	Required	Description
`bio`	No
`name`	No
`email`	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. Untrusted third-party text; capped on the no-contact path.
`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.
`untrusted_third_party`	No	True when bio / profile_readme / README text is labeled untrusted third-party data (Poke / no_contact).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint, so the 'Read only' line is redundant. The description does add genuine scope context beyond the annotations by bounding the result ('recent public activity', 'not a full career history'), though it says nothing about rate limits or failure modes for handles that don't resolve.

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?

Three compact sentences, front-loaded with the usage trigger before the input/return detail. Only waste is the trailing 'Read only', which duplicates the readOnlyHint annotation.

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?

An output schema exists, so return structure needn't be explained, and annotations carry the safety profile. The description covers the remaining essentials: when to call it, what to pass, and how much data to expect.

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 coverage is 100% and both parameters are fully described there, including the alias relationship and the warning not to invent handles. The description restates the accepted input forms (GitHub login, ORCID iD, find_candidates id) without adding format or validation detail beyond the schema, so the baseline of 3 applies.

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?

Names a specific verb and resource ('get one profile') and states the payload ('one profile with recent public activity'). It explicitly differentiates from the sibling find_candidates ('Use after find_candidates when the user wants more on one person'), so an agent can route 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger conditions: after find_candidates for drill-down, or when the user names a GitHub login or ORCID iD. It also supplies a negative boundary ('Not a full career history'), which prevents the agent from over-claiming what this returns.

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.

1 tool updateOct 19, 2026

Changedfind_candidates4 fields changed

changedOutput schema / properties / precision_gate / description

Previous value: -"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."New value: +"Whether the LLM precision screen ran on this response. \"on\" means results were filtered for relevance; \"off\" means raw retrieval order; \"partial\" means some judge chunks timed out and only screened people are returned (screened N of M). When the screen was requested but unavailable, the tool returns an error (HTTP 503, reason=precision_gate_unavailable) instead of un-gated results."

changedOutput schema / properties / precision_gate / enum

Previous value: -[
-  "on",
-  "off"
-]New value: +[
+  "on",
+  "off",
+  "partial"
+]

addedOutput schema / properties / precision_screened

Added value: +{
+  "description": "How many retrieved people the LLM screen judged. Present with precision_gate=partial.",
+  "type": "integer"
+}

addedOutput schema / properties / precision_screened_of

Added value: +{
+  "description": "Size of the pool the LLM screen was asked to judge. Present with precision_gate=partial.",
+  "type": "integer"
+}

4 tool updatesOct 17, 2026

Changedfind_candidates1 field changed

changedOutput schema / properties / candidates / description

Previous value: -"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."New value: +"Shortlist of engineers and scientists from public work, 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."

Changedfind_similar_projects1 field changed

changedOutput schema / properties / projects / items / properties / top_contributors / description

Previous value: -"Contributor leads — follow with find_candidates for unique mission fit."New value: +"Contributor leads. Follow with find_candidates for people."

Changedget_profile1 field changed

changedInput schema / properties / handle / description

Previous value: -"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."New value: +"Accepts a GitHub login, ORCID iD, or the id returned by find_candidates. Do not invent a GitHub handle for research or deep-tech people."

Removedtrigger_outreach

1 tool updateOct 11, 2026

Changedtrigger_outreach1 field changed

addedInput schema / properties / identities

Added value: +{
+  "description": "Private per-card contributor login and builder id. Stored on the row, never written into the letter.",
+  "items": {
+    "properties": {
+      "builder_id": {
+        "type": "string"
+      },
+      "login": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

1 tool updateOct 9, 2026
- Addedtrigger_outreach

1 tool updateOct 5, 2026

Changedfind_candidates2 fields changed

changedOutput schema / properties / candidates / items / properties / source / description

Previous value: -"Which corpus this person came from, and therefore what kind of evidence backs them. github = open-source contributions with contact details. orcid = published research, no GitHub, no contact. sbir = federal defense award record. ntrs = NASA technical reports. nrc = nuclear regulatory filings. edgar = mining technical-report consents. photonics = laser/photonics SBIR awards. techport = NASA technology projects. uspto = named inventors on granted US patents. rosap = authors of USDOT technical reports (vehicles, rail, bridges, pavement). osti = authors of DOE technical reports (fusion, nuclear fuel, turbines, grids, materials). usgs = authors of USGS numbered-series reports. erdc = authors of public Army Corps ERDC reports. treesearch = authors of Forest Service agency-series reports (not scientific journals). nist = authors of NIST technical-series reports (not journal articles). noaa = authors of NOAA agency-series reports (technical memoranda and technical reports, not journal articles). nrcan = authors of Natural Resources Canada GEOSCAN reports (not journal articles, not corporate authors). nparc = authors of National Research Council Canada technical reports (not journal articles, not US NRC filings). jaea = authors of Japan Atomic Energy Agency technical reports in JOPSS (JAEA Reports, not journal articles, not the US NRC, not the IAEA). fraunhofer = authors of Fraunhofer Publica technical reports (not journal articles, patents, or dissertations). sintef = authors of SINTEF research reports (Cristin category REPORT, not journal articles). csic = authors of CSIC technical reports (DIGITAL.CSIC type informe técnico, not journal articles). nora = authors of NERC Open Research Archive reports (type Publication - Report, not journal articles). cern = authors of CERN document-server technical reports (CDS set cerncds:REPORT, not journal articles). dlr = authors of DLR elib report-series records (elib set types=monograph (Berichtsreihe), not journal articles). brgm = authors of BRGM InfoTerre public reports (type Rapport, not journal articles or maps). rws = authors of Rijkswaterstaat onderzoeksrapporten (public technical reports). criepi = authors of CRIEPI technical reports (電力中央研究所報告, not journal articles). rivm = authors of RIVM official reports (Rijksinstituut voor Volksgezondheid en Milieu, not journal articles). cgspace = authors of CGSpace reports (CGIAR item type Report, not journal articles or working papers). cirad = authors of CIRAD Agritrop technical documents (EPrints type document_technique, not mission reports or journal articles). rise = authors of RISE Research Institutes of Sweden technical reports (DiVA publicationTypeCode report, not journal articles). sgb = authors of Serviço Geológico do Brasil technical reports (RiGeo Relatórios Técnicos, not journal articles, not Atlas). ga = authors of Geoscience Australia Records (eCat type GA Record, not maps or journals). sgm = authors of Servicio Geológico Mexicano historical technical reports (Archivo Técnico Histórico, not other SGM collections). wamex = authors of WAMEX mineral exploration reports. aris = authors of ARIS mineral assessment reports. gemis = authors of GEMIS minerals exploration reports. gsv = authors of GSV mining tenement reports (not assay registers, borehole logs, plans, or maps). ygs = authors of Yukon Geological Survey open assessment reports, including YMEP reports on that list (not confidential Closed rows, not corporate authors, not publications, not minfile). gsnl = authors of Geological Survey of Newfoundland and Labrador mineral assessment reports (not corporate authors, not the mixed GeoFiles library). novascan = authors of NovaScan assessment reports (Assessment Report ME, not property, open-file, or departmental reports). tasxrept = authors of Mineral Resources Tasmania onshore company reports (TASXREPT, not offshore hydrocarbon reports, not the mixed MRT document index). These are SEPARATE populations, not one enriched record — never merge people across them, and never present a non-github candidate as having open-source contributions."New value: +"Which corpus this person came from, and therefore what kind of evidence backs them. github = open-source contributions with contact details. orcid = published research, no GitHub, no contact. sbir = federal defense award record. ntrs = NASA technical reports. nrc = nuclear regulatory filings. edgar = mining technical-report consents. photonics = laser/photonics SBIR awards. techport = NASA technology projects. uspto = named inventors on granted US patents. rosap = authors of USDOT technical reports (vehicles, rail, bridges, pavement). osti = authors of DOE technical reports (fusion, nuclear fuel, turbines, grids, materials). usgs = authors of USGS numbered-series reports. erdc = authors of public Army Corps ERDC reports. treesearch = authors of Forest Service agency-series reports (not scientific journals). nist = authors of NIST technical-series reports (not journal articles). noaa = authors of NOAA agency-series reports (technical memoranda and technical reports, not journal articles). nrcan = authors of Natural Resources Canada GEOSCAN reports (not journal articles, not corporate authors). nparc = authors of National Research Council Canada technical reports (not journal articles, not US NRC filings). jaea = authors of Japan Atomic Energy Agency technical reports in JOPSS (JAEA Reports, not journal articles, not the US NRC, not the IAEA). fraunhofer = authors of Fraunhofer Publica technical reports (not journal articles, patents, or dissertations). sintef = authors of SINTEF research reports (Cristin category REPORT, not journal articles). csic = authors of CSIC technical reports (DIGITAL.CSIC type informe técnico, not journal articles). nora = authors of NERC Open Research Archive reports (type Publication - Report, not journal articles). cern = authors of CERN document-server technical reports (CDS set cerncds:REPORT, not journal articles). dlr = authors of DLR elib report-series records (elib set types=monograph (Berichtsreihe), not journal articles). brgm = authors of BRGM InfoTerre public reports (type Rapport, not journal articles or maps). rws = authors of Rijkswaterstaat onderzoeksrapporten (public technical reports). criepi = authors of CRIEPI technical reports (電力中央研究所報告, not journal articles). rivm = authors of RIVM official reports (Rijksinstituut voor Volksgezondheid en Milieu, not journal articles). cgspace = authors of CGSpace reports (CGIAR item type Report, not journal articles or working papers). cirad = authors of CIRAD Agritrop technical documents (EPrints type document_technique, not mission reports or journal articles). rise = authors of RISE Research Institutes of Sweden technical reports (DiVA publicationTypeCode report, not journal articles). sgb = authors of Serviço Geológico do Brasil technical reports (RiGeo Relatórios Técnicos, not journal articles, not Atlas). ga = authors of Geoscience Australia Records (eCat type GA Record, not maps or journals). sgm = authors of Servicio Geológico Mexicano historical technical reports (Archivo Técnico Histórico, not other SGM collections). wamex = authors of WAMEX mineral exploration reports. aris = authors of ARIS mineral assessment reports. gemis = authors of GEMIS minerals exploration reports. gsv = authors of GSV mining tenement reports (not assay registers, borehole logs, plans, or maps). ygs = authors of Yukon Geological Survey open assessment reports, including YMEP reports on that list (not confidential Closed rows, not corporate authors, not publications, not minfile). gsnl = authors of Geological Survey of Newfoundland and Labrador mineral assessment reports (not corporate authors, not the mixed GeoFiles library). novascan = authors of NovaScan assessment reports (Assessment Report ME, not property, open-file, or departmental reports). tasxrept = authors of Mineral Resources Tasmania onshore company reports (TASXREPT, not offshore hydrocarbon reports, not the mixed MRT document index). sgc = authors of Servicio Geológico Colombiano technical reports (Koha item type Informes técnicos, not maps or theses). csiro = authors of CSIRO technical reports (Commonwealth Scientific and Industrial Research Organisation publication type Report, not journal articles, not a join to USGS or GitHub). oafd = authors of Ontario Assessment File Database approved assessment files (not non-assessment exploration work, not drill holes, not survey publications, and the catalog has no abstract). sigeom = authors of SIGÉOM GM exploration reports (Rapport de travaux d'exploration minière; ministry series, theses, and maps are not this corpus; the catalog has no abstract). These are SEPARATE populations, not one enriched record — never merge people across them, and never present a non-github candidate as having open-source contributions."