Invest with AI
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.
00:17:15 · Thomas Li, Brett Caughran
Moreover, if I gave you that skill, I'm making it even easier for you to go and view my data in Claude and not on my website. So I think for organizations where they look at that setup as a loss of adoption, then it's rightly so you get concerned, right? I have a different view. My view is so long as I am the reason a customer's problem gets solved, I don't really care if you're solving it in my system or, you know, in someone else's system, long as I am solving your problem. So I'm willing to put every single asset I have into the MCP, but you can see how at different organizations you end up at different conclusions. [00:17:53] S1: Yeah, I've noticed that I'm a FactSet subscriber and I've found that the time I spent in the FactSet terminal is down materially, which is sort of nice because the UI is not great. But I'm accessing a lot of that data via an agentic workspace. How do you think about like one the things I'm struggling with is and I get here, you know, sort of get this question from my students and clients is like, what's the right MCP stack within an agentic workspace? Because DeLuca was early as a connector into many of these workspaces, but now I could get fundamental data from six or seven different players in the same agentic workspace. How do you think about that competitive environment where more fundamental data pipes, KPI pipes are coming in into the agent? How you would counsel an investor to decide on that stack and how you think about Dilupa as being differentiated within that stack?
00:18:50 · Thomas Li
[00:18:50] S0: Yeah, so I love the way you frame it, which is like pipelines, right? So yes, we were the first to build this pipeline, but, you know, anyone can build a pipeline and ultimately, if you're an investor, you should have hundreds of these pipelines coming into your firm. But just like a pipeline, if let's say every pipeline is carrying water, right? What you really want is to get the pipeline with the highest quality water. Usually, the highest quality water tends to also come at a premium. And you might say, hey, I am a science lab, and this water needs to be so pure, it doesn't even conduct electricity, right? Pure water. Or you could be a household where you're like, that doesn't really matter, it just needs to be potable, I just need to be able to drink it. Or you could be a factory where it's like it doesn't even need to be like potable, I just need it to cool a machinery, who cares? So depending on your needs, you probably have different types, you could connect to all of those pipes, but you should only turn on the pipe that solves your problem. So I don't pretend that the lupus data and content can solve everybody's problem at their perceived price to value, right? What we do is we go for the extreme quality, the low latency, the high coverage, right? No fundamental data set out there has deeper data than we do, has more accuracy. So we are the most accurate, we have the lowest latency, and we are probably by far the most comprehensive, right? We cover data points that other firms just simply don't cover. We have, you know, guidance and adjustments and KPIs and guarantees and enterprise SLAs. So we're sort of like the pure water that goes into a lab, right? It's truly enterprise grade, targeting some of the largest institutional investors, and today serving some of the largest institutional investors, right? But I will argue, you know, if you're a smaller firm, and the quality doesn't matter, because your investment style and process just doesn't require like extreme high quality, like this is company dropped earnings, I need to know everything right away, then we might not be at the right price point, because your perceived value of our data will be lower. And there are, as you pointed out, a lot of other sources.
00:21:02 · Brett Caughran
[00:21:02] S1: Yeah, how do you think about a sort of, you know, debate with myself both sides of this sort of like best of breed stack within an MCP pathway of like, let me go pull in the six highest quality stack, the sort of pieces of the stack, which makes sense. I sort of agree with you certainly for the tier one client. Although the MCP pricing for that stack now can be like an aggregate, like $60.70 ks, like the numbers get pretty high when you start to add up the MCP price versus a number of vendors chasing this one pipe strategy where they're trying to be very good, but with one MCP price and there's some creative sort of, you know, vendor licensing strategies. How do you think about where does Dilupo want to play in that? And how do you think about the juxtaposition of those two MCP strategies?
00:21:53 · Thomas Li
[00:21:53] S0: Yeah, so because the beauty of a large language model is that whether you have one pipe or three pipes is fundamentally the same to the large language model, right? Because if, let's say, I'm connected to three MCPs, which basically means the model is connected to three APIs, And if behind every API is three other APIs, the model is now connected to nine endpoints, right? Versus if I had nine MCPs with only one endpoint each, the model at the very core is actually connected to the same amount of resources. So it doesn't really matter. From a buyer's perspective, yeah, you have to deal with more vendors and contracts and like people now, but at least from a product angle, you should be getting the same outcome. Now from a vendor perspective, obviously, if you have more content, you can make the argument I can sell to more people and therefore I can build a bigger business. But I think that the core to whether or not you want data into your pipe or not, is whether there are synergies between the data assets. So one example is, the clearest example is data and documents, right? If all I had was numbers, but I don't have the documents, then you are losing the context for the numbers, because the number 27 in itself means nothing until I can describe what it is. I can describe the history, can describe the context, and how the context has shifted. So having a pipe of just documents and having a pipe of just data will not get you the same output as having one pipe where they are interconnected and woven together where taxonomy has been built. But said differently, let's use like stock price as an example, right? If I have a pipe of just end of day stock price, and I have another pipe of just fundamental data, like that map is relatively simple, because end of day stock price doesn't have a lot of like you don't have a security master issue with end of day stock price, for let's say the New York Stock Exchange tickers. So then it works well with a large language model. However, if you say, hey, NFT stock price is not enough, I need tick by tick, you know, L2, L3 stock price data. Now all of a sudden, you have a security master issue, right? So now you need all of your security pricings to get mapped. If you throw in like option prices into that, now you have a real security master issue.
00:24:05 · Thomas Li, Brett Caughran
So trying to get the LLM to say, Hey, I'm going to buy one L1 panel, one L2 panel, one L3 panel, I'm going to buy a fundamental data panel, and magically assume that LLM can do the mapping in real time, or in runtime, like that's not, just not possible, right? You will end up with a lot of hallucination. So there are data sets that require the vendor to build taxonomies and mapping beforehand, and there are data sets that don't. [00:24:30] S1: Yeah. And how do you think about the moat of your of your data set? I mean, I sort of would seem that armed with agents, it would be easier for a competitor to recreate what you've built. But what are the sort of defensible elements of the moat of your high quality data?