MCP: Why AI Needs Git Intelligence

Welcome everyone to Gitcon 2025. Today we're diving into a topic that's quickly becoming one of the most important shifts in developer tooling. The rise of MCPs and what happens when AI is given real Git and repo context. I'm joined by someone who needs no introduction into the Git world, Eric Emodio. How you doing, Eric?

>> Great, M. Happy to be here.

>> Thank you. We're happy you're here, too. Um, if you don't know, Eric is the creator of Git Lens and CTO of Git Kraken. He's been at the center of how Git Kraken has approached AI and has played a major role in the direction and evolution of Git Kraken MCP, which is our approach to bringing Git intelligence directly into AI agents and IDEs. During this session, we'll break down how Git Kraken MCP works today, how it removes real Git pain without messing with the fundamentals of Git, and where MCP is headed in as a foundational layer in the future of developer tools. So, let's get into it. Welcome again, Eric. Thanks for joining us today. For the people hearing about MCP for the first time, how do you explain what the Model Context Protocol actually is and why it matters?

>> Yeah, so um you know MCP, yes, it's yet another dev acronym buzzword. Um the the value here in in MCP is not necessarily the this particular protocol. Um but you know some of its value is really that it's become standard and adopted by all the sort of tools you know dev tools and AI players. So that's really what makes it really important. Um but the capabilities is the real magic you know what it provides. And so like MCP is kind of described as USB for AI. So you you know just like you can sort of plug all these different devices into your computer and as long as they talk USB you know your computer gets they access them gets all these new capabilities. Well MCP is kind of the same exact thing for AI. So you can plug into your AI agent uh or your model and you know get these new capabilities that aren't built by you know Anthropic or Open AI or you know they're built by everyone else and to give the capabilities there. So it's, you know, it's really about, you know, providing that that those capabilities and letting, you know, these agents do a lot more than they would be capable of otherwise. Um, and you know, again, whether it's the the the the same acronym, this capability is really important because it really just exposes that. Um and another way of thinking of it is you know like you know as developers we're you know know about CLIs and like you know we can pull down different CLIs to give us access to do different things different tools and so MCP is also can be described as a CLI designed for agents right it gives this these capabilities and wraps it up um and so you can have you know low order tools or higher order tools as well that brings me to another question then like what makes Git intelligence so important for AI agents why can't they just kind guess from the context they already have.

>> Uh I mean so like you know from looking at the file system or just looking at the code right like it tells you sort of what's there that that you know and so like that's the content but you don't really know the intent behind it and so Git like you know not only allows you to know you know hopefully why it's there if you've written good commit messages and you you know how it got there like who did it when did they do it you know what other changes happened around those times. Um so it gives you this additional context to build up this wealth and sort of you know it's also a layered context right you can see how things have changed over time and you know you know problems that existed before got fixed and you know you can easily not repeat history um you know and then just bringing some more of that in of just trying to you know track down where things were introduced you know what point in time that that happened uh you know it becomes really valuable you know it's to give the agent the same powers that you know a senior dev would take if they're coming and trying to investigate a problem, go through history. why is this code the way it is? um you know like just looking at why it is doesn't necessarily unless someone wrote really good comments around it doesn't tell us why it's like that.

>> In your view then what's the biggest kind of Git pain that can be solved, you know, with Git Kraken MCP? What is it kind of helping eliminate right now?

>> Yeah, I mean so right now is an important context, you know, we have a lot of where we want to go with it, you know, right now it it it's not, you know, it's not real, it's not the realization of our vision um but right now, you know, I think the one of the biggest things that it does help uh is to, you know, s sort of gives you know the Git tools a little bit more access to dive through that history with explicit tools, you know, they can figure it out themselves but now we sort of provide examples so they don't know how they don't have to know the right Git incantation to get that that context um and, you know, like one of the biggest pain points that sort of we eliminate at least right now is probably like the creation of PRs, like the whole workflow so like, you know, you creation of that branch, you know, the agent goes and makes its changes can push it, you know, commit, push it and create that PR all, you know, sort of by itself. Um, you know, and by itself is with prompts and and other things of like, you know, making sure you want those things to happen. Um, but, you know, th those are probably some of the biggest things we solve right now. back up a little bit of like what what we were trying to do when we set out to you know like create the MCP because that'll give you a bit of of context of how we can piece them together. Um and so like, you know, one of the goals, you know, out of the outset were to a put, you know, better accuracy, you know, and safety on on the Git operations. So like, you know, letting the the the model know how to, you know, call specific things and not and call it in very specific ways and then if there's going to be destructive operations or stuff that you know has a chance of losing data, changing things that there is, it's safe, right? Like well, we'll prompt you to make sure so that like you're not just giving it sort of full access to Git where it can do lots of damaging things if it if it wants to or gets confused and runs the wrong command. And then the other one was this aggregated context. So like, you know, through, you know, the Git Kraken ecosystem, right, we have connections to, you know, you set up different connections to all your different integrations, whether that's to, you know, Jira, to GitHub, to Bitbucket, to Linear, like, you know, we have all these different connections to access that. So then we can sort of aggregate that. So you don't need to install 12 different MCPs to get access to that data. you can just say okay, you know, for this repository, what is it connected to um but like, so the aggregated context and then the one that is nearer and dearer to me is like leveraging work trees. Um, you know, we do have tools that do that, but the agents, we haven't done enough yet to allow the agents to really understand what a work tree is and how to work with it because they still get confused on, oh, if you created a new work tree, it still tries to like write stuff to the original folder, it doesn't realize you've switched into a new context and so like we're still teaching it a little bit more about that. Um, but that is one area that we're we're working on much more deeply. Um, but yeah, that's one thing we, you know, that's the ultimate thing is be able to like start from, you know, what issues are most critical for me to solve right now. Grab that issue, you know, the agent says, okay, you know, here's your list. Okay, yeah, pick issue one. Let's go do that. Create a new branch, or, you know, ideally create a work tree on that. Go and solve that problem. Go and code it up. Go and break that down, you know, into a series of commits that make logical sense and have a progression, push it up, you know, push up the branch and open the PR, right? Like that would be the ultimate workflow. Um, now, you know, like that fully autonomous is, you know, yes, it could happen, but it's extremely rare. Um, but be able to have that workflow. So like as you know, like you may say the agent start work, it goes and creates the work tree, creates the branch, creates that whole thing, starts doing the first set of coding, and then you're going to be continue iterating with that agent for a while on, you know, solving the problem that sort of thing, and you've got the problem solved. Then it's like, okay, time to commit. Well, instead of just grabbing the entire diff as one commit, let's break it up into individual commits that make sense. And so, like leveraging the agent to do that. Um, and then go through the push and and create the PR. Um, and you you may actually even want to get to the point of, well, you know, logically this should be many commits, but it may also should be many PRs. Um, because like this set of changes should be one PR and another one stacked on top of that. Um, so we're exploring that. I mean, we've introduced Commit Composer into our UI tools. We'll be bringing that to MCP in the in the future as well.

>> And for those that don't know, could you elaborate a little bit more on the Commit Composer tool? You know, what what it is?

>> Is you can just, you know, open up Commit Composer to either, you know, a set of working in progress changes, or a set of work in progress changes in some commits, or just, you know, like, hey, I've been working on this branch for a while. I've made a whole bunch of commits and I just want them to be reorganized. And so, you know, right now you can open that that UI call to, you know, there's a button to say, you know, recompose with AI. You can provide a specific prompt um how you want this, you know, this particular instance to be reorganized if there's something special and then, you know, we'll go through and sort of suggest a new series of commits to break that into and you can go and explore the the diffs of each um change uh and, you know, this is also, you know, you know, there was actually a question from, you know, users of, you know, how do we make sure that this is verifiable, right? Like how how do we make sure that the AI didn't lose changes? Well, you know, basically like we know exactly the diff that it has to be at the end, right? And so we can just say that okay, all all the changes in here, you know, as after the AI reorganizes it, we can validate that the ultimate diff after all of that is identical to what it was before. So that you know it's statically verifiable that you had the same as you did, you know, had before, but they're just in different structure of order of getting there. Um, so that that allows us to, you know, make sure that not not a single change was lost in the process. Um, so yeah, and it we'll be bringing that same sort of thing to MCP in the future as well. Um, that's that's crazy.

>> So I've used Commit Composer a couple times on some of my projects and stuff and it's very impressive. I can't even imagine giving that to MCP and letting it run with it. Um, like but I think I the question on a lot of developers minds too is like when we're using AI tools, when we're using things inside of IDEs, right? Like I I myself even worry about this too, but like a lot of developers worry about like AI touching like the Git history. And how do we think about like kind of safety guardrails and things when we were designing MCP at Git Kraken?

>> Yeah, I mean, that's one thing where, you know, we are looking at um ways of, you know, I mean, that there's not touching the history is one thing. I mean, you you know, not letting it commit without your approval is is an option. Um, but, you know, you're going to limit the capabilities of that agent. Now, you may want to let it go wild on committing on your local, but not what you push. And so you there you know, could be a serious gate on being able to push that. So that way you could always redo your local, you know, squash things or or use Commit Composer to recompose it in a different way um to to restructure it. Um, because we're we're really looking at, you know, some, you know, multiple different facets of like, you know, how do we uh not only snapshot things during the flow of the agent so that you can easily go back um but like have more commits there so that it it is easy to replay to a particular point. Um and then be able to like, you know, at the end, just squash them, recompose them into a new, you know, meaningful set of changes, but while you're in the fray of exploration, we snapshot a lot. So yeah, you may create a whole lot of noisy commits, but then at the end, once you're ready, once, you know, the code has gotten to the point of things work. Okay, let's just, you know, recompose it all and, you know, you as the user don't have to go through in this complicated rebase, right? It can just click one recompose and, you know, redo it all all together for you. Um, we're also looking at uh, you know, one thing we want to get in is on that safety aspect is, you know, when when a when you know, a particular operation is going to be run that has a destructive nature, and you know, we we currently will prompt and not let that happen until you agree. Um, but even more than that, you may want to look at taking certain snapshots so that even if you did agree or you like ultimately set the agent into YOLO mode, you can still find a way of backing out. Like these are some of the things that have happened. I mean, and a lot of things in Git are already, you know, you can back them out just by digging through the ref log, but is there a way of making that more accessible so you can sort of see the the changes that have happened there so that you can not lose changes? Now also like lots of changes can happen to your working directory and those aren't, you know, you know, saved by Git. So, you know, like will we stash things or take snapshots through that to make sure that you don't lose changes through that process. Um, so those are things we're also exploring. Um, zooming out like into the the broader dev ecosystem. Um, there's a lot going on with like IDEs, agents. I know Google had just dropped a new um IDE which was Anti-Gravity. We've got Cursor. So, like where do you think like MCP adoption is is right now across tools and IDEs? Is it early? Is it mid? Is it accelerating? Um, kind of what's what's your take on that?

>> Yeah, I mean, you know, MCP is kind of it's been crazy the the the growth um file, you know, the the growth trajectory there. It's like like I've never seen anything get, you know, proposed as a standard and adopted so widely in such a narrow band of time. Um, you know, like it was it it's kind of crazy and it but it's it's awesome that it isn't it is this open standard, open protocol that, you know, all the players have adopted, right? Every major um, you know, AI company has adopted MCP to support in their models for for, you know, tool use um and then, you know, all the IDEs, the CLI tools have almost all adopted MCP as well. Now, there are varying degrees of how much of the MCP spec they fully implement and that does create certain challenges um like there are more advanced bits of MCP and it is it is a continuously evolving spec. There's, you know, a new proposed spec came out in November and, you know, we'll see how, you know, that how quickly that gets adopted um but one thing is like this this protocol, this this, you know, spec is a core way of how they, you know, expand what these tools can do. So in a lot of ways it is in everyone's best interest to adopt the latest version of the standards as quickly as possible because otherwise they get left behind on, you know, what their tool can't do and another tool can. Um, so we are getting sort of like that net na that natural push for adoption. Um, but it is, you know, it's been great to see, you know, you know, I mean, there's an explosion of like everything's in MCP [laughter] um and that, you know, like you'll kind of get some consolidation. I mean, we're doing some level of consolidation for for the things that we find valuable that are accessible. Like you don't, you know, it depends on your workflows, but like, you know, if you're really like at, you know, from the developer point of view, uh, if you're working with Jira and Linear and these sort of things, you may not need those other MCPs unless you're doing richer things to dive more deeply into, you know, the capabilities of their platform. But if you're mainly just looking at, you know, dealing with issues, solving them, that sort of stuff, you know, we're going we're trying to cover the basis there so that, you know, the agents can follow those more easily. They don't need to know if they're talking to Jira or Linear or anything. It's about getting an issue to work on, getting context around it, solving it, closing it, that sort of stuff.

>> Right. Right. That that kind of goes back to your um your analogy of the USBs, right? We have USB A, USB C, like all kinds of variations of it now. Um, but it started with that central USB, you know, port to begin with. So.

>> Moving on, you know, the future kind of of developer tools in general, you know, if you look 12 to 24 months ahead, you know, what new developer workflows become possible because of MCP and even Git Kraken MCP?

>> Yeah, I mean, I think you you sort of you get this you get an additional level of like this autonomous nature, right? These more more agentic workflows for um, you know, so things that you can clean up a, you know, you go and run and, you know, go and clean up all your stale branches after you've pushed something, you have, you know, have things or, you know, make sure that these changes, you know, didn't break the build and, you know, auto-heal CI, or, you know, look at things that have come in from, you know, like Sentry or your, you know, error monitoring or performance monitoring, right? You know, Git, so you can have all tools that can provide ways of it going and reading that data and then going to the codebase and looking at, okay, well, this is the snapshot in history before, you know, this is everything that changed since that change went out, we know that this bug got introduced in that. Go look at the code and then the agents can go and try to suggest changes autonomously on how to fix and resolve that issue and, you know, can just go and like, oh, open a PR that this should fix the thing that we're seeing in production without any human interaction at the early stage and then you're just at the view that, you know, you can just naturally fix that or, you know, per performance, uh, you know, things are introduced as part of that deployment, right? Like it can go and look at the snapshot of where those things. So it's going to use tools to go and get like, you know, where the history was for the deployment, uh, you know, so it may look at GitHub Actions stuff and then go and pro get information from your APM and, you know, so it's using leveraging these tools to piece together to do more autonomous workflows or they could be run locally on your machine. Um, you know, there's others, you know, I mean, those are sort of like, you know, things will sort of they're possible today, but you can, you know, you got to build a lot of the the infrastructure, go make that that happen. Um, you know, I think where I hope MCP sort of evolves into too is to sort of expand into more of these agentic workflows in itself. So like a single tool can do more, right? Like it like today a single tool has sort of a limited context of what it can do um and what is provided and, you know, it can't run for, you know, there's, you know, I mean, there are some things for long-running tools, but it it's not fully adopted and and be able to do that, but like, you know, like I want I would like to see, you know, MCP sort of expand into like the ATA, which is another protocol that was around the same time that is more about the higher order of like how do agents talk to one another, you know, and so MCP was more lower level. MCPs continually come up and I just wanted to see it, you know, absorb um that to, you know, expand out so it's like, you know, you could have your low-level tools, but you can have your higher order tools that, you know, do more things and bring also allow tools to um interface back with the chat. Technically, that's possible with some of the things in MCP, though most a lot of the MCP tools, even like Cloud Code itself, doesn't implement some of the MCP spec that allows that to happen, but be able to like, you know, I have a tool and I'm going and collecting, you know, certain data, you know, because you asked me to do a certain operation and I I've got the data and I want to ask the model to do a little other work before I and then I need to do more work on that and then I return like, cuz the tool that was, you know, something, you know, richer, let's just say sake of argument, say like it was a Commit Composer tool, right? Like, you know, go and compose my commits and that sort of thing. So, you know, we get a tool to, you know, we that goes and we go and get the diffs. That's fine. Um, but then it's like, okay, well, we've broken it out. This is the way we should, you know, break things out. You know, we want to call the model to go and generate commit messages for each one of those things or how to reorganize it. But we can't really call back into the model easily to do that part of the operation and then, you know, but once we have that, then we can sort of go out. So, those are some of the challenges we have for like bringing Commit Composer to MCP. That's why it doesn't exist already. Um, now there are ways of kind of getting that to work and we're exploring that. Um, but I hope that it grows up more there. And then the other one that I really hope MCP expands into is like doing richer UIs, you know. So like, you know, I'm going to provide you this data, that's fine for the context, but I want to provide a rendering for that data. Like, you know, so like you called out this thing and I I can render this beautiful chart, or I can render a graph of the commits, or, you know, like, you know, much more rich UIs, or I want to ask certain questions back to you rather than just simple yes nos, like I can provide a a richer dialogue that you don't have to answer a series of questions, you can go and customize sort of the responses. And so there's there's um projects like MCP UI that are exploring that and I'd love to see those sort of things get adopted [snorts]. And well, not you won't see that anytime soon inside the chat panel, but in GitLens, we are looking at connecting the two, right? Like you can go in your IDE, go and chat through, and then our MCP can directly communicate with GitLens and then show data and provide, you know, like you want to see a visualization of the file history, we can load up the the the history view, you know, if there's, you know, some search you were trying to find on, you know, search, excuse me, particular items in the in, you know, certain commits, we can run that search on the graph and show you that visually. Um, so we will be tying that, it won't be integrated into the chat panel because we don't have any way of injecting that um, but those are some things that we will still be providing, you know, with the experience if you have GitLens installed in the MCP. Um.

>> Wow, there's a lot of exciting things coming down the pipeline with with Git Kraken MCP and MCP in general. Um, so [clears throat] along those lines, you know, if you could give developers one mindset shift about AI and Git as a whole, what would it what would it be?

>> Um, I think it's really like the agentic future. As much as I don't like the word agentic, I have to, you know, h have to concede at this point. It's here. [laughter] Um, you know, you know, I mean, like it it it's not it's not going anywhere. And you like other tools that have come up in the, you know, history of development, right? You know, those who explore and experiment will really find out how to leverage them to, you know, bend them to their will to improve their own workflows. So, I would definitely, you know, you know, these these are not magic um but, you know, they are they still do provide very valuable things. So like explore, you know, experiment, figure that out and, you know, the other core thing is like, you know, the playbook here, the things, the workflows of the future are not written, right? We're exploring them, we're we're building them now. So the more that you explore, the more you experiment, and then provide that feedback back to us, we can build, you know, and I don't mean us just as Git Kraken, I mean us in general building dev tools and and all of these things, like the more that we can sort of address the issues, you know, improve the experiences to get, you know, to build out those workflows of tomorrow. So, yeah, dive in and play. Yeah, I mean, def definitely play, you know, definitely play with like leveraging the agents and yeah, try plugging in different MCP servers to do, you know, provide different value and and and see which ones, you know, leverage there. Uh, you know, see which ones resonate and, you know, provide value of what you're looking for because there's a lot of really interesting MCP tools out there. Um, there's also just an explosion of MCP tools, so it is a little bit hard to like piece together, but um, yeah, definitely, you know, play around and experiment.

>> Wow. Well, Eric, thanks for sharing the story and vision behind Git Kraken MCP. Um, this is obviously clearly just the beginning of MCP and how it's going to reshape the relationship between AI and developer tooling in the broader spectrum. So, thank you very much. And if you guys are interested, make sure you check out GitLens. It's in a lot of IDEs, right, Eric? It's in Cursor. It's in um all the IDEs basically.

>> All the VS Code forks. Uh, yeah, so all the AI IDEs and and, you know, even like the newest entry from Google and, you know, Anti-Gravity were there. So.

>> Yeah, bundled right with GitLens. So.

>> MCP is is auto-installed and in the future in the, you know, nearest future, you'll see it even light up more even more between the MCP and and GitLens directly. Um, so yeah.

>> And, you know, for people actually playing with our MCP and and, you know, GitLens in that respect, just, you know, feedback is invaluable. So, you know, like what what workflows are you seeing success with? What workflows are you not seeing success with? Like what's failing or what do you wish you were able to do that, you know, you you can't get to happen? Like to us, that that that feedback is highly, highly valuable.

>> Right. We heard it here first, everybody. Um, go try MCP. Uh, give us the feedback that you got and let us know what you want to see next. So, all right, Eric, thanks so much for your time. Thanks everybody for watching.

>> Thanks, Gitcon. Thanks, Blaze.