Skip to main content
Glama

Revternal Search Developers

revternal_search_developers
Read-onlyIdempotent

Search a live index of ~12M developers (GitHub-centric) by role, primary programming language, location, and recent activity — for recruiting, GTM/lead-gen, and developer-audience research. Each result is a matching GitHub username, display name, and profile URL; your search filters are echoed back on the response rather than repeated per result. Filters: role (e.g. "backend engineer", "ai/ml engineer" — spaces/punctuation are normalized to underscores), primary_language (e.g. "Python", "Rust"), location, active_within_days (only devs active in the last N days), sort_by ("last_active", "commit_quality", or "external_contribution_ratio"; default last_active). Paginate with limit + offset — each requested slot costs 1 credit. Requires your own Revternal API key (BYOK) — pass it as _apiKey. Example: revternal_search_developers({ primary_language: "Rust", active_within_days: 30, limit: 20, _apiKey: "..." }).

Input Schema

NameRequiredDescriptionDefault
roleNoDeveloper role filter, e.g. "backend engineer", "ai/ml engineer", "frontend engineer".
limitNoResults per page, 1-100 (default 20). Each requested slot costs 1 credit.
offsetNoPagination offset (default 0).
_apiKeyYesYour Revternal API key (sent as x-api-key), from https://revternal.com/signup. Required — Pipeworx has no platform key for this pack.
sort_byNoSort field: "last_active" (default), "commit_quality", or "external_contribution_ratio".
locationNoLocation filter, e.g. "Berlin", "United States".
primary_languageNoPrimary programming language, e.g. "Python", "Rust", "TypeScript".
active_within_daysNoOnly developers active within the last N days (>=1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / _apiKey / description
      Previous value: -"Revternal API key (x-api-key). Injected from the platform key when omitted."New value: +"Your Revternal API key (sent as x-api-key), from https://revternal.com/signup. Required — Pipeworx has no platform key for this pack."
    • changedInput schema / properties / limit / description
      Previous value: -"Results per page, 1-100 (default 20)."New value: +"Results per page, 1-100 (default 20). Each requested slot costs 1 credit."
    • changedInput schema / properties / sort_by / description
      Previous value: -"Sort field. Default \"last_active\"."New value: +"Sort field: \"last_active\" (default), \"commit_quality\", or \"external_contribution_ratio\"."
    • changedInput schema / required
      Previous value: -[]New value: +[
      +  "_apiKey"
      +]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "active_within_days": 30,
      +    "limit": 20,
      +    "primary_language": "Rust"
      +  },
      +  {
      +    "active_within_days": 7,
      +    "limit": 50,
      +    "location": "Berlin",
      +    "offset": 0,
      +    "role": "backend engineer",
      +    "sort_by": "last_active"
      +  }
      +]
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial non-obvious behavior on top: each requested slot costs 1 credit, results echo filters rather than repeating them per row, and role values are normalized (spaces/punctuation to underscores). The BYOK requirement and _apiKey passing are also disclosed, which the annotations cannot convey.

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?

Front-loaded with purpose and scope, then filters, pagination/credits, auth, and an example — a logical progression with little filler. It is dense and somewhat long, and the sort_by options and credit note partially repeat the schema, keeping it short of 5.

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?

Despite having no output schema, the description specifies the return shape (GitHub username, display name, profile URL, echoed filters), the auth requirement, the credit model, and pagination. For an 8-parameter read tool, an agent has everything needed to call it correctly.

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 meaning the schema omits — the role normalization rule, the default for sort_by, and the credit cost tied to limit. It does not, however, explain offset/pagination edge behavior or interactions beyond what the schema states.

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?

States a specific verb+resource with real scope: 'Search a live index of ~12M developers (GitHub-centric)' and names the filter dimensions (role, language, location, activity). It implies differentiation from enrich/intel tools by being a search over an index, but never names or contrasts a sibling, so it falls short of the 5 bar.

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 concrete use contexts — recruiting, GTM/lead-gen, and developer-audience research — which tells the agent when this tool is appropriate. However, it offers no exclusions or alternatives (e.g. revternal_people_search, revternal_developer_intel, revternal_enrich_developer), leaving the agent to infer routing among similar siblings.

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.