The open-source talent graph for humans and AI agents. Find developers.
Scored across 8 tools
Each tool has a clearly distinct purpose: search, find similar, match to repo, get profile, get trending, preview mission, request intro, and check intro status. No significant overlap or confusion.
All tool names follow a consistent lowercase snake_case verb-first pattern (get_, find_, match_, preview_, request_, search_). The naming convention is uniform and predictable.
The 8 tools form a well-scoped set for a developer discovery and introduction workflow—neither too sparse nor overly redundant.
The tool surface covers the full lifecycle: discovery (search, trending, similar, match), profile retrieval, introduction preview/request, and status checking. No obvious missing operations for the stated domain.
Use when the user wants alternatives similar to a known GitHub login. Similarity uses public repository, language, location, and profile signals and is not a suitability judgment. Example: {"login":"sajeetharan","limit":5}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum similar profiles from 1 to 20 | |
| login | Yes | GitHub login of the source profile |
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| results | Yes | |
| resultCount | Yes | |
| methodologyDisclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context by specifying that similarity is based on public repository, language, location, and profile signals, and importantly clarifies that this is not a suitability judgment. This goes beyond what 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the use case, and every sentence adds value. The example is short and directly demonstrates a realistic call. There is no filler or repetition.
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 simple two-parameter, read-only, idempotent tool with a full input schema and an output schema, the description provides all necessary context: when to use it, what similarity means, and a caveat about suitability. Nothing essential 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 description coverage is 100%, so the schema already fully documents both login and limit. The inline example reinforces usage but does not add significant meaning beyond the schema definitions. Baseline 3 is appropriate.
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 states a specific verb and resource: it finds alternatives similar to a known GitHub login. It clearly differentiates from sibling tools like search_developers or match_developers_to_repository by focusing on similarity to an existing profile, not general search or repository matching.
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 explicitly says "Use when the user wants alternatives similar to a known GitHub login," providing clear context for when to invoke the tool. It does not explicitly list exclusions or alternative tool names, so it stops short of a full when-not/alternatives guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user names a GitHub login or selects one DevGlobe search result and needs its public profile and contribution evidence. No authentication is required. Example: {"login":"sajeetharan"}.
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | GitHub login |
| Name | Required | Description |
|---|---|---|
| profile | Yes | |
| methodologyDisclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds concrete output details (public profile and contribution evidence), enhancing transparency without contradicting the annotations.
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 succinct and front-loaded, stating the trigger condition immediately. It avoids fluff and conveys all necessary information in two sentences.
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 simple lookup tool, the description covers the key aspects: when to use, what it returns, and the required parameter. No output schema is provided, but the description's mention of 'public profile and contribution evidence' sufficiently sets expectations.
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?
The parameter 'login' is described as 'GitHub login' in both the schema and the description. The example value 'sajeetharan' provides practical context, going slightly beyond the schema coverage alone.
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's purpose: retrieving a public GitHub profile and contribution evidence for a given login. It distinguishes itself from sibling tools like search_developers and find_similar_developers by focusing on a single, specific profile lookup.
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 explicitly specifies when to use the tool: when the user names a GitHub login or selects a DevGlobe search result. It also notes that no authentication is required, which is helpful for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after request_introduction to check a request created by the same authenticated agent. An accepted request returns only the public GitHub contact route.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| developerLogin | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context: it only works for the authenticated agent's own requests, and an accepted request returns only the public GitHub contact route. This goes beyond the annotations without contradicting them.
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?
Two concise sentences, each earning its place: the first gives the triggering workflow and scope, the second clarifies the key return behavior. The most important information is front-loaded and there is no filler or redundant restating of the tool name.
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?
The description provides the essential workflow and one important output detail, and annotations cover side-effect safety. However, there is no output schema and the description does not cover non-accepted statuses, pending/rejected behavior, or where the id comes from. For a status-checking tool, this leaves meaningful ambiguity about the full range of possible responses.
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 0%, so the description carries the full burden for explaining parameters, but neither 'id' nor 'developerLogin' is described. Parameter names provide some hint, but 'id' is generic and it is not stated that this is the introduction request ID returned by request_introduction. The description fails to compensate for the missing schema-level documentation.
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?
States a specific verb ('check') and resource ('introduction request'), and ties it to the sibling 'request_introduction' workflow. The description clearly indicates this tool is for checking status rather than creating or searching, which distinguishes it from all siblings.
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 says 'Use after request_introduction', giving a clear when-to-use trigger. It also scopes usage to requests created by the same authenticated agent, which is an important eligibility condition. It does not explicitly name alternatives, but the sibling list and workflow context make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when recency or momentum matters. Lists public score gainers and high-ranking profiles new to impact tracking; do not use as a hiring recommendation. Example: {"days":30,"limit":10}.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Trend window from 1 to 90 days | |
| limit | No | Maximum gainers and new entries from 1 to 20 each |
| Name | Required | Description |
|---|---|---|
| gainers | Yes | |
| hasHistory | Yes | |
| newEntries | Yes | |
| windowDays | Yes | |
| generatedAt | No | |
| resultCount | Yes | |
| methodologyDisclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds useful context: it clarifies the data is public, scoped to score gainers and new profiles, and explicitly warns against misuse for hiring decisions. No contradiction with the annotations is present.
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 compact: two sentences plus a JSON example. The key usage condition is front-loaded, the scope is stated, and the example earns its place by showing the expected parameter shape. No filler exists.
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 read-only, two-parameter tool with full schema coverage and an output schema, the description covers the necessary behavioral and usage context. It tells the agent when to use it, what it returns conceptually, and what it should not be used for. Nothing essential 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?
The schema provides full descriptions for both parameters, so the description does not need to cover them in detail. It adds a concrete example object {'days':30,'limit':10} that demonstrates how the parameters combine, which is genuinely helpful for invocation. This exceeds the baseline but remains complementary rather than comprehensive.
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 identifies the resource (public score gainers and high-ranking profiles new to impact tracking) and the specific verb (lists). It also highlights the recency/momentum angle, which distinguishes it from generic search or profile tools. It does not explicitly name a sibling alternative, so it stops short of a full 5.
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 opens with an explicit usage condition ('Use when recency or momentum matters') and includes an important exclusion ('do not use as a hiring recommendation'). It does not mention alternative sibling tools, which would have elevated it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user starts with a public GitHub repository and wants relevant indexed developers. Matches public owner, contribution, language, topic, repository, and self-declared opportunity signals; this is not a suitability judgment. Example: {"repository":"owner/repo","limit":10}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches from 1 to 20 | |
| repository | Yes | Public GitHub repository as owner/repository or a github.com URL |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| repository | Yes | |
| resultCount | Yes | |
| methodologyDisclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful nuance by listing the matching signals (owner, contribution, language, topic, repository, self-declared opportunities) and explicitly stating this is not a suitability judgment.
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 and well-structured: a clear use statement, a compact explanation of matching signals, a caveat about suitability, and a short example. No unnecessary words or redundant details.
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 that an output schema is present and the annotations cover safety guarantees, the description provides sufficient context for an agent to decide when and how to invoke the tool. It covers the trigger, input format, matching logic, and a key limitation.
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?
The schema descriptions cover both parameters with 100% coverage. The description reinforces this with an example showing the expected repository format and a default limit, making parameter usage slightly clearer without contradicting the schema.
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 states a specific action ('matches relevant indexed developers') and a concrete trigger ('user starts with a public GitHub repository'). It clearly distinguishes itself from a suitability judgment and includes an example, making the tool's scope easy to identify.
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 explicitly says when to use the tool: when the user starts with a public GitHub repository and wants relevant developers. It does not explicitly mention when not to use it or contrast it with sibling tools like find_similar_developers, but the trigger is clear enough for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants one concrete open-source contribution opportunity for an indexed GitHub login. Read-only, rate limited, and does not reserve the issue. Example: {"login":"sajeetharan"}.
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | Public GitHub login already indexed by DevGlobe |
| Name | Required | Description |
|---|---|---|
| mission | Yes | |
| profile | Yes | |
| resultCount | Yes | |
| reservationDisclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: it is 'rate limited' and 'does not reserve the issue', clarifying side effects not visible in the schema or annotations.
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 two sentences: usage context in the first, behavioral caveats and a concrete example in the second. Every sentence earns its place, and the front-loaded 'Use when' clause is immediately actionable.
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 one clearly documented parameter, strong annotations, and an output schema, the description covers the essential extras: rate limiting, non-reservation, and the indexed-login prerequisite. Nothing critical is missing for an agent to call it 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 description coverage is 100%, and the single parameter login is already described as a 'Public GitHub login already indexed by DevGlobe'. The description reinforces this with an example JSON payload, which is convenient but does not add substantial semantic meaning beyond the schema.
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 returns 'one concrete open-source contribution opportunity' for a GitHub login, which conveys the resource and expected output. It is distinguishable from sibling tools like search_developers or match_developers_to_repository by focusing on a single previewed contribution opportunity, though it does not explicitly name a differentiating verb.
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 opens with 'Use when the user wants one concrete open-source contribution opportunity', making the intended context explicit. It does not mention alternatives or exclusions, but the context is clear enough for an agent to know when this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only after the user explicitly asks to contact an opted-in developer. Requires a bearer token, creates a consent-gated pending request, and never returns private contact details. Example: {"developerLogin":"octocat","reason":"We would like help maintaining our open-source React library.","project":"Example UI"}.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Specific collaboration reason of at least 20 characters | |
| project | Yes | Project or organization name | |
| developerLogin | Yes | GitHub login selected by the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior beyond annotations: it requires a bearer token, creates a consent-gated pending request, and never returns private contact details. This adds meaningful context about auth, side effects, and privacy that is not present in the annotations.
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 one dense, front-loaded sentence followed by a useful example. Every part earns its place and there is no redundant verbiage.
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?
The description covers behavior, auth, and privacy well, and all parameters are documented. However, with no output schema, it does not clarify what the tool returns (e.g., a request ID or status), leaving a minor gap for an agent that needs to interpret the response.
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 parameter descriptions already carry most meaning. The description adds a full JSON example with realistic values, which helps clarify expected shape and usage without repeating the schema.
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 states a specific action—creating a consent-gated pending request to contact an opted-in developer—and clearly identifies the resource and intent. This distinguishes it from read-only sibling tools like get_introduction_status or search_developers.
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?
It gives an explicit condition: 'Use only after the user explicitly asks to contact an opted-in developer.' This is strong when-to-use guidance, though it does not enumerate alternatives or explicitly say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to find public developers by skill, name, language, location, agent availability, or active opportunity intent. Start discovery here; no authentication is required. Example: {"query":"TypeScript maintainers","location":"Germany","availableForAgents":true,"limit":5}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results from 1 to 20 | |
| query | Yes | Required natural-language public search intent, such as "TypeScript maintainers" or a developer name | |
| language | No | Optional primary programming language, such as "TypeScript" | |
| location | No | Optional public location text, such as "Germany" or "Colombo" | |
| opportunityType | No | Optional active self-declared opportunity type; do not infer availability | |
| availableForAgents | No | Set true only when the user needs profiles accepting verified agent requests |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| resultCount | Yes | |
| methodologyDisclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnly, idempotent, openWorld). It adds behavioral details such as 'no authentication required' and warns 'do not infer availability' for opportunityType. No side effects or destructive actions are implied, and the read-only nature is transparent.
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 compact and efficient, combining purpose, usage trigger, authentication note, and an example in just a few sentences. There is no redundant or extraneous content, and the example is well-placed to illustrate the tool's use.
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 tool's simplicity and the presence of a full input schema, the description provides all necessary context: what it does, when to use it, and a concrete example. The output schema is indicated as existing but not required to be explained in the description, and the tool's role within the sibling set is clarified by 'Start discovery here.'
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?
All six parameters are fully described in the schema, and the example in the description demonstrates how to use them (e.g., query, location, availableForAgents). The description also clarifies conditional usage like 'Set true only when the user needs profiles accepting verified agent requests,' which adds semantic value beyond the raw schema.
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's purpose: 'find public developers by skill, name, language, location, agent availability, or active opportunity intent.' It uses a specific verb ('find') and resource ('developers'), and the phrase 'Start discovery here' indicates its role as a primary search tool, distinguishing it from sibling tools like find_similar_developers or get_developer_profile.
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 explicitly says 'Use when the user wants to find public developers...' and provides a concrete example. It also notes 'Start discovery here' and 'no authentication is required,' which are clear usage guidelines. This leaves no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_developer_profile1 field changedOutput schema / properties / profile / properties / matchAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ },
+ "label": {
+ "enum": [
+ "Strong match",
+ "Good match",
+ "Related match"
+ ],
+ "type": "string"
+ },
+ "method": {
+ "enum": [
+ "text",
+ "semantic",
+ "hybrid"
+ ],
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 3,
+ "type": "array"
+ },
+ "score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "enum": [
+ "text",
+ "semantic"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "score",
+ "label",
+ "reasons",
+ "signals",
+ "method",
+ "disclaimer"
+ ],
+ "type": "object"
+}match_developers_to_repository1 field changedOutput schema / properties / results / items / properties / matchAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ },
+ "label": {
+ "enum": [
+ "Strong match",
+ "Good match",
+ "Related match"
+ ],
+ "type": "string"
+ },
+ "method": {
+ "enum": [
+ "text",
+ "semantic",
+ "hybrid"
+ ],
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 3,
+ "type": "array"
+ },
+ "score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "enum": [
+ "text",
+ "semantic"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "score",
+ "label",
+ "reasons",
+ "signals",
+ "method",
+ "disclaimer"
+ ],
+ "type": "object"
+}search_developers1 field changedOutput schema / properties / results / items / properties / matchAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ },
+ "label": {
+ "enum": [
+ "Strong match",
+ "Good match",
+ "Related match"
+ ],
+ "type": "string"
+ },
+ "method": {
+ "enum": [
+ "text",
+ "semantic",
+ "hybrid"
+ ],
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 3,
+ "type": "array"
+ },
+ "score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "enum": [
+ "text",
+ "semantic"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "score",
+ "label",
+ "reasons",
+ "signals",
+ "method",
+ "disclaimer"
+ ],
+ "type": "object"
+}find_similar_developersget_developer_profileget_introduction_statusget_trending_developersmatch_developers_to_repositorypreview_contribution_missionrequest_introductionsearch_developersHiring developers? Find and source software engineers by what they build on GitHub.
Talent discovery for AI. Search and read agent-readable candidate profiles; cite by URL.
Semantic search for people, projects and AI agents by task, skills and collaboration needs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Add one secure layer between your agents and this server.
