Search GitHub repos, issues, pull requests, and user profiles for development intelligence via MCP.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 4 of 4 tools scored.
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.
compare_reposACompare 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.
get_repo_languagesAAnalyze 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.
get_repo_statsAFetch 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_reposASearch 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
