镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

HTTP Server #2

Description

@toby

Implement a HTTP based MCP server that matches the functionality of the CLI server. It should require OAuth to access. We can reference the Anthropic docs on authorization but be flexible to implement our own best practices.

Activity

  1. added a commit that references this issue on Mar 13, 2025
  2. jngiam commented on Apr 4, 2025

    @jngiam

    We're have a HTTP based client that supports the latest specs; right now our AI agent connects to Github via APIs, would be interested to try this out / test whenever you have it ready.

  3. mathiasschopmans commented on Apr 5, 2025

    @mathiasschopmans

    I want to second @toby‘s request.

    Having a global GitHub.com/mcp / Streamable HTTP Transport would be awesome.

    Now that the latest MCP spec was released in the end of march, the link is broken and the auth docs can be found here: https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization/

    It may not fit into GitHubs Server-Stack or this Golang implementation, but Cloudflare created a great abstraction with their agents/mcp Typescript Library. Worth a read: https://developers.cloudflare.com/agents/guides/remote-mcp-server/

  4. SamMorrowDrums commented on Apr 15, 2025

    @SamMorrowDrums
    Collaborator

    Reposting the comment from @elizabetht 's issue, as I closed it as a dupe:


    Describe the feature or problem you’d like to solve

    As part of building interactive and responsive developer tools on top of the MCP server, we have a need to expose HTTP endpoints that can stream data incrementally to clients using Server-Sent Events (SSE). This is particularly useful for use cases like:

    • Real-time progress updates for long-running tool executions
    • Streaming logs or partial results as they become available
    • Event-driven workflows triggered by tools or models

    However, the current MCP server does not appear to support SSE-style HTTP streaming out of the box. Since SSE relies on keeping an HTTP connection open and continuously pushing updates using the text/event-stream content type, it requires explicit support at the server level to manage connection lifecycle and event formatting.

    Without native support, it's challenging to build streaming, real-time experiences using MCP — which limits the kind of rich developer tools and UIs that can be built on top of it.

    Proposed solution

    Adding SSE support would unlock:

    • Real-time user experiences (e.g., showing partial results or live updates)
    • Streaming logs or status updates for tool execution
    • Lower latency responses without requiring polling
    • Simplified client-side implementations using native browser support (vs. websockets)

    Additional context

    SSE support would:

    • Enhance Developer Experience: Provide users with more flexibility to build real-time tools or dashboards powered by MCP.
    • Broaden Adoption: Many organizations have frontends or APIs that rely on streaming capabilities — this would make MCP compatible with those out-of-the-box.
    • Improve Integration with AI/LLM Tooling: LLM-related use cases often benefit from streamed outputs (like token-by-token streaming) — SSE is ideal for that.
    • Align with Open Standards: SSE is supported in most browsers and backend frameworks, making it easier to integrate across diverse ecosystems.
    • Encourage Community Contributions: Clear extensibility via streaming would likely attract more usage and contributions in tool/plugin scenarios.
  5. scott-clare1 commented on May 2, 2025

    @scott-clare1

    Based on the example in the Go MCP SDK it looks like something like this should be doable to support SSE? https://github.com/mark3labs/mcp-go/blob/f3fef81032fde6519525abf64a9f67afdb0b3e38/examples/everything/main.go#L457

    Am happy to create a PR if this looks like an appropriate solution?

  6. yasonk commented on May 2, 2025

    @yasonk

    This would be really helpful for a production use case where I want to keep GitHub MCP running as own server.

  7. bhrutledge commented on May 6, 2025

    @bhrutledge

    This seems even more useful with the announcement of "Integrations" for Claude.ai and Claude Desktop. It'd be great to see GitHub in this list:

    To start, you can choose from Integrations for 10 popular services, including Atlassian’s Jira and Confluence, Zapier, Cloudflare, Intercom, Asana, Square, Sentry, PayPal, Linear, and Plaid—with more to follow from companies like Stripe and GitLab.

    I just replaced my local third-party Atlassian MCP server with the Atlassian's remote MCP server.

  8. yasonk commented on May 6, 2025

    @yasonk

    Based on the example in the Go MCP SDK it looks like something like this should be doable to support SSE? https://github.com/mark3labs/mcp-go/blob/f3fef81032fde6519525abf64a9f67afdb0b3e38/examples/everything/main.go#L457

    Am happy to create a PR if this looks like an appropriate solution?

    It looks right. The key is that you can connect to it via HTTP client (SSE in this case) and not stdio.

  9. williammartin commented on May 12, 2025

    @williammartin
    Collaborator

    Copying from #388

    Describe the feature or problem you’d like to solve

    Currently, the GitHub MCP Server Dockerfile supports execution only through the stdio interface. This limitation restricts its use with clients expecting an SSE (Server-Sent Events) endpoint, which is useful for long-lived, real-time communication patterns such as streaming model context updates

    Proposed solution

    Add a new entry point or configuration in the Dockerfile to allow the GitHub MCP Server to run as an SSE server out-of-the-box. This could include:

    Exposing an HTTP server that serves SSE responses on a configurable port (e.g., /sse).

    Allowing the user to select between stdio or sse mode via environment variable or command argument.

    This feature would simplify deployments, improve integration with SSE-compatible MCP clients, and make it easier for users to run the server without custom infrastructure.

    Additional context

    Many MCP clients and tools support SSE mode by default. Enabling this in the Dockerfile will enhance compatibility and usability, especially in containerized or orchestration environments like Kubernetes.

  10. gavinmcfall commented on May 19, 2025

    @gavinmcfall

    Adding my desire to have this, I would like to be able to wire Githib MCP into tooling like Open-WebUI, n8n, etc and that is a real challenge when all you have to work with is stdio

  11. trevor-coleman commented on May 19, 2025

    @trevor-coleman

    I'd also like this -- I have a home server that i use to host all my docker containers so I don't need to run them locally, and it would be great to be able to put this on there.

  12. sidarth164 commented on May 31, 2025

    @sidarth164

    Jumping on the bandwagon - it would be very helpful to have such an HTTP MCP server. In fact - this could allow me to setup a centrally managed server for my team - thereby removing all the setup hassle.

  13. kevin-presalytics commented on Jun 2, 2025

    @kevin-presalytics

    Also upvoting this. This would allow models to get application contexts for non-technical enterprise users.

  14. SamMorrowDrums commented on Jun 12, 2025

    @SamMorrowDrums
    Collaborator
  15. yasonk commented on Jun 12, 2025

    @yasonk

    @SamMorrowDrums Just to confirm, this remote server is hosted by GitHub, so there is no need to host own HTTP MCP server, right?

  16. SamMorrowDrums commented on Jun 12, 2025

    @SamMorrowDrums
    Collaborator

    Correct @yasonk

  17. ghost added a commit that references this issue on Jun 15, 2025
  18. added a commit that references this issue on Dec 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions