Show HN: GitMCP is an automatic MCP server for every GitHub repo

But why would we need an MCP server for a github repo? Sorry, I am unable to understand the use case.

It's very helpful when working with a specific technology/library, and you want to access the project's llms.txt, readme, search the docs, etc from within the IDE using the MCP client. Check it out, for exmaple, with the langgraph docs: https://gitmcp.io/#github-pages-demo It really improves the development experience.

Same here. Can't we just give the repo URL in Cursor/Windsurf to use the search tool to get the context? :thinking:

As an example, some repositories have huge documents (in some cases a few MBs) that agents won't process today. GitMCP offers semantic search out of the box.

Yeah this is one fundamental reason I don't see MCP taking off. The only real use cases there are will just be built in natively to the tools.

Once case I’ve found valuable is dropping a reference to a PR that’s relevant to my work.

I’ll tell it to look at that PR to gain context about what was previously changed.

Right, because agents can utilize git natively.

If this is for navigating/searching github in a fine-grained way, then totally cool and useful.

MCP servers present a structured interface for accessing something and (often) a structured result.

You tell the LLM to visit your GitHub repository via http and it gets back… unstructured, unfocused content not designed with an LLM’s context window in mind.

With the MCP server the LLM can initiate a structured interface request and get back structured replies… so instead of HTML (or text extracted from HTML) it gets JSON or something more useful.

Is html less structured than json? I thought with LLMs the schematic of structure is less relevant than the structure itself.

Yes, they could be, but then you 100% rely on the client tools doing a good job doing that, which they aren't always good at, and they also have to reinvent the wheel on what are becoming essentially commodity features.

E.g. one of the biggest annoyances for me with cursor was external documentation indexing, where you hand it the website of a specific libarary and then it crawls and indexes that. That feature has been completely broken for me (always aborting with a crawl error). Now with a MCP server, I can just use one that is specialized in this kind of documentation indexing, where I also have the ability to tinker with it if it breaks, and then can use that in all my agentic coding tools that need it (which also allows me to transfer more work to background/non-IDE workflows).

It’s one of my favourite MCP use cases. I have cloned projects and used the file browser MCP for this, but this looks great.

It allows you to ask questions about how an entire system works. For example the other day “this GitHub action requires the binary X. Is it in the repo, downloading it, or building it on deploy, or something else.” Or “what tools does this repo used to implement full text search? Give me an overview”

Just trying to explain it to you made me think of a very good reason why an MCP is preferable to just telling it to fetch a page. When you tell ChatGPT or Sonnet or even cursor/windsurf/whatever to fetch a website do you know exactly what it is fetching? Does it load the raw html into the context? Does it parse the page and return just the text? What about the navigation elements, footer and other “noise” or does it have the LLM itself waste precious context window trying to figure the page out? Is it loading the entire page into context or truncating it? If it is truncated, how is the truncation being done?

With an MCP there is no question about what gets fed to the model. It’s exactly what you programmed to feed into it.

I’d argue that right there is one of the key reasons you’d want to use MCP over prompting it to fetch a page.

There are many others too though like exposing your database via MCP rather than having it run random “psql” commands and then parsing whatever the command returns. Another thing is letting it paw through splunk logs using an MCP, which provides both a structure way for the LLM to write queries and handle the results… note that even calling out to your shell is done via an MCP.

It’s also a stateful protocol, though I haven’t really explored that aspect.

It’s one of those things that once you play with it you’ll go “oh yeah, I see how this fits into the puzzle”. Once you see it though, it becomes pretty cool.

I don’t mind schemas and repositories, but I feel it’s a bit backwards. That’s the kind of work I would hope we can avoid with AI.

MCP is written for the AI we’ve got not the ones doing all the hyping want us to believe exists.

With a long enough context window it wouldn’t matter the difference. But “long enough” in this context to me means where you view its length as big enough where size no longer matters. Kind of like modern hard drives that are “big enough that I don’t care about a 1gb file” (I was thinking megabyte files but that might be too large of an order of magnitude )