github-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: user identity, code search, repo listing/detail/search, file retrieval, issue listing/creation, and pull request listing. There is no overlap or ambiguity between tools.
Naming Consistency5/5
All tools follow a consistent `github_` prefix with snake_case naming and a verb_noun pattern (search_code, list_repos, get_repo, create_issue). The `whoami` tool slightly deviates from the noun structure but remains a recognizable verb, so the overall pattern is highly predictable.
Tool Count5/5
With 9 tools, the server is well-scoped for a GitHub integration, covering common read operations (user, search, repos, files, issues, PRs) and a couple of write operations (create issue). The count feels intentional and not bloated.
Completeness4/5
The server covers the core GitHub browsing and searching workflow, including user identity, repository list/search/detail, file content, and issue list/create. Minor gaps exist such as lacking PR creation/update, issue update/delete, and repository creation, but these are not critical for a read-oriented utility.
Average 3.3/5 across 9 of 9 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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 ISC 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

Behavior1/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 doesn't mention that creating an issue is a permanent mutation, requires authentication, or what the API response looks like. The description only restates the action and offers zero transparency beyond the literal operation.
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, direct sentence with no redundant words. It is front-loaded with the action verb and is appropriately concise for a simple create operation, making it easy to read and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is far too sparse. It lacks essential context such as return values, authentication requirements, error conditions, and parameter details, making it inadequate for an agent to confidently invoke the tool without further information.
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 compensate by explaining what owner, repo, title, body, or labels mean or how they interact. Even though the parameter names are somewhat self-explanatory in a GitHub context, the description adds no value beyond the schema's type and required fields.
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 action with a specific verb ('Create') and resource ('new issue') in a repository context. While it doesn't explicitly mention alternative tools, the 'create' verb effectively distinguishes it from sibling list/search tools like github_list_issues, so it's clear but lacks explicit differentiation.
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, no mention of required permissions, repository ownership, or any expected flow. It simply states what it does without contextualizing the use case.
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 must carry behavioral burden, but it only states the basic function. It does not disclose defaults (like state=open), pagination, or other behaviors, leaving the agent under-informed.
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 a single short sentence with no fluff, but it is under-specified and almost paraphrases the tool name. It is concise but does not earn its place with added value.
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?
For a tool with 4 parameters, no output schema, and no annotations, this description is highly incomplete. It omits default behaviors, scope limitations, and expected response shape, making it inadequate for reliable invocation.
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 coverage is 0% and the description adds no meaning to any parameter. It does not explain state options, per_page limits, or the roles of owner/repo, failing to compensate for the bare 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 lists pull requests in a repository, using a specific verb and resource. However, it does not distinguish from sibling tools like list_issues or provide scope details, so it misses the top score.
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?
Usage is implied—when you need to list pull requests—but no explicit guidance is given about when to choose this over alternatives, nor any exclusions or prerequisites.
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. It only states 'List issues,' implying a read-only operation, but does not disclose default state filtering, pagination, response format, or rate limits. The description adds no behavioral context beyond what the name implies.
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, front-loaded sentence with no filler. It is concise, though extremely minimal; it could include brief parameter hints without losing conciseness, but this is not a major flaw.
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?
For a tool with 4 parameters and no annotations or output schema, the description is insufficient. It does not mention the default state ('open'), pagination limits, or what fields are returned. An agent would need to guess essential behavior.
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 4 parameters with 0% description coverage. The description does not mention owner/repo requirements, the state enum, or per_page bounds. Since coverage is low and there is no parameter information, the description fails to compensate for the schema gap.
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: 'List issues in a repository' with a specific verb (list), resource (issues), and scope (repository). This distinguishes it from siblings like github_create_issue and github_list_pull_requests.
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 such as github_list_pull_requests. There is no mention of prerequisites, intended use cases, or exclusions.
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 restates the purpose ('Get the contents') and omits important details such as base64-encoded content, response format, or authentication requirements.
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 sentence, front-loaded with the action verb 'Get', and contains no unnecessary words. It is highly concise while still conveying the core purpose.
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?
There is no output schema, so the description should explain what the response contains. It does not mention the return format, file encoding, or any edge cases, making it incomplete for an agent to fully understand 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 describes ref and path, but not owner and repo; the description adds no parameter semantics at all. With 50% schema coverage, the description does not compensate for the undocumented parameters, leaving the agent with minimal guidance beyond parameter names.
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 the specific verb 'Get' with the resource 'contents of a file from a GitHub repository', clearly stating the tool's function and distinguishing it from sibling tools like github_search_code or github_get_repo.
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. It simply states the function without any contextual clues, exclusions, or references to sibling tools.
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 of behavioral disclosure. It does not mention authentication requirements, rate limits, or what the response contains. For a read operation, it omits any detail about the return payload, making the behavior opaque.
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 is front-loaded with the action and subject. Every word earns its place, with no redundant or filler content.
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?
As a simple 2-parameter tool with no output schema, the description is adequate but not complete. It does not explain what 'details' are returned, nor does it address authentication or error conditions. It is minimally viable but leaves the agent with questions about the response structure.
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 fully documents both parameters (owner and repo) with descriptions, achieving 100% schema_description_coverage. The tool description adds no additional meaning 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.
Purpose4/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: 'Get details about a specific repository.' It uses a specific verb ('Get') and resource ('repository'), and the phrase 'specific' distinguishes it from sibling tools like github_list_repos and github_search_repos. However, it does not explicitly name the alternative tools or elaborate on what 'details' includes.
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 its use when a known, specific repository is required, but it provides no explicit guidance on when to use this tool versus alternatives like github_search_repos or github_get_file. No exclusions or conditional advice 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure, but it only restates the tool's basic action. It does not mention read-only nature, pagination behavior, authentication requirements, or any potential side effects, offering negligible transparency 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 clear sentence with no redundant words. It is concise and front-loaded, effectively communicating the core function in minimal space.
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?
The description is too sparse for a tool with no output schema, no annotations, and multiple siblings. It does not mention return value structure, pagination options, or how results are ordered, leaving critical contextual information missing for an agent to fully understand 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 covers 50% of parameters (query has a helpful example, but per_page has no description). The tool description itself adds no parameter semantics, merely referencing 'keyword/query' without elaboration. The per_page parameter remains minimally explained, relying on its type and range to convey meaning.
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 'Search GitHub repositories by keyword/query' clearly states the verb (search) and resource (repositories), distinguishing it from github_search_code which searches code. It unambiguously conveys the tool's purpose.
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 tool is for searching repositories by query but provides no explicit guidance on when to use it over alternatives like github_list_repos or github_search_code. No exclusions or alternative comparisons are given, leaving usage context largely implicit.
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 provided, the description carries the full burden. It mentions the authentication context ('authenticated user') and the scope ('owned by or accessible'), which is useful. However, it does not disclose pagination behavior, sorting defaults, or explicitly state that it is a read-only operation. Minimal but non-contradictory disclosure.
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 sentence of about 10 words, direct and free of redundancy. It is front-loaded with the core action and scope, earning a high score for conciseness and structure.
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 only three optional parameters and no output schema. The description captures the core action and scope, but it omits details about return format and pagination behavior. Given the lack of annotations and output schema, it is adequate but not fully complete.
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 only 33% (only 'type' has a description). The description does not mention any parameters (sort, type, per_page) or add meaning beyond the schema. It fails to compensate for the low coverage, leaving parameter semantics largely unexplained.
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 purpose: 'List repositories owned by or accessible to the authenticated user.' It uses a specific verb ('List') and resource ('repositories'), and the scope ('owned by or accessible to the authenticated user') distinguishes it from sibling tools like github_search_repos and github_get_repo.
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 when to use this tool (when you need the authenticated user's repositories), but it does not explicitly mention alternatives or when not to use it. No exclusion criteria or comparison with sibling tools is provided, so guidance is only implied.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals that repo scoping is possible via `repo:owner/name` and provides an example, but it does not mention any rate limits, authentication needs, or return format. Since it is a search tool, read-only behavior is implied, but not explicitly stated.
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 clear sentence that is front-loaded with the core purpose and includes a useful example. It is concise, well-structured, and every word contributes meaning.
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 simple two-parameter schema and no output schema or annotations, the description covers the primary use case and the repo-scoping feature. However, it omits the optional `per_page` parameter details and does not explicitly contrast with repo search, so it is not fully complete but sufficient for a straightforward search tool.
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 only 50% (query has a description, per_page does not). The description repeats the schema's example for `query` but adds no new meaning for `per_page`, which remains undocumented. Thus the description adds little value beyond what the schema already provides and fails to compensate for the coverage gap.
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 action ('Search code') and the resource ('across GitHub'), with a specific scoping option (`repo:owner/name`). It unambiguously distinguishes itself from the sibling `github_search_repos` by focusing on code rather than repositories.
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 description gives clear context on when to use the tool (searching code globally or within a specific repo) but does not explicitly mention when not to use it or name alternatives. However, the sibling tool names provide implicit differentiation, so the guidance is adequate but not fully explicit.
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?
No annotations are provided, so the description carries the burden. It mentions the output fields but does not explicitly state authentication requirements or potential errors. However, the term 'authenticated' implies that an auth token is required, and for a simple read operation this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It includes a parenthetical list of example return fields, adding value without extra words.
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's simplicity (no parameters, no output schema), the description is sufficiently complete. It lists the key return fields and indicates the scope ('authenticated user'). It could mention edge cases like no token or rate limits, but the context signals show this is a basic tool.
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 the schema provides no semantics. The baseline is 4 per the rubric. The description adds no parameter info because none are 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 the tool gets the authenticated GitHub user's profile, listing specific details like login, name, and email. This is a specific verb+resource that distinguishes it from sibling tools (e.g., github_get_repo, github_list_repos).
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 context is clear: this is for retrieving the current user's own profile. It implies when to use it (when you need authenticated user info) and no alternatives among siblings serve the same purpose. However, it doesn't explicitly state exclusions or alternatives, so a 4 is appropriate.
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-server MCP server](https://glama.ai/mcp/servers/hampannagouda/github-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/hampannagouda/github-mcp-server)

Score Badge

Copy to your README.md:

[![github-mcp-server MCP server](https://glama.ai/mcp/servers/hampannagouda/github-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/hampannagouda/github-mcp-server)

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/hampannagouda/github-mcp-server'

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