Invest with AI
00:08:20 · Thomas Li, Khe Hy
So what we saw is essentially now almost our entire database is getting used like every single quarter, because there's so many agents from our customers that deployed on top of it. And we saw a remarkable shift in the volume of the documents we provide, the data we provide. I think year on year, we've seen data consumption grow over 100 times. [00:08:40] S2: So that 5%, has that changed? [00:08:44] S0: Yeah, it's almost 100% now. Wow. Whether Yeah. Or not, an agent will consume all the information, right? But after the agent consumes the information, whether or not they surface all the information to their end user, I don't know, right? Because that's their internal system. Chances are they're not, right, but the agent is processing all of that information. It's almost like if your analyst went to read the 10 Q cover to cover, they might not give you everything in the 10 Q, because a lot of it is irrelevant, but they would have read it cover to cover, and it'll give you the top three most important things. [00:09:21] S2: And naively, was that growth from kind of the easier agentic services like CoWork, Cloud Code, Codecs? Or did something else happen?
00:09:21 · Khe Hy, Thomas Li, Brett Caughran
[00:09:21] S2: And naively, was that growth from kind of the easier agentic services like CoWork, Cloud Code, Codecs? Or did something else happen? [00:09:32] S0: I think the most the biggest change and unlock for firms is going from using chat as just a chatbot to connecting MCPs with it. So that's like the first lift. It's a simple lift, which is sort of why the adoption rates have been so high. And we just saw explosions there. When we dig into how users use us, you also have these like very spiky users, right? We have users using, you know, thousands of times more data than our average user is. And that almost always is because they're in a coding agent. [00:10:09] S1: Can frame, Thomas, a little bit of just the path we've been on of abstraction into the MCP? And even eighteen months ago, people were sort of building data lakes and it was just like a much more complicated talking about OCR and PDFs. Was much more complicated situation to get fundamental data into a chatbot. Can you just give us a little bit of the highlights of what's happened and your sense of where we're at right now? Because even six months ago, people were telling me like MCP is still too brittle for some of these use cases, which seems to be have become a solved problem. Just give us that context, if you would.
00:10:50 · Thomas Li
[00:10:50] S0: Yeah, so not all MCPs are created equal, because if you really think about what is an MCP, right? An MCP is a set of prompts, like English prompts, that sit in front of your API. So really, it's no different, like if you wanted to create an MCP, it's no different than writing a very long prompt into Claude or ChatGPT and then ending it with your API endpoint, your URL, right? So now what is this prompt? The prompt in short is a set of instructions on how to use your API. So in human world, we actually have that, we've had that for a long time, it's called documentation and API. So when you have a software engineer use the API, they always ask where's the documentation, because just giving me a URL for the API is meaningless if I don't know how to use it, right? I don't know what's behind it, what are best practices, what are rate limits and all of that. So the MCP prompt is basically the documentation's portal summarized into a text file. But ultimately, what makes an MCP good or bad or brittle comes down to what is in the API, right? MCP is just an API that's being used by a large language model versus a human. And how you set up the API still is the same as what it is before. First of all, you need to have the right data in it, right? Anyone can create an API endpoint with nothing behind it. It's a functionally useless API, but you could create one. Two is once you put the data in it, how do you structure it? All the best practices that exist for humans to use an API is identical here. Are you creating a pathway and an index to help search through the API? Right, if an engineer looks at an API and they say, hey, there's 15 different API, like endpoints within this first endpoint, like, how do I search through them, how do I know what the syntax is, what are best practices, like all of that still needs to exist, right? Does your MCP have, or the API in your MCP have access to different tables? How do the tables work together? So I'll give you an example. In our MCP, there are multiple different tables, right? One table is just numbers, one table are documents. So when you hit our MCP and you ask a question like summarize Amazon's earnings, right, a few things needs to happen.
00:13:06 · Thomas Li
The first thing is it needs to go through all of the data and essentially say, okay, what has happened to earnings, what are the historical numbers like, and so on and so forth. But it also needs to corroborate the numbers with the actual transcript, with the Q, with the eight ks, with the investor deck, right? Pull all that information out to create a holistic view. It also needs to get access to stock pricing, right? And look at how Amazon stock price has changed vis a vis its benchmark or other peers, so it needs to pull in a bunch of stock pricing. So to make your MCP really good, you need to not only have multiple data sources in there, but also the data sources need to be connected internally within your API in a way where if the large language model is pulling Amazon's gross margins, it knows where it's coming from, it knows the notes that are relevant to gross margin, and it knows based on these notes, are the historical notes that I should look at, because that might be relevant to helping me understand gross margins today. So connecting all of those tables, setting up an index, making sure that, you know, the latencies are low, that's what makes an API good. And if you have a good API for humans, you almost always have a good API for MCPs.
00:14:25 · Brett Caughran
[00:14:25] S1: And where do you think is sort of understanding that it's probably a heterogeneous answer, where do you think the MCP structure is today in terms of reliability? Has that improved? Is the foundation models have improved? Agenic search, etcetera. And of where are we at in terms of, you know, trusting that data to not hallucinate or, you know, sort of break retrieval in MCP structure?
00:14:52 · Thomas Li
[00:14:52] S0: So I think it has definitely improved on the model side, but I think the bulk of the improvement that we're seeing with MCPs today is actually not because of the models or the labs, but actually because of how data providers are creating their MCP. I think people are starting to get comfortable around, you know, an MCP is not like a business catchall, right? Like someone senior says we got to build an MCP, we build an MCP. At the end of the day, it's still a product. It's a product that needs to be maintained, you need to talk to your customers, you need to understand what problems you're actually solving for, what are the most likely used prompts, why they're using something, and how do you build your MCP to help that. What other people have figured out is, you know, one of the fastest ways you can help people adopt your MCP is to teach them what are the best use cases. So can you create skills such that when your MCP is invoked, your customers can also pool those skills to invoke the MCP, right, and your skills will have a clear guide to how to use the MCP. So a lot of it is just like how, you know, when you deploy an API, you will sit down with your customer and say, Hey, let me teach you how to use the API. Here are some case studies of how people have been successful using that API. It's the same thing here, just instead of case studies, you're using skills, or agents, right? So I think there is a lot of grown understanding amongst the vendor community about that. Where we see roadblocks happening comes primarily down to this cannibalization debate, right, because you could argue that if all of my data is in the MCP, so first of all, the question is, does all my data go into the MCP, right? But hypothetically, let's say you're a content company or data company, you say all of my data goes with the MCP, and it goes to my customers, then if you have any other products that are reliant on your data, then the question is, is it still relevant? Right, like a simple example is, let's say on the Dilupo website, I have a summary table for a summary of financials for every company, and customers will go to that page and just look at summary financials. If I put financials in my MCP, then theoretically, you don't have to go to my website to look at summary financials, because if you prompted Claude, you will get the same thing.