Hacker Remix

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

170 points by liadyo 1 day ago | 51 comments

kiitos 1 day ago

> Simply change the domain from github.com or github.io to gitmcp.io and get instant AI context for any GitHub repository.

What does this mean? How does it work? How can I understand how it works? The requirements, limitations, constraints? The landing page tells me nothing! Worse, it doesn't have any links or suggestions as to how I could possibly learn how it works.

> Congratulations! The chosen GitHub project is now fully accessible to your AI.

What does this mean??

> GitMCP serves as a bridge between your GitHub repository's documentation and AI assistants by implementing the Model Context Protocol (MCP). When an AI assistant requires information from your repository, it sends a request to GitMCP. GitMCP retrieves the relevant content and provides semantic search capabilities, ensuring efficient and accurate information delivery.

MCP is a protocol that defines a number of concrete resource types (tools, prompts, etc.) -- each of which have very specific behaviors, semantics, etc. -- and none of which are identified by this project's documentation as what it actually implements!

Specifically what aspects of the MCP are you proxying here? Specifically how do you parse a repo's data and transform it into whatever MCP resources you're supporting? I looked for this information and found it nowhere?

broodbucket 23 hours ago

As someone who is obviously not the target audience, I feel like literally anything on this page that could lead me to explain what MCP is would be nice, while we're talking about what the landing page doesn't tell you. Even just one of the MCP mentions being a link to modelcontextprotocol.io would be fine.

Or maybe I'm so out of the loop it's as obvious as "git" is, I dunno.

fragmede 11 hours ago

It’s fair to be curious, but at some point it’s also reasonable to expect people are capable of using Google to look up unfamiliar terms. I'm not gatekeeping—just, like, put in a bit of effort?

Threads like this work better when they can go deeper without rehashing the basics every time.

matthewdgreen 37 minutes ago

I took a brief look at the MCP documentation today, and left looking confused. At a high level that protocol looks like a massive swiss-army knife that could potentially do everything, and the use-case in TFA looks like it's implementing one very specific tool within that large swiss-army knife. Both need better explanation.

johannes1234321 8 hours ago

Having a Link to the mcp website won't be "rehashing" but how the web once was supposed to be.

T3RMINATED 10 hours ago

[dead]

sdesol 15 hours ago

[flagged]

kiitos 10 hours ago

I appreciate that! Now maybe they could update the readme accordingly! ;)

john2x 13 hours ago

Is this the new LMGTFY?

sdesol 6 hours ago

Not really. I had to do the following:

- Identify the files that should be put into context since tokens cost money and I wanted to use a model that was capable like Sonnet, which is expensive.

- There were 35 messages (minus 2 based on how my system works) so I wrote and read quite a bit. I was actually curious to know how it worked since I have domain knowledge in this area.

- Once I knew I had enough context in the messages, I switched to Gemini since it was MUCH cheaper and it could use the output from Sonnet to guide it. I was also confident the output was accurate since I know what would be required to put a Git repo into context and it isn't easy if cost, time and accuracy is important.

Once I went through all of that I figured posting the parent questions would be a good way to summarize the tool, since it was very specific.

So I guess if that is the next LMGTFY, then what I did was surely more expensive and timeconsuming.

sivaragavan 6 hours ago

I see the appeal of it. It is a good start. But I don't think it's quite useful yet. This proves to be a great distribution model for an MCP project.

FWIW, this project creates two tools for a GitHub repo on demand

  fetch_cosmos_sdk_documentation
  search_cosmos_sdk_documentation

These tools would be available for the MCP client to call when it needs information. The search tool didn't quite work for me, but the fetch did. It pulled the readme and made it available to the MCP client. Like I said before, it's not so helpful at the moment. But I am interested in the possibilities.

sdesol 6 hours ago

Full Disclosure: I built an indexing engine for Git and GitHub that can process repos at scale and my words should be taken with scepticism.

I think using MCP is an interesting idea, but the heavy lifting that can provide insights, is not with MCP. For fetch and search to work effectively, the MCP will need quality context to know what to consider. I'm biased, but I really looked into chunking documents, but given how the LLM landscape is evolving, I don't think chunking makes a lot sense any more (for code at least).

I've committed to generating short and long overviews for directories and files. Short overviews are two to three sentences. And long overviews are two to three paragraphs. Given how effectively newer LLMs can process 100,000 tokens or less, you can feed it a short overview for all files/directories to determine what files to sub query with. That is, what long overviews to load into context for the sub query.

I also believe most projects in the future will start to produce READMEs for LLMs that are verbose and not easy to grok for humans, but is rich in detail for LLMs. You may not want the LLM to generate the code for you, but the LLM can certainly help us navigate complex/unfamiliar code in a semantic manner, which can be game changer for onboarding.

ianpurton 16 hours ago

Some context.

1. Some LLMs support function calling. That means they are given a list of tools with descriptions of those tools.

2. Rather than answering your question in one go, the LLM can say it wants to call a function.

3. Your client (developer tool etc) will call that function and pass the results to the LLM.

4. The LLM will continue and either complete the conversation or call more tools (functions)

5. MCP is gaining traction as a standard way of adding tools/functions to LLMs.

GitMCP

I haven't looked too deeply but I can guess.

1. Will have a bunch of API endpoints that the LLM can call to look at your code. probably stuff like, get_file, get_folder etc.

2. When you ask the LLM for example "Tell me how to add observability to the code", the LLM can make calls to get the code and start to look at it.

3. The LLM can keep on making calls to GitMCP until it has enough context to answer the question.

Hope this helps.

sandbags 5 hours ago

I’ve been wanting to write this somewhere and this seems as good a place as any to start.

Is it just me or is MCP a really bad idea?

We seem to have spent the last 10 years trying to make computing more secure and now people are using node & npx - tools with a less than flawless safety story - to install tools and make them available to a black box LLM that they trust to be non-harmful. On what basis, even about accidental harm I am not sure.

I am not sure if horrified is the right word.

liadyo 1 day ago

We built an open source remote MCP server that can automatically serve documentation from every Github project. Simply replace github.com with gitmcp.io in the repo URL - and you get a remote MCP server that serves and searches the documentation from this repo (llms.txt, llms-full.txt, readme.md, etc). Works with github.io as well. Repo here: https://github.com/idosal/git-mcp

nlawalker 24 hours ago

>searches the documentation from this repo (llms.txt, llms-full.txt, readme.md, etc)

What does etc include? Does this operate on a single content file from the specified GitHub repo?