GitHub-MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct resource and action, but there is some potential confusion between analysis tools (e.g., analyze_issue vs get_issue) and retrieval tools. Overall, descriptions are clear enough to distinguish them.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_, list_, analyze_, etc.), but 'hello_world' and 'repository_health' deviate from this convention. The naming is mostly consistent with minor exceptions.
Tool Count4/5
With 15 tools, the server is at the upper edge of a well-scoped set. Each tool seems to serve a distinct purpose, though a few could potentially be consolidated without losing functionality.
Completeness3/5
The server provides good read and analysis operations for issues, PRs, repositories, and users, but lacks write operations like creating issues, merging PRs, or updating repositories. This limits its utility as a complete GitHub MCP server.
Average 3.2/5 across 15 of 15 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the analysis is 'deterministic,' hinting at reproducibility, but does not disclose whether it is read-only, whether it requires authentication, what side effects occur, or what the return structure is. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is brief, but it is under-specified rather than concise. The sentence does not convey enough information to be useful, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description does not clarify the nature of the analysis or how it integrates with related tools. Given the sibling set, more context is needed to know when to invoke this tool over alternatives. The minimal description is incomplete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter explanations. The parameter names (owner, repo, pull_number) are self-explanatory, but the description adds no value beyond the schema. It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'analyze' and the resource 'GitHub Pull Request,' but 'deterministic analysis' is vague and does not explain what aspects of the PR are analyzed. It fails to distinguish from sibling tools like analyze_issue or get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool or how it differs from alternatives such as get_pull_request or analyze_issue. The absence of any 'use this when' or exclusion statement leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the analysis is 'deterministic', which is a minimal behavioral trait. It does not disclose side effects, permissions, rate limits, or any operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant information. It is front-loaded with the key action, making it concise and easy to parse. It loses a point because the brevity contributes to under-specification rather than effective communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete. It fails to explain what 'analysis' means, what the output represents, or any prerequisites. It also lacks comparison to sibling tools, leaving the agent without sufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining the parameters. It simply mentions 'GitHub Issue' without adding meaning to owner, repo, or issue_number beyond their names. This does not help the agent understand parameter structure or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'perform analysis' and the resource 'GitHub Issue', and it distinguishes itself from sibling tools like get_issue (which retrieves) and analyze_pull_request (which analyzes a different resource). However, it does not specify what the analysis entails, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the basic action and fails to mention pagination, filtering, authentication requirements, rate limits, or any other behavioral traits. This is a significant gap for a tool that could have such behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no fluff. It is appropriately concise for a simple tool, though it lacks critical details that could be included without clutter. It is not misleading and reads clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no nested objects) and presence of an output schema, the description is still incomplete. It fails to mention whether all pull requests or only open ones are returned, lacks any usage context, and does not address behavioral concerns. The description, while minimally functional, leaves the agent with significant uncertainty about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only says 'for a repository' which vaguely hints at the repo parameter but does not explain the meaning of 'owner' or clarify required vs optional parameters. The parameter names are self-explanatory, but the description adds no meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List pull requests for a repository' clearly states the verb (list) and resource (pull requests) with scope (for a repository). It is specific enough to distinguish from siblings like get_pull_request or analyze_pull_request, though it does not explicitly differentiate by noting it returns multiple results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons to sibling tools like list_repository_issues or analyze_pull_request, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. The word 'deterministic' adds a behavioral trait, but the description does not disclose whether this operation is read-only, how many API calls it might make, whether it requires authentication, or how it handles invalid usernames. This is insufficient for an aggregation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a single functional sentence followed by a required Args section. Every word earns its place; there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description gives no sense of what the 'comprehensive analysis' actually entails—what metrics, what repos, what comparison logic. With many sibling tools available, the lack of contextual guidance makes the tool harder to invoke correctly in complex workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. The line 'username: The exact GitHub username to analyze' adds the precision requirement ('exact') and clarifies the target is a GitHub username. This is marginal but meaningful given the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a comprehensive, deterministic analysis on a GitHub developer's profile and repositories. It distinguishes itself from more specific sibling tools like get_user_profile or list_user_repositories by emphasizing the aggregated analytic nature, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools (e.g., get_user_profile, repository_health, analyze_issue). The phrase 'comprehensive, deterministic analysis' implies a broad use case, but there are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get details' and omits any mention of read-only nature, authentication requirements, rate limits, or error behavior (e.g., 404 if not found). This is a minimal disclosure that falls short for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence of seven words, with no filler or redundancy. It is front-loaded with the action and object, making it easy to scan. Perfectly appropriate in size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (so return values are presumably covered), the description lacks essential context for correct tool selection and invocation. There are no annotations, no parameter semantics, and no usage guidelines, leaving the agent with only the tool name and a minimal description. For a simple tool this is still insufficient to fully understand behavior and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not describe any of the three parameters (owner, repo, pull_number). The parameter names are self-explanatory, but the description adds no value beyond the schema. Since coverage is low, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('a specific pull request'). It distinguishes itself from sibling tools like list_pull_requests (specific vs. list) and get_issue (pull request vs. issue). The purpose is unambiguous and easily understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While 'specific' implies it is for a single pull request, it does not mention the sibling analyze_pull_request or any exclusion criteria. An agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation through the verb 'get,' but fails to mention what specific details are returned, any pagination, or potential lack of authentication. The description adds minimal context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. Every word earns its place, and there is no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context. It does not explain when to prefer this over list_repository_issues or analyze_issue, nor does it mention any constraints or required authentication. The minimal text is insufficient for a tool with no annotations and undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any parameters. While 'owner', 'repo', and 'issue_number' are self-explanatory, the description provides no additional meaning or clarification, failing to compensate for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details for a specific issue' uses a specific verb and resource, clearly distinguishing it from siblings like list_repository_issues (which lists issues) and analyze_issue (which analyzes). It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_repository_issues or get_pull_request. There are no explicit use cases, exclusions, or comparisons to siblings, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears the full burden of behavioral disclosure. 'Fetch' implies a read-only operation, but the description does not mention potential side effects, authentication needs, rate limits, or what precisely constitutes 'language statistics.' This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, but it repeats the parameter list and definitions already present in the input schema. This redundant Args block wastes space and could be omitted to make the description more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations, the tool is simple and the output schema covers return values. The description states the essential purpose and parameters, which is sufficient for a basic get operation. It lacks usage differentiation from siblings, but this is partly offset by the clear purpose statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. However, the Args section merely restates the parameter names with trivial definitions ('The repository owner', 'The repository name'), adding little beyond the schema's own property titles. No examples, formats, or additional constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch language statistics for a repository' uses a specific verb 'fetch' and defines the resource (language statistics). This clearly distinguishes it from sibling tools like get_repository or analyze_repository, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The description only states the function and parameters, leaving the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'fetch' without mentioning authentication requirements, rate limits, or the shape of the result. This is a minimal disclosure for a tool that likely performs an external API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence and a parameter listing. Every word earns its place, and there is no fluff. This is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description doesn't need to explain return values. However, it lacks context about the scope (e.g., does it include private repos?) and fails to mention any pagination or result limits. It is minimally sufficient but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section adds 'exact' and 'to look up' to the username parameter, providing marginal meaning beyond the schema's title. It clarifies the parameter's role but lacks details like formatting or case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a user's repositories, which is a specific verb and resource. It is distinct from siblings like get_repository (single repo) or get_user_profile (profile), but does not explicitly differentiate itself, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or context are provided, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states that a report is generated, with no mention of read-only status, data sources, rate limits, or any side effects. This is insufficient for a tool that likely performs extensive analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an Args block, with no redundant content. It front-loads the core purpose and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the return format need not be detailed, but the description lacks broader context such as what constitutes a health report, how it relates to sibling analyze_* tools, and any prerequisites. The tool's scope and integration points are undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only restates the property names ('owner' and 'repo') with minimal elaboration ('The repository owner.', 'The repository name.'). It adds no examples, formats, or constraints beyond what the schema titles already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and identifies a clear deliverable ('repository health report with actionable recommendations'). This clearly distinguishes it from siblings like get_repository or analyze_issue, which focus on specific data retrieval or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over siblings. The description does not mention alternatives or conditions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral detail beyond the action itself. It does not mention authentication requirements, rate limits, or what a 'profile' includes, so the agent lacks context about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one main sentence plus a parameter explanation. It uses no unnecessary words and is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch with an output schema, the description covers the core purpose and parameter. However, it omits extra context such as authentication, edge cases, or when to choose this over related tools, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains that 'username' is 'The exact GitHub username to look up', adding useful semantic detail beyond the schema's bare type definition. This clarifies the parameter's meaning and exactness, compensating for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'a user's GitHub profile', making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like get_repository or analyze_developer, though the name and phrasing are sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without providing context on scenarios, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'recommends' but does not explicitly confirm it is read-only, mention authentication requirements, or explain how interests are derived. This lack of detail leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a simple argument list, no redundant content, and the main purpose is front-loaded. It is appropriately sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description is moderately complete. It explains purpose and the argument, but lacks context on what 'interests' means, how recommendations are generated, or any limitations. The presence of an output schema mitigates the need to describe return values, but more context would still help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the line 'username: The GitHub username to analyze,' which gives some meaning beyond the bare schema name. However, this is minimal—it does not clarify format, whether it is a login or ID, or any other constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Recommend new repositories to a developer based on their interests.' It uses a specific verb ('Recommend'), identifies the resource ('new repositories'), and specifies the context ('based on their interests'), distinguishing it from siblings like analyze_developer or list_user_repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context—an agent should call this when a developer wants repository recommendations based on their interests. However, it does not explicitly compare with alternatives or mention when not to use it, leaving the guidance at an implied level rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not state that this is a read-only operation, how popularity/activity/health are measured, or whether API rate limits apply. The description is silent on side effects, data sources, or potential errors. For a tool that presumably fetches GitHub data, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Args section is a bit repetitive but not wordy. Every sentence earns its place, though the Args list could be more compactly integrated. It is slightly over-structured for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though details are not visible here), so return values are likely covered. The description covers purpose and parameters adequately, but lacks usage guidelines and behavioral transparency. Given the tool's moderate complexity, it is minimally complete but leaves clear gaps in context that could trip up an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does list all four parameters and adds meaning beyond the schema: 'owner1: The owner of the first repository,' etc. This clarifies that owner and repo are separate strings and how the parameters are paired. However, it does not provide formats, examples, or additional constraints, so it is helpful but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare two GitHub repositories based on popularity, activity, and health.' This uses a specific verb and resource, and distinguishes it from sibling tools like get_repository or repository_health, which focus on single repos. The comparison aspect is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to compare two repositories. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It is a clear purpose, but no proactive usage guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'Fetch details,' which implies read-only but adds no context about authentication, rate limits, or response behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with a clear purpose statement followed by parameter definitions. No unnecessary words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to detail return values. It covers the essential purpose and parameters. However, it could add a note about the scope of 'details' or distinguish from list operations, but for a simple fetch tool it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are minimal (titles only), but the description explains that owner can be a username or organization and repo is the repository name. This clarifies the parameters beyond the schema, though it doesn't include types or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch details for a specific repository' with a specific verb and resource. This distinguishes it from sibling tools like list_user_repositories (listing) and get_repository_languages (languages only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use, or related tools. The usage context is implied only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the tool's purpose (greeting and verification) but does not describe output format, side effects, or any edge behavior. For a zero-parameter hello tool this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the purpose efficiently. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial zero-parameter hello-world tool with an output schema, the description fully covers the context needed. There are no additional edge cases, prerequisites, or return-value concerns that a user would reasonably expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The schema and description are fully consistent, and the baseline for 0-parameter tools is 4 because no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('a friendly greeting') and its purpose ('verifying GitHub-MCP is running'). It unambiguously distinguishes this tool from the GitHub-analysis siblings as a health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'verifying GitHub-MCP is running' clearly implies the use case: check connectivity/server status. It does not explicitly mention alternatives, but for a simple hello-world tool no exclusions are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It specifies a scoped read operation ('open issues' and 'excluding pull requests'), which is useful behavioral context. However, it does not mention auth, pagination, or error behavior, though an output schema 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single purpose sentence followed by a minimal Args block. Every word earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward two-parameter list tool with an output schema, the description is nearly complete. It covers purpose, scope, and parameter meanings. The only minor gap is not mentioning the output format explicitly, but the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only names and types for owner and repo, but the description's Args section explains that owner is the repository owner and repo is the repository name. This adds meaningful context beyond the bare schema, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists open issues for a repository and explicitly excludes pull requests. This distinguishes it from sibling tools like list_pull_requests and get_issue, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'excluding pull requests' provides a clear boundary for when not to use the tool, but it does not explicitly name the alternative tool (list_pull_requests) for that case. This gives clear context and an exclusion, but stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![GitHub-Mcp MCP server](https://glama.ai/mcp/servers/ZenitsuAckerman/GitHub-Mcp/badges/card.svg)](https://glama.ai/mcp/servers/ZenitsuAckerman/GitHub-Mcp)

Score Badge

Copy to your README.md:

[![GitHub-Mcp MCP server](https://glama.ai/mcp/servers/ZenitsuAckerman/GitHub-Mcp/badges/score.svg)](https://glama.ai/mcp/servers/ZenitsuAckerman/GitHub-Mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZenitsuAckerman/GitHub-Mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server