Ryan chats with Karen Ng, EVP of Product at HubSpot, to chat about Model Context Protocol (MCP) and how they implemented it for their server for their CRM product. They chat the emergence of this as the standard for agentic interactions, the challenges of implementing the server and integrating it with their ecosystem, and how agentic AI has affected work at Hubspot.
Episode notes:
Hubspot is a customer-relationship management (CRM) platform that aims to help businesses grow.
MCP is an open-source protocol for connecting AI agents to external systems, originally developers at Anthropic.
Connect with Karen on LinkedIn.
Virtual hi-five to Rob Truxal for asking What is the purpose of "pip install --user ..."? and garnering themselves a Stellar Question badge.
TRANSCRIPT
(STACK OVERFLOW INTRO MUSIC)
Ryan Donovan: Hello everyone, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I'm Ryan Donovan, your host. And today we're going to be talking with somebody who's built a remote MCP server. I know everybody's talking about MCP as the new hotness. And now we have somebody who knows more about it. So welcome Karen Ng, who is EVP of product at HubSpot. So welcome to the show, Karen.
Karen Ng: Ryan, thanks for having me.
Ryan: My pleasure. So, top of the show, we like to find out a little bit about our guest. How did you get into software and technology?
Karen: I grew up in Silicon Valley, and even just as a little kid, kind of watched technology innovations. I worked in the back of Lawrence Livermore Lab when I was a TA for a programming area, and so that kind of got me into technology and what can be done with tech. So, it's followed my career the whole time.
Ryan: Nice. Today we're talking about an emerging tech. Talking about the Model Context Protocol, which lets agents talk to SaaS products and other things on the internet. Tell us a little bit about why you all at HubSpot decided that MCP server was something you wanted to build.
Karen: My background is in programming languages. My first job out of college was actually on the Csharp programming team, before Microsoft had actually even really released the language. And at that time, in programming languages, at some point, there are standards that you want to interoperate and work across things. And so, for MCP, for me, we just built this HubSpot connector to deep research in ChatGPT. The way... I kind of run the developer and platform teams here, and I kind of think of it as, like, when do standards become standards? And so, I was watching pretty closely. In the cloud era, there were REST APIs that rose because you started having things like microservices that needed to talk to each other. And in the AI world, nothing had quite yet emerged. MCP has actually been around. But you started seeing slower adoption. In the AI era, we need a protocol for data to pass through each other that's more around agents and context and tools. So. I was watching MCP pretty heavily, and there was a date that was a turning point. And it was the turning point for when OpenAI adopted MCP. And then you can see in the span of 48 hours, you saw all the big players Microsoft, Google, OpenAI, all adopt it. And so for us at HubSpot, you know, we're a CRM team. That meant teams, let's go. Let's go try prototype, local or remote version. But let's understand the protocol well and how we would adapt our existing APIs in surface in this time. So, that's when it became a bigger thing for us here.
Ryan: It is interesting as the emergence of a standard. I'd been talking to folks about the sort of need for standards. And then had a conversation recently comparing the MCP to the sort of early web standards. Do you feel like MCP is this one that emerged at Anthropic and then got picked up by everybody? Do you think it's the standard that's going to be kept up? Or do you think this is an iterative process?
Karen: I have conviction that it actually will land. So, it's an emerging protocol. So there are things, even as we build our remote MCP server, that are not fully there. Like, do you stand up a remote MC server, is it stateless? How do you build it? One of the big pieces that was missing in MCP, kind of just natively, is like, how to think about auth. Or OAuth, or auth protocols. How to think about scopes. I think it has a lot of early stuff around how you think about tools and contacts and messages, where you can teach AI or agents things, but it's still missing kind of a full, even agent-to-agent protocol. So, I have high conviction that it will be a player in the AI era, but it needs to evolve to a bunch of different use cases. It needs to be evolved to agents. And even how we're thinking about it, we take clues on the current MCP spec, but it is very much still evolving. We actually have two remote MCP servers and then one local server in play. They are slightly different versions. One exposes our core raw APIs, our CRM search API with contacts, companies, and deals. It's built on top of our existing REST APIs. The other one that we used for the connector is a MCP spec that's specific to OpenAI, that has a search and fetch component.
Ryan: Before this, I was just reading over the blog that you all put out talking about this, and one of the interesting things I saw in there was that some folks already have commoditized MCP server products like Cloudflare, you mentioned. What led you to develop your own?
Karen: Yeah, we definitely looked at that. One, I'll put the connector, is, we built this connector with OpenAI in four weeks. Or in less than four weeks. And, to move kind of AI speed, you know, we're the first CRM connector to do this. So we were looking at, how can we deliver core customer value quickly? 75% of our customers use ChatGPT today. How can we think about the use cases that need to be there? How can we protect security and auth, and then how can we move at this speed? So, we looked at a whole bunch of different evaluations, build and buy, and we decided that the things that we needed, it would have been faster and easier to build. Because we needed it to work with our existing enterprise RPC system. So when we looked at it, we said, there are a couple of different options. We can do something off the shelf. We can get vendor approvals, everything it needs, does it work with everything that we need? Or we can build. And basically we could extend the Java MCP SDK to do things like HTTP streaming protocols. And then we said, okay, well, if that's open source, do we contribute back or do we write it ourselves? And so we decided to take that and update it ourselves. And then it worked really well with our existing RPC systems. And so that was another factor for us. The last factor for us is, the connectors need to honor auth. Like I was mentioning, MCP doesn't really have all that built in. So, what would be the fastest way for us to ensure that you can only see HubSpot CRM data that you're allowed to? We decided to use the OAuth protocol for that. And of course there's 2021 private keys. So we evaluated all of that. The current MCP spec that Anthropic has out supports OAuth 2.1. The ChatGPT one, which was a new spec protocol that had not been released yet, could support OAuth 2.0. We supported 2.0. So luckily it all kind of worked out, but that was another factor. We had to think about the auth capabilities we needed.
Ryan: As somebody who has read over the auth specs in a previous role, it can get pretty complicated. There's a lot of extra things in there. A lot of optional stuff. And implementing the spec isn't always as straightforward. Did you run into any issues in sort of, like, implementing it and having it work well with all the pieces?
Karen: 100%. You know, we adopted quickly. So, for this particular connector, we were working against a spec that uses MCP protocol, but it has the search functionality that was not yet released. You know, there were a number of things that we had to try very quickly. We actually ended up using things like Claude Code to generate all of the pieces we needed in the first spec we had from that spec. That was actually how we accelerated building those. Like, the templated versions. We learned a ton from, how were we going to enforce user permissions at scale? How would we take our existing APIs, which were based off the CRM search API, and then kind of had them in the right format? But we evolved a lot. And we had debates with the OpenAI engineering team of like, even Snake case or Camel case, it's not consistent across all of the MCP server implementations.
Ryan: If you're still fixing casing, that's real early stage.
Karen: Yeah, that's a funny tidbit, on a part of it. Part of it was like, a casing debate we ended up having.
Ryan: Yeah. I don't think I've talked to many folks actually implementing it, but I've heard, MCP, that it's not that big of an implementation. Or, it's a little iffy. What's the actual effort to make not only an MCP implementation, but a remote server?
Karen: The MCP implementation is pretty trivial. So, I will say that I was mentioning kind of, when we decided to go MCP and just to put more weight behind it, we had a PM on the team that created one of the first prototypes of MCP on a local server. So, the spec is like, you know, pretty easy to follow. We had a bunch of prototypes and POCs. We have over 100 HubSpot MCP, like, made by other people that came online. And so, from the implementation of MCP, that part was simpler. The remote part was a little trickier. Because you do need to kind of think through, is it going to be a microservice? What technologies are you using? Is it stateless? Is it not? We are kind of a Java-based area. And so, like, the Java MCP SDK again is also emerging and evolving. Does it actually support all the protocols that we need it to? So, the remote one took us a bit more work. It was pretty quick to get into the MCP format.
Ryan: That's interesting. Because at that point you're just building a server, right? It's just a sort of standard piece of network technology.
Karen: Yeah. You know, to your same question. Do you build buy? Is it off the shelf? What do you need? What auth does it have?
Ryan: Yeah. And how easily does this fit within your ecosystem? Because I know a lot of folks who end up buying may have to do a lot of customization, right?
Karen: That was the trickiest piece for us, and one of the reasons why we decided to build. It needs to work with our existing stack. You know, if you have an RPC system or however you stand it up, if it's homegrown or using something else, to move at that speed and to make sure you have the right quality for it, we just needed to look at a bunch of different things.
Ryan: MCP itself, I believe, is open source at this point? Is that right?
Karen: Mhm.
Ryan: Yeah, the Java version is open source. How much are you feeding your learnings back into the open source pieces?
Karen: We're feeding it back into the Java MCP SDK. And then we have partnerships with, like, Anthropic and OpenAI. And so one of the reasons we published the engineering blog was just to share our learnings. We're probably one of the first to do it in such a large scale, and a remote MCP server. And, you know, we have a ton of customers currently getting value and using that connector right now.
Ryan: Tell me a little bit about how this remote server actually plugs into HubSpot as a whole.
Karen: So I mentioned already that we extended the Java MCP SDK. One of the things that we needed to support was a streamable HTTP transport. So it's exactly how you kind of thought about it, as a web service. And then we said, how are we going to do this inside HubSpot's standard Java stack? We used something that was called, like, a Dropwizard microservice. That's how we ended up implementing it. We did it first as a proof of concept. But what we needed to think about was, how do you manage this at scale? So are we going to have long-ranging server-event connections, which were a little bit harder to manage at scale? It would also cause us to think about, depending on the traffic that came to it. Or should we do this for short-lived kind of, like, HTTP requests? That's the way that our stack is built today, so that's the route that we went. We then built kind of an MCP gateway. It auto-discovers tools across those services. And then we needed to add the OAuth scope, and then the user permissions that were mapped to our HubSpot seat and tiers. And so that part we needed to connect. To do that, we also have a very strong microservices architecture currently in the HubSpot stack, so we wanted to work like that. But we essentially created an annotation system for MCP tools. So it was easier to describe these RPC Java methods. And that, we used Claude Code to generate them. That saved a lot of time. That's how we ended up plugging it into the existing HubSpot stack itself. We needed to maintain the scale that we needed. We needed to think about security and to work with the stack. And then we also knew that the customer experience we wanted should feel very seamless from a customer consumer. Today, if you use a MCP server to any of these desktop clients - our local server, for instance - you need to usually do NPM package. You have to install it to your local desktop, and then you have to teach the desktop client, like, how to connect. And we were offering this connector for... ChatGPT will say it has 500 million weekly customers. Those customers aren't necessarily developers or technical, and we wanted it to connect instantly. Which is why we built it that way.
Ryan: It's a product that has developers building on it, but not everybody who uses it is a developer.
Karen: Yeah, so that actually was really important for me. Just as, like, coming from product, we had both what we technically needed to build and how to stand it up, and then what requirements for the user experience would be.
Ryan: You all already had APIs available for customers, and this sort of exposes it to agents. Have you seen any issues with the scaling? Have you had to adjust the load that you're anticipating?
Karen: We haven't. We built it with these kind of short HTTP calls. It's stateless. So the first version is read only, and then it's also stateless. So because of that, we don't have any load or server issues. There's these very short-lived requests. So we haven't seen any issues with that as well.
Ryan: I would think that the right portion of that might be a little dangerous, especially early in with AI agents.
Karen: We expect a world where you probably get to write for the kinds of things that you can do. But then that matters a lot. Like, do you have permissions to write? Even if you do, do you know what you're doing? Changing the CRM data. You know, there's kind of a magic to it. Like we know, for instance, that CRM data is not always in the best shape. And if we had our MCP tools or our agents running over it, it could create data in the right shape and in good shape. But, that is something that we're being really thoughtful about when and how we do, because it's easier with read only.
Ryan: You said you all are using agent tools within HubSpot to both create some of these MCP servers. So, how's your sort of internal adoption of agents been going?
Karen: AI fluency and enablement of these tools is just really important to HubSpot, so we kind of expect it. This is how engineering and product teams and design teams will be working, actually, even in go to market. So we've started on this journey a year and a half, almost two years ago. And so, we definitely have a culture of using a lot of these tools. Even within our engineering. It's probably used... Adoption is, I don't know the exact number, but I think it's upwards in the 70-80% of adoption.
Ryan: Do you yourself use AI tools or AI agents?
Karen: I do. You know, it's interesting to see how product has been changing as well. Like, it's so fast to prototype. I use lovable and V0 all the time. There's a lot of different tools that I'll use myself. My background is in programming languages. So for me, it's almost a means to very quickly prototype an idea. And sometimes that's code and sometimes it's visual. So I'm watching the product teams change as well, in terms of how quickly we can prototype things.
Ryan: With that, do you think there'll be a baseline fluency in programming tools necessary? Or will these agents just be able to handle everything?
Karen: What I see so far is it's much closer to the Iron Man suits in Iron Man than it is in like totally autonomous type of, here's my mind and how you do it. So I definitely see still a human in the loop, in that you're still, like, a domain expert on like, what you want it to do. And then the creativity aspect of it. But I'm also watching these tools evolve so quickly. You know, six months ago you really needed some understanding of, like, code back end, and where's the data stored? How is it, you know, like, in this MCP remote protocol, you need to understand the protocol, and how it would actually transfer data. And I'm watching that, it's amazing how quickly things are evolving. And the new wave of code agents as well. Like, it becomes much more like a pair programmer. Like, you can do a set of things autonomously. I still find, though, that once you hit a bunch of bugs or, like, your code stops working, you have to revert or it's still, like, a pain. So it's much easier to do micro changes and control those than one big shot.
Ryan: I wonder how much vibe coding will sort of supplant the actual programmer. Because you still need to understand it.
Karen: Yeah. I think it will supercharge programmers. And there's probably, like, a set of things getting from a spec that was barely developed to what the templated versions are. Like, it's just so much faster, but you have to kind of know what you're doing and ask for what you needed to get generated.
Ryan: So with your MCP server, have you seen any cool implementations? Like, I've seen some agent systems for marketing or other things where it's like, I want to do this thing, and it's like, well, here you go. I've done all the research for you. Here's the script that you need.
Karen: I do see that. So I see MCP kind of in two realms, and that's how we see it here too. We have our MCP server side, which is, okay, if you're trying to do, like, a connector like this, that MCP server needs to serve up the right information. And in this particular one it was in search and fetch, which means, of the CRM objects you have, do you know how to query it? Do you know how to return something? So an example being, like, we've seen a ton of customers be able to say, hey, over the last 90 days, of all the new contacts and companies that you've seen, give me an analysis of, like, which areas they're part of, and then tell me which ones are the highest converting. For that, it needs to know how to operate on top of your APIs or your data. And so that's the remote server piece. The other piece though, is MCP clients. And that becomes really interesting. Where, we have Breeze Assistant today, those are just AI tools. But when you ask Breeze Assistant to say, okay, now I want to run a nurture campaign, and please save it back to Asana for me, to me, that's the tool question. Which is, we think of MCP clients as, that's a discovery problem. Which is, do you have verified and good MCP servers? Right now, MCP is in this state of, there are a million MCP servers. And it's sometimes hard to know which ones are verified, which ones are great, which ones think in terms of security. And so our client work is doing discovery and registry service. And then we will call out and teach tools. So, our agents internally use MCP clients, and think of them as tools that extend what you can do.
Ryan: When I first started hearing about agent and tool use, I sort of jokingly was like, oh no, every SaaS company is going to be an API now. I wonder how you feel about that statement and how you're planning for agent-first interaction?
Karen: I don't think they'll all be API tools. I've always believed, like in cloud, the rise of RESTful or GraphQL. They were programmatic ways that you would access data. And the rise of microservices happened because you can have clear dependencies between things. The same way I felt like, in cloud or enterprise SaaS operations, like, those were just ways that you kind of almost communicate. Like, if we lived in a world of robots and this was the language they speak, APIs were the language they used to speak. And in the AI world, MCP is the way you speak. Data APIs and MCP are closely coupled. But I'm also seeing the opportunity to say, MCP gives us a format that lets you teach tools how to find things in context, and that can be exposed via APIs. But you'll have other, two other dimensions. We think a lot about context. And so context is not just a raw object API. It knows things. Observations and things about things. You can expose that in API and then expose it through MCP, but that layer can be thoughtfully done as agent protocol or MCP. And then the other layer I think about is, the operator use case, or when you don't have an API. Being able to point it to a set of desktop or browsers, now we can see. So that's the other element that's happening, which is a little different than API, which is, you can now bring a perception layer into agents. That, turns out, if you didn't have an API exposed yet, I can see it on the screen.
Ryan: That's an interesting use case for front ends, but do you think that there'll still be a case for the human use of the HubSpot front end, or is there going to be an agent front end that everybody goes through?
Karen: I definitely think there will be. So, I think it will evolve. I think there's an evolution in how people take action. But the simplicity of how well something is designed based on your use case is still going to be there. So when you put, even things like a connector in. Or let's say it's just an agent. You might interact with an agent, like, somebody on your team. And I might mention you, or I might ask you a set of questions, or I might say, hey, please, Ryan, do this set of tasks for me. Like, here's your job. I think you're going to interact with that pattern a lot more like humans interact with things. So I think there's still going to be a world where you'll want an actual tool or, like, the HubSpot front end interface. There's more things that you can do that might be like, here's my landing spot, here's my homepage, here's the workspace I operate. Here are all the curated workflows that are really important to me. I think that will still exist.
Ryan: I think you mentioned agent-to-agent protocol. Google has an agent-to-agent protocol. Are you thinking about any of that? Are you building your own agents?
Karen: We are definitely building our own agents. But we believe that we're applying AI in a bunch of growth scenarios. And so, I'm also very interested in A to A right now. So, same kind of thing with A to A. When it first came out as a Google protocol, like, is it going to become a standard? There was a little bit of a period where it wasn't clear. But you're starting to see more people be interested in it. MCP doesn't solve all of that yet. So how the two work together, there's nothing that has fully solved, like, an agent-to-agent protocol yet.
Ryan: Well, I'll check this afterwards, but I think Google just donated A to A to the Linux Foundation, right?
Karen: I worked at Google for four years on Android and, like, same thing. When it becomes an open standard. And in an open source capacity, like, you'll see more people adopt it. Because the protocol benefits all of us.
Ryan: It's been also fascinating in the last, I don't know, ten, 15 years, just to see how everybody flipped on open source. Like, there was a lot of protectionist stuff, and then now everybody's like, no, no, open source is safer. How do you at HubSpot think about open source?
Karen: Yeah, we like open source a lot. Open source causes advancements to move faster because you have more people thinking and building. The same way, for this, we probably wouldn't have been able to build this connector in four weeks if there wasn't in a Java MCP SDK, and one that we could contribute back into.
Ryan: What are you all thinking about, you have the MCP server, remote server now, what's the future?
Karen: The remote MCP server I mentioned, we have two. It allows us to kind of be custom, if we need, for the connectors that are in play. But those are, to me, consumer use cases. And MCP was an implementation to kind of get there in the way that we wanted. We have another MCP server, a local one and a remote one that's coming. That one will unlock just a number of scenarios. This is the beginning of, we're seeing with MCP. We have folks even in product management here that run, like, a local MCP server, and like, it's just wild to see what people do. We use it to generate test data and demo data by giving it the right shape of deals and customers in the industries that we need. The PMs will do that. We have an MCP server connected to Claude Code. Connecting that MCP server to Claude Code allows you to actually just generate... That's how we generate the schemas for this one. So we're watching MCPs change programming. We're seeing MCP change the tools that you can find. So, it'll be kind of a baseline where agents and Breeze Assistant for us. Yeah, of course it can do things like save back to the project management tool that you have. It's assumed that agents will be able to interop and to work with other tools, and I think that will be one thing that you'll see here. But it's amazing to see, just like, the day-to-day stuff people are doing with our current MCP server.
Ryan: It's fascinating. Wild times right?
Karen: Yeah. Super fun. It's really exciting what we're doing with MCP. For us, it was meeting customers where they are. So, you know, that's the reason why we are the first CRM with an MCP server, and the first CRM with a connector to open AI. We're going where users want to go. And at the end of the day, we want to provide value for them. So, it's just a number of things people can do now.
Ryan: It's that time of the show again, ladies and gentlemen, where we shout out somebody who came on to Stack Overflow, dropped a little knowledge, shared some curiosity, and earned a badge. So today we are shouting out a Stellar Question badge winner! Congrats to Rob Truxal for asking, what is the purpose of pip install --user? If you were curious, we have an answer for you in the show notes. I am Ryan Donovan. I edit the blog and host the podcast here at StackOverflow. If you have comments, concerns, ratings, reviews, send them to me, at podcast@stackoverflow.com. And if you want to reach out to me, you can find me on LinkedIn.
Karen: I'm Karen Ng, I'm the head of product at HubSpot, and if you want to find me, you can find me on LinkedIn as well.
Ryan: Thank you for listening, everyone, and we'll talk to you next time.
(STACK OVERFLOW OUTRO MUSIC)