Search GitHub repos, issues, pull requests, and user profiles for development intelligence via MCP.
Compare multiple GitHub repositories side-by-side with key metrics. Returns star counts, fork counts, issues, primary language, and comparative analysis for each repository. Use for choosing between similar projects or analyzing competitive landscape.
| Name | Required | Description | Default |
|---|---|---|---|
| repos | Yes | List of repositories to compare (minimum 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by disclosing the exact output categories (stars, forks, issues, primary language, comparative analysis), which goes beyond the annotations' minimal safety hints 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?
The description is exactly two sentences, front-loaded with the core purpose and immediately followed by output details and use case. Every word earns its place; no filler or redundancy.
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 (one array parameter, read-only, no output schema), the description fully covers what it does, what it returns, and when to use it. No missing information that would hinder correct selection or invocation.
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 input schema fully documents the 'repos' parameter, including format and minimum count (100% schema description coverage). The description merely echoes 'multiple' without adding syntax or non-obvious constraints, so the baseline score of 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 clearly states a specific verb ('Compare'), resource ('GitHub repositories'), and scope ('side-by-side with key metrics'). It explicitly lists the metrics returned and distinguishes itself from siblings like get_repo_languages and get_repo_stats by focusing on multi-repo comparison.
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 clear context for when to use the tool: 'choosing between similar projects or analyzing competitive landscape.' It does not explicitly name alternatives or when-not-to-use scenarios, but the usage context is specific and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the programming language composition of a GitHub repository. Returns percentage breakdown of languages used, dominant language, and file counts per language. Use for understanding project tech stack or evaluating language distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name (e.g. 'cpython', 'go') | |
| owner | Yes | Repository owner GitHub username or organization (e.g. 'python', 'golang') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by specifying what the tool returns (percentage breakdown, dominant language, file counts). This goes beyond just a read-only flag, giving the agent a concrete picture of the tool's output behavior.
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, front-loaded with the main action, and every clause serves a purpose. It avoids redundancy and is easy to parse.
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 tool with no output schema, the description covers purpose, usage context, and output details. It lacks explicit alternatives or exclusions, but given the tool's simplicity, it is sufficiently complete for an agent to invoke 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 coverage is 100%, with both parameters (owner, repo) fully described with examples. The description does not add parameter-specific insights beyond the schema, so the baseline score of 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 clearly states the tool analyzes the programming language composition of a GitHub repository, with a specific action ('Analyze') and resource ('language composition'). It also details the specific outputs (percentage breakdown, dominant language, file counts), distinguishing it from siblings like get_repo_stats or search_repos.
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?
Provides clear use cases: 'understanding project tech stack or evaluating language distribution.' While it doesn't explicitly mention when not to use it or name alternative tools, the context is sufficient for an agent to decide 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.
Fetch comprehensive statistics for a specific GitHub repository. Returns total stars, forks, issues (open/closed), pull requests, watchers, last commit date, and contributor count. Returns metrics useful for assessing project popularity and maintenance status.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name within the owner (e.g. 'linux', 'vscode', 'gpt-2') | |
| owner | Yes | GitHub username or organization name (e.g. 'torvalds', 'microsoft', 'openai') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds beyond this by enumerating the exact return metrics (stars, forks, issues, PRs, watchers, last commit, contributor count), giving a clear picture of what the agent can expect. It does not mention output format or pagination, but for a read-only stats tool the described scope is adequate.
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 sentences, front-loaded with verb and resource, then a concise list of return metrics and use case. Every sentence earns its place with no redundancy or fluff.
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 only two well-documented parameters, read-only annotations, and no output schema, the description compensates by listing all expected return fields. It gives a complete enough picture for the agent to invoke correctly, though it could note potential exclusions like private repo access or data freshness. Overall adequate for a tool of this complexity.
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% — both 'owner' and 'repo' are described with examples. The description adds no parameter-specific detail beyond what the schema already provides. Baseline 3 is appropriate since the schema handles parameter semantics fully.
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 verb 'fetch' and a clear resource 'comprehensive statistics for a specific GitHub repository', listing concrete metrics. It clearly distinguishes this from siblings like compare_repos (which compares repos) and search_repos (which searches), making the purpose unmistakable.
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 clear context by stating the tool is for 'a specific GitHub repository' and is 'useful for assessing project popularity and maintenance status'. This implies when it should be used, though it does not explicitly mention alternatives or when not to use it. With siblings visible, the context is sufficient but slightly indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across GitHub for repositories matching keywords, sorted by relevance or metrics. Returns matching repositories with description, star count, language, and last update timestamp. Use for finding projects, libraries, or code samples related to specific topics.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort results by most stars, most forked, or most recently updated (default: relevance) | |
| query | Yes | Search terms to find repositories (e.g. 'todo app', 'machine learning framework', 'authentication middleware') | |
| max_results | No | Number of repositories to return (default 10, max 100 for comprehensive search) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds context about the search scope and return fields. However, it does not disclose behavior such as rate limits, pagination, or how results are ordered by default beyond what the schema already specifies.
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, front-loaded with the action, and includes only essential information: purpose, sort capability, return fields, and intended use case.
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, the description covers what it does, why you'd use it, and what it returns. The schema covers parameter details, and annotations handle safety. Minor gap: no explicit mention of default sorting or result limits, but these are in the schema.
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 three parameters have schema descriptions with 100% coverage, so the description does not need to compensate. It adds no significant semantics beyond the schema, apart from general context about keywords.
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 as searching GitHub repositories by keywords, with specific output fields, and distinguishes itself from sibling tools focused on comparison or statistics by emphasizing its search-and-find purpose.
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 clear context on when to use this tool ('Use for finding projects, libraries, or code samples related to specific topics'), but does not explicitly mention alternative tools or exclusions for 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.
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!
Add one secure layer between your agents and this server.
Each tool targets a distinct task: searching, analyzing a single repo, analyzing language composition, and comparing multiple repos. Even though stats and compare both return metrics, their purposes are clearly separated (single vs. multi-repo), so no ambiguity.
All tool names follow the verb_noun pattern in snake_case (compare_repos, get_repo_languages, get_repo_stats, search_repos). The verbs are semantically appropriate and consistent in style.
The server is scoped to repository analytics and discovery, and four tools cover the core workflows without being sparse or bloated. Each tool has a clear purpose and earns its place.
The tool set covers the main steps of repository analysis: finding repos, getting overall stats, examining language breakdown, and comparing multiple candidates. Minor gaps exist (e.g., no direct tool for fetching README or file structure), but the provided surface is sufficient for the implied use case.