The open-source talent graph for humans and AI agents. Find developers.
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 cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those annotations: no authentication is required and the data is public. This is meaningful for an agent deciding whether to invoke the tool.
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 front-loaded with the key usage condition. The example is brief and instructive, and no sentence is wasted.
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 single-parameter read-only tool with a full output schema and comprehensive annotations, the description supplies all necessary invocation context: when to use it, what it returns at a high level, authentication requirements, and an example. 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 fully documents the only parameter, `login`, so the baseline is 3. The description adds value beyond the schema by providing a concrete JSON example and clarifying that the login comes from a user mention or a DevGlobe search selection.
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 identifies a clear verb-resource pair: retrieving a GitHub login's public profile and contribution evidence. It also distinguishes this from search-oriented siblings by tying usage to a specific login or a selected DevGlobe search result.
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 explicitly states when to use the tool: when the user names a GitHub login or selects a search result and wants profile/contribution information. It does not explicitly list when-not-to-use conditions or alternatives, so it falls just short of a 5.
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 description goes beyond annotations by listing the signal types matched (owner, contribution, language, topic, repository, and self-declared opportunity signals) and by explicitly disclaiming suitability judgment. This adds meaningful behavioral context while remaining consistent with the readOnly, openWorld, and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the trigger scenario, followed by a compact example. Every sentence earns its place with no redundant filler.
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, combined with rich annotations and an output schema, provides everything an agent needs to select and invoke the tool correctly. It covers the input trigger, matching behavior, example payload, and an important caveat about suitability.
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 parameters. The description includes a helpful JSON example with 'repository' and 'limit', but it does not add substantive semantic detail beyond what the schema already provides.
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 uses a specific triggering scenario ('starts with a public GitHub repository') and a clear action ('wants relevant indexed developers'). It also clarifies what the tool does and does not do ('not a suitability judgment'), making it easy to distinguish from sibling tools like search_developers or get_trending_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?
The description explicitly states when to use the tool: when the user starts with a public GitHub repository and wants relevant developers. It does not explicitly name alternatives or when-not-to-use conditions, but the repository-based trigger provides clear usage context.
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?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context beyond annotations: no authentication required, searches public data only, and supports agent availability and opportunity-intent filtering. No contradiction with 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 concise: a clear trigger sentence, a workflow hint, and a compact JSON example. Every sentence earns its place, and the most important information is front-loaded.
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?
With full schema descriptions, annotations, and an output schema present, the description only needs to clarify access, scope, and entry-point positioning—all of which it does. Nothing essential for correctly invoking this search tool 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 documents all parameters clearly. The description adds a compact example and maps search dimensions to parameters, but this is illustrative rather than necessary; baseline 3 applies.
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 function: finding public developers by skill, name, language, location, agent availability, or opportunity intent. It also positions itself as the discovery entry point ('Start discovery here'), which differentiates it from siblings like get_developer_profile or get_trending_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?
The description provides an explicit trigger ('Use when the user wants to find public developers...') and useful context such as 'no authentication is required'. It does not explicitly name sibling alternatives or exclusion conditions, but 'Start discovery here' implies when in the workflow this tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on 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.
No comments yet. Be the first to start the discussion!
Hiring developers? Find and source software engineers by what they build on GitHub.
AI recruiting for mission-aligned engineers — verified across GitHub, X, YouTube, Medium, and more
Talent discovery for AI. Search and read agent-readable candidate profiles; cite by URL.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Add one secure layer between your agents and this server.
The discovery-oriented tools (search_developers, find_similar_developers, match_developers_to_repository, get_trending_developers) all return developers, but each is anchored to a distinct input—query, login, repository, or recency—so an agent can tell them apart. The remaining tools (profile, introduction status, contribution preview, request introduction) are clearly separated by action.
All tool names follow a consistent snake_case verb_noun pattern: search, find, get, match, preview, request. The noun clearly indicates the resource or action target, with no mixed casing or vague verbs.
Eight tools is a well-scoped surface for developer discovery and introduction. Each tool serves a distinct part of the workflow, and the count feels neither bloated nor thin.
The core workflow is covered: discovery, profile lookup, contribution preview, introduction request, and status check. A cancel or list introductions capability would round out the introduction lifecycle, but the essential agent journeys have no dead ends.
