Live data from Hacker News

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

gitmcp.io

51–60 of 67 posts

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

#51

Earlier quoted context omitted.

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.

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.

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

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

#52
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.

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

#53
post #40
post #39

Earlier quoted context omitted.

[flagged]

Is this the new LMGTFY?

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.

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

#54

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 d…

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.

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

#55
post #36

Earlier quoted context omitted.

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…

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

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.

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

#56

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…

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.

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

#57

Earlier quoted context omitted.

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.

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.

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.

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

#58
post #54

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 d…

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 ho…

That sounds really interesting! What got us into this project is the problem in with the LLM a large llms-full.txt file as a context, for example. We wanted to provide the agents an easy way to get the documentation for every repo (be it llms.txt, readme, etc) - but also search chunks of it using semantic search. Will be happy to chat more, if you like - sounds like we can benefit from bouncing ideas and notes

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

#59
post #36

Earlier quoted context omitted.

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

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…

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.

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

#60
post #59

Earlier quoted context omitted.

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…

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 )

Post reply on HN