Skip to main content
Glama

Find the people behind repos

find_people_behind_repos

Find the developers who build open-source projects: searches GitHub for repositories (most stars first) matching a query, topic or language, then lists the people who contributed most to them, ranked by how many of those repos they build and how much they contributed. Bots and AI coding agents are excluded. Pass repo ('owner/name') for the people behind one exact project, or org ('vercel') for the people behind an organization's repos (each person has public_member; false only means not shown as a member). Mining several seed repos one after another is often the best way to find strong people. location keeps people whose GitHub location is in one of the places, plus people who list no location, marked location_match: 'unknown' (unknown is never a mismatch; location_unknown: 'exclude' leaves them out). page reads the next set of repos. With role_id, people the role has already seen are left out (unless include_seen) and the search goes in the role's history. Free (GitHub only).

Input Schema

NameRequiredDescriptionDefault
orgNoA GitHub organization (or account), e.g. 'vercel': the people behind its top repos. Combine with query/language to narrow
pageNoPage of matching repos (default 1; 2 and on for the next ones)
repoNoOne exact repo, 'owner/name' or its GitHub URL: the people who build it
limitNoMax people to return (1-100, default 25)
queryNoWords matched against repo name, description and README, e.g. 'agent framework'
topicNoGitHub topic, e.g. 'llm' or 'react'
role_idNoOptional role id: this search is logged in the role's search history, everyone it returns is marked as seen for the role, and people the role has already seen are left out (unless include_seen). Nothing is added to the role: use add_people_to_role.
languageNoMain repo language, e.g. 'Python', 'TypeScript', 'Rust'
locationNoPlaces to keep: cities, countries or regions, e.g. ['Germany', 'Berlin'] or 'Europe'. A country also matches its main cities, and a region (Europe, US, North America, UK) its countries and their cities; anything else matches the words people wrote on their profile. Up to 40.
min_starsNoMinimum stars (default 1000; 0 with org)
repo_limitNoHow many repos to look at (1-20, default 10)
include_seenNoWith role_id: also return people the role has already seen (default false)
pushed_afterNoOnly repos pushed on/after this date (YYYY-MM-DD), to skip abandoned projects
created_afterNoOnly repos created on/after this date (YYYY-MM-DD), for 'went viral recently'
people_per_repoNoTop contributors to take from each repo (1-20, default 5; with repo 1-30, default 20)
location_unknownNoWith location: keep (default, marked unknown) or leave out people who list no location

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite readOnlyHint=false, the description explains the actual side effects: with role_id the search is logged in the role's history, results are marked seen, already-seen people are excluded, and 'Nothing is added to the role: use add_people_to_role.' It also discloses bot/AI-agent exclusion, the location_match:'unknown' semantics, and that the source is free/GitHub-only — context none of the annotations provide.

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 core purpose is front-loaded and every sentence carries operational information (repo/org routing, location caveat, role_id side effects). It is dense and slightly run-on in places, but there is no filler.

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 16-parameter tool with no required params and no output schema, the description plus full schema coverage covers what an agent needs: selection between repo/org/query paths, the roles of location and role_id, and the key returned fields (public_member, location_match). Nothing critical is left unexplained before invocation.

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, but the description adds real meaning beyond the schema: page paginates repos (not people), location keeps people with no location marked 'unknown' and 'unknown is never a mismatch', and role_id's seen-filtering semantics including include_seen. That lifts it above baseline.

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 and resource — search GitHub repositories, then list the people who contribute most to them, ranked — with the exact scoping knobs (repo, org). An agent can distinguish this 'repo-first then people' tool from the people-first siblings like search_people or find_people_for_role purely from the description.

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?

Gives clear selection guidance: pass repo for one exact project, org for an organization, and 'Mining several seed repos one after another is often the best way to find strong people.' It also explains role_id behavior. It does not explicitly contrast against sibling alternatives by name (e.g. search_people), so it falls short of a full when/when-not map.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources