Streamable HTTP Server for GHES (oauth)

[SamMorrowDrums]

We'd love to hear from people who use the server with GHES, especially folks who have rolled their own fork and use the server on their own infra.

• What did you learn?
• Any friction (maintaining a fork counts here too)?
• Any GHES specific needs you would like us to consider?
• Anything not working for you?

---

📊 Interest Already Expressed in GHES/GHES-Specific Features

The community has filed several GHES-related issues showing significant demand:

Open Issues

• Support subdomain isolation for GHES hosts #500 - Support subdomain isolation for GHES hosts
• Add Streamable HTTP Transport Support for Multi-User Mode #471 - Add Streamable HTTP Transport Support for Multi-User Mode
• Network timeouts when interacting with GitHub Enterprise Server #299 - Network timeouts when interacting with GHES
• Better support custom TLS situations when using a Docker #157 - Better support custom TLS situations when using Docker

Notable Closed Issues

• support GitHub App installation‑token authentication (server‑to‑server) for MCP #311 - GitHub App installation-token authentication (30 👍)
• get_file_contents is not working properly (Path did not point to a file or directory, but resolved git ref) #864 - get_file_contents path resolution (14 👍)
• Multiple account support #623 - Multiple account support (4 👍)
• Custom GHES host names are not supported #662 - Custom GHES host names (fixed)
• Support the ability to have multiple instances running at the same time #206 - Support multiple instances (GHES + GHEC)

[bbartels]

We are looking into a centralised MCP to sit in front of GHES, is there any plans to still release support or merge the existing PR's to allow for multi tenancy? @SamMorrowDrums

For us it would be useful to have both PAT and OAUTH auth modes (PAT being higher priority for us)

[SamMorrowDrums]

We are actively working on it.

[SamMorrowDrums]

@bbartels #1482 (comment)

[SamMorrowDrums]

HTTP mode is now merged and will be in the next official release. Try it on main today:

https://github.com/github/github-mcp-server/blob/main/docs/streamable-http.md

[zamirD123]

Sorry i probably misread somthing

[caravin]

@SamMorrowDrums, I am assuming this is for enterprise setup where multi-tenancy is a requirement i.e., multiple mcp clients connecting to the same server via oauth.
If that is the intention, I have a few questions:

1. In our enterprise, we have our custom setup for doing OAuth. So will this implementation allow us to define our custom oauth endpoints?
2. One other thing I am not sure is how this Oauth token generated using our custom AD can be used to talk with out enterprise gituh..com. Will it be like we have to use the OAuth token for authenticating the end user and then use the PAT credentials shared by the user to talk to the github server?

I have had experience building or working with python mcp servers where we take the python object (mostly a FastMCP object) and mount it to a ASGI server authenticated with our custom setup. Because github mcp server is implemented in Go, I don't seem to get good clarity on how it works. Are there plans to implement this in python?

[SamMorrowDrums]

This particular feature I was imagining for just for end users, we have provided an http server endpoint that can likely do what you need, but in the end the remote server version just takes a bearer token, and you could likely put something in front (or client side) that obtains the token or provides the right Oauth app etc.

[caravin]

I see. So the actual Oauth that the mcp protocol mandates for connecting to mcp servers — this http endpoint doesn’t take care of that right?
Will it be like i can put a oauth layer before this just to authenticate the end user but then users would have to pass their PAT token for this endpoint to talk to the actual server?

[SamMorrowDrums]

The http server command supports standard Oauth as per the MCP spec. I was saying that you could do some other mechanism for token exchange if required for your business, and in the end we will accept a valid GitHub token as an authorization header bearer token.

This is for STDIO which has no protocol support for Oauth. I found a way to do it anyway, which is what I've been talking about in this thread.