Posted by liadyo 7 days ago
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?
Or maybe I'm so out of the loop it's as obvious as "git" is, I dunno.
Threads like this work better when they can go deeper without rehashing the basics every time.
There's always a baseline expectation of some kind of shared context, sure, and within that kind of context your comment makes total sense. But all of the stuff I'm pointing out is definitely not part of any notion of that kind of shared context. That's my whole point!
If you give a lecture to 100 people, and 5 people leave that lecture confused, that's their problem. But if 95 people leave that lecture confused, that's your problem.
- 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.
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.
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.
What does etc include? Does this operate on a single content file from the specified GitHub repo?
FWIW, this project creates two tools for a GitHub repo on demand
fetch_cosmos_sdk_documentation
search_cosmos_sdk_documentation
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.
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”
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.
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.
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 )
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).
I’ll tell it to look at that PR to gain context about what was previously changed.
If this is for navigating/searching github in a fine-grained way, then totally cool and useful.
Not sold on MCP being the right paradigm (we'll see), but had a lot of fun building an MCP server recently using https://github.com/tadata-org/fastapi_mcp to quickly get up and running and be able to call to it from Cursor.
What about private repos in, let's say GitLab or Bitbucket instances, or something simpler?
A Dockerfile could be helpful to get it running locally.
I want to change this to gitmcp.io. I directly modified it to: https://gitmcp.io/modelcontextprotocol/servers/tree/main/src...
But it doesn't work in Cursor. Even if I point to the index.ts file, it still doesn't work. Can anyone tell me how I should write it?