Inside Stainless: The Developer Tools Startup Anthropic Just Bought for $300 Million

The internet runs on computers talking to each other, but its entire architecture was built for a pre-AI world. Now we're trying to hook AI up to the internet with MCP, Model Context Protocol, which turns any website or a web service into a set of tools that an AI can use natively to get work done. And the software companies that learn how to do MCP well are going to win over the next decade. That's why I brought Alex Rattray, the founder and CEO of Stainless, onto the show. Stainless's job is to help computers talk to each other. They make the API and SDKs for all the big companies that you know about, like OpenAI and Anthropic, and they're starting to build MCP servers, too. So Alex and I get into the nitty-gritty of what the future of MCP looks like, how to design good MCPs, why MCPs are actually really hard to scale and possibly insecure. And we try to figure out together what a better model for allowing AIs to use the internet might look like. This is a great episode. Alex is a good friend of mine. Let's dive in. Alex, welcome to the show. Thanks, Dan. It's really exciting to be here. It's good to have you. So for people who don't know, you are the founder and CEO of Stainless, which is the API company. You make APIs for companies like OpenAI and Anthropic, and just name your big company that you might use your API. Stainless is probably behind it. Before that, you worked at Stripe doing their API, surprise. And before that, most importantly, we were very good friends in college, and we remained good friends, and we were both starting companies in college. I'm a tiny investor in Stainless, but it's been really, really fun to watch your journey and get to hang out together so much over the years. And I'm just very excited to bring you on to talk about AI and what you're doing at Stainless. Thanks, Dan. Yeah, it's been really fun over the years. I mean, you know, when we were in college, I was working on a startup. You were working on a startup. You had a conference room at a venture capitalist's office as your office, and you let me crash there with my co-founder and team. And we were just like on the other side of the conference table hacking away into the evening. And, you know, very fond memories of those days. And these days, it's not every evening, but, you know, on the weekends, whatever, same thing is still happening. And it's, you know, you don't see that every day, and it's a really nice feeling. And it's been great to see everything happening with Every on the way. Thank you. As I say, I started from the bottom, now we're here. And yeah, I mean, the thing that I always say when people, when I run into people and they ask me about you, in order to embarrass you, I just talk about how you're the only person that I know of who has consistently run barefoot through the streets of Philadelphia. Because when we first met, you were not a fan of shoes and you were a fan of running. You want to talk about that? Yeah, it wasn't that I didn't like the concept of shoes. It's that I couldn't find a good pair. And at a certain point, you know, it's like I was running through Nikes and they would, they would bust open every few months. I think what was actually going on is I had really wide feet and I was buying probably narrow shoes, but they would, shoes would constantly get ruined. And, you know, on a college budget, it's just like, this is, this is no good. And eventually I decided, okay, the longer you wear your shoes, the, the more worn out they get, but the longer you just wear your feet, the tougher they get. So the longer you wear your feet. Try it out. Try this at home. What could go wrong? I actually currently have a really annoying splinter in one of my feet that I was, and so don't actually try this at home. But are you still running barefoot? No, no, this is just from around the house. I see. Dangerous. Yeah. Yeah. But see, that's the thing. If I had been going around on the asphalt without socks on, then my feet would have been tougher and I'd have no splinter. So when you're not running barefoot, you're running, you're running stainless. So you're running stainless. And so how, how many people, you know, you're, you're around 50, right? Just about. Yeah. That's, that's pretty wild. And you started stainless in a pre AI world. And now we're in an AI world. And I think you have some ideas for what the future of AI is going to be and maybe how, how APIs fit into that and maybe how MCPs fit into that. Do you want to like paint a little bit of a picture for us about where we're going? Yeah, I would love to. So to start, like what's an API? Not everybody's familiar with that. So it stands for application programming interface. There will not be a quiz, right? Right, Dan. No quizzes. Nope, no quizzes. Great. But basically it's, it's how one computer program talks to another computer program. It's how, it's how computers talk to computers, how apps talk to apps. And so APIs are, are the dendrites of the internet. Dendrites are where your neurons connect and actually exchange information with each other. So if you have like two neurons in your brain, but they're not talking to each other, you're actually not thinking, right? There is no thought happening in a brain without connections between neurons. And if you think about the internet, if all these servers in the cloud weren't talking to each other, you wouldn't, you wouldn't have internet, right? Like there's, there's nothing going on. If, you know, programs, internet software is doing nothing without APIs, without connections to, to other programs. And so it's really fundamental to the mesh, to the mesh of pretty much all modern software. Everything that we think of when we think about technology at this point, APIs are kind of at the, the heart and center of that, just like dendrites are, you know, the center of the mesh of the, of the brain and how we think. And um, Stainless's mission from day one was sort of to make it easier for computers to talk to computers. So, and, um, You know, it's the long running trend of technology to have more automation, right? Automation is what we mean when we say, okay, we're going to, you know, we're going to apply technology to that. You know, we're going to be making things more efficient. And APIs are how most business to business interactions in some format or another become, become real, become automated. And what we see with the, the rise of AI is that there was a new, a new computer has entered the chat, right? There's a new, there's a new kind of system that can talk to other systems, or at least we would like it to be able to. You used to have either, you know, humans interacting with a computer through a user interface, a UI, or a computer acting with a computer through, through an API. And now we have LLMs interacting with computers, right? And what's that through? And I'm sure anyone familiar with, you know, with Every and, and, and who's regular listeners is going to be familiar with MCP, Model Context Protocol, which is a system for connecting LLMs to, to computers broadly speaking. And it's an area that we're investing in at Stainless. It's really, I think, part of our core mission of, like I said, make it easy for computers to talk to computers. And we've invested a lot of time, you know, at Stainless, the core product that we first brought to market is software development kits, SDKs. And so these are ways of saying, okay, Stripe has this great REST API. You know, you can send JSON over HTTP and get back JSON over HTTP. And if you want that to be really convenient, you're going to use the Stripe Python library, the Stripe Python SDK. So you can go, if you're a Python developer, you'll go pip install Stripe. And then in your application code, you'll write Stripe.customers.create. And all of a sudden you have a nice new customer object in sort of your Stripe database. And you're off to the races. Or Stripe.charges.create in the old days to charge a credit card. And SDKs are what gives developers that easy way to interface with an API. What's the thing that gives LLMs an easy way to interface with an API? And you might say MCP. And in a sense, you'd be right. But what we're seeing so far as MCP is rolling out into the world and people are experimenting with it and trying it out, is that it's not working so great. Like there's, it's, it's difficult to deliver on what I see as the core vision of, of what's so exciting about MCP, which is just like a dashboard and a user interface lets you click around, see a bunch of stuff, fill out forms, click buttons, do things, anything that you would do while you're interacting with the software, you'd do through the user interface generally. But LLMs interacting through MCP, it tends to be much more restricted. You can only do a few little things. So there's usually not a ton of tools that you're going to be exposing to the models. And just to stop you there. So I think what I'm hearing you say is what the, what MCP does is just like a website is built for humans to be used. MCP is sort of the equivalent in, you can think of it in certain ways of exposing a set of tools for the AI Chat with every single tool available in there, with every single nook and cranny and corner case available so that you can do anything through AI. That's the vision. Now, there's a lot of problems with that. The biggest one that I mentioned is sort of this context window limit. But you also have all sorts of security and permissions problems because you don't want the AI to color outside the lines and say, okay, in addition to refunding Dan's socks, I also refunded every customer for all transactions ever. You know, and then I sent a bunch of money to my own AI bank account, ha ha ha. And so there's more to the challenge, but that's the vision that I see. But I think, you know, the place we started there was you said it's not working, but I don't think that that's the reason why it's not working today, right? Or is that the reason why it's not working today? So what people do with MCP today is sometimes they'll try to expose all parts of their API. And the way people build MCP tools is, generally speaking, they have an underlying API, usually a REST API, and they wrap different parts of that, different endpoints, different operations in MCP tools. And you can kind of do that in a one-to-one mapping, or you can kind of handcraft things for the MCP. And today, in order to succeed, people are finding that you really have to kind of handcraft it to the MCP, to the LLMs. You have to say, okay, I'm making one specialized tool to look up a customer and refund their transaction based on a description. So there's all these like decisions that you have to make where you need to have like the ergonomics of the model and how the model thinks in mind in order to make sure the model does the right thing more often than not. Yeah, it's hard. It's hard. Yeah, yeah. So I use this SDK analogy sometimes. So it took a long time for humanity to get to the point where we could make a really good Python SDK for a Python developer wrapping an API. And I think we've we've cracked that nut. um offers really great Python libraries, but you know, we're building on the shoulders of giants here. A lot of people have done this over time. We haven't figured out how to expose an API ergonomically to an LLM in the same way that we've figured out how to expose it ergonomically to a Python developer. And that's kind of like a new research problem in a sense. And it's harder because I can go learn how to be a Python developer if I want. I can't really learn how to go think or see like an LLM. But you know, sure would be powerful if I could. And that makes it tricky. We do have at Stainless, I think some things that we're cooking up to address some of these problems, including not, you know, including the ones that you also mentioned, like LLMs have a really hard time with a repeated sustained chain of actions. And you know, even like if you get an API response back around, hey, like list all the transactions, there's so much data and you might have to go through the next page and the next page and the next page to go through all the transactions to find the one that has Dan with the stripey socks. And that's, again, a ton of context with one or two small needles in the haystack. And LLMs are pretty good at that, but they're not perfect. And with too much hay, you know, we all kind of end up throwing up our hands and that's true for LLMs too. So yeah, so there's a lot of challenges today. And so when you look at, I mean, and you're building MCP servers for people, but when you build them and just generally when you see people doing it well today, like what are the principles or how do you think about making an MCP server that one, people use, which is actually a big one. And then two, when it is used, actually does the right job. There have been relatively few times that I've seen it done well. I have seen it done well. We're cooking something up that I'm really excited about, but with today's technology, you really have to do a good job of product management. I mean, you have to go out into the market and talk to your customers and see what their actual needs are and look over their shoulders as they, you know, use and operate, you know, your software and think about what could we unlock through AI where people would be doing things that they can't really do with our software today because it just got so much easier. And then you have to do kind of a lot of engineering work usually to wrap it up in a bow that works for the models. And you have to, you know, you have to set up a really good system for evals. And if you're doing MCP, you have to think about the different clients that people might be using. Are they using cursor? Are they using cloud code? Are they using something else? And the different models underlying all of that. So you end up with this pretty crazy matrix of things that you might want to optimize for and ways that you might want to evaluate and make sure that what you're offering is, is working well. Um, and it's also kind of a black box to get that feedback, uh, back to your, um, servers so that you can find out, hey, we, we gave it, we gave a tool call response here. We gave an answer of some kind. Was it actually any good? Um, did, did the user like it? Um, was the LM able to use it? Uh, and that's a problem that I think I haven't seen a lot of people solve, um, yet as well. And so, um, thinking about that as the first class thing, maybe you have like a send feedback tool. Um, that's something that we've been thinking about doing. Um, just so if a user like says out loud, you know, in the chat, oh man, that was useless garbage. Like, okay, now, now that at least the MCP server is going to find out about that. Um, but is, is there anything specific you've learned about like how to do it well, other than like, obviously you got to talk to your customers, think about your use cases, but like more concrete, more, more applicable stuff about how to design a good MCP server. You want to keep the number of tools relatively small, relatively low. Um, you wanna have the tool name and the description be, be really precise and specific. Um. Um, Yes. Good writing is hard. Um, yeah, I mean, that, that's that's why, like, you know, you can make a great tool of lookup person by name and product description and then refund them. You can make a great tool that does that. Um, and you also want a small number of of in, you know, properties in the input schema. You want a small number of parameters and you want them concisely described, but sufficiently described. Um, this, this is also hard. Um, and you want the response data to come back with a very small amount of data, only exactly what the model will need. That's also very hard because you may not know a priori which things the model is really looking for. Um, and you know, we have a technique that we use in our MCP servers today where we give the model a JQ filter, which is a way of filtering out JSON. Um, and that can work pretty well. Um, but, but that's kind of a, a special trick. Doesn't this mean that like MCP just needs another level of like a search tool function, search tools, search, like find a list of relevant tools given my task. The tool browsing problem is, is, it's definitely one very serious one. Um, and that is one approach. And so we actually do this at stainless today where you can get an MCP server for your API that just has, like I was saying earlier, the very simple thing of every endpoint is exposed as a tool. And if you have a small API, that works great. Um, and you can also filter it out so you expose an MCP server server with only a small subset of, of your, of your endpoints. That works great. Um, you can also use kind of what we call dynamic mode, where there's three tools no matter how big your API is. One is, you know, list endpoints. The other is get endpoint and learn about it. Um, and then the last one is execute endpoint. Uh, and so that enables this context thing to scale really well, but it means there's three turns of the model just to do one thing. Um, and so that, that gets slower. It's, it's more expensive in another sense. Um, and um there's some lossiness. The, it doesn't perform, it performs pretty well, usually, but not, not quite as well because, um, the, the tools aren't loaded up in quite the same way. Are you using MCP servers yourself? Yeah, I use, I use MCP, um, uh, to, actually, uh, funnily enough, not so much on the, on the coding side, but I use it on the business side. Um, so I'll use like the Notion, uh, HubSpot, Gong, um, MCP servers to kind of say, hey, like, And actually an MCP server for, for our database, um, a read-only, a read-only copy of our database and say, hey, what are the interesting customers that signed up for stainless last week? Um, and it'll go off and make a great query of our Postgres database and then it can cross-reference those things in HubSpot and then look up our notes in Notion, um, maybe even look at transcripts and Gong, um, and tell And two minutes later, and they want to jump on that. They don't want to be knee-deep in a debugger. And so something that we do sometimes is they'll file the ticket in case, and by default, it'll maybe, they intend to do it later or some other engineer is going to be doing it later. But, hey, can we see if quad code can just take a crack at it? Is that going to work out 100% of the time? Definitely not. Is that going to work out 50% of the time? Still no, to be honest with you. But can that improve the overall efficiency? Yeah, maybe. We're still, I would say, experimental there, but we're seeing a lot of promise. That's really interesting. Okay. Well, I know you also, in our pre-production call, you were talking about, you have a big vision for the future of AI. Do you want to talk me through that? Yeah, yeah. I would love to. We talked earlier about how Agentic AI can make operators' lives a lot easier by taking their certain pedestrian tasks and sort of running with it independently. And that's something that I think, as an industry, we're almost on the cusp of. And if you start stepping, you know, you ask how you get there, and you also start asking about the steps beyond that and beyond that. A big part of the way I see things unfolding from here, I like to say is the future of AI is cyborgs, which is like sort of like extra ridiculous because like, what is a cyborg other than like already like a robot? But, you know, cyborg, as I understand it, is a term that means you're sort of like part, you know, person and then part machine. And in this case, I mean, when you go and talk to an agent, what you're going to be getting is part GPT, neural net, LLM, part AI and part code, where the machine, quote unquote, that I'm talking about is traditional CPU, not GPU software. And to me, I think I expect this to play out in two main ways. One is your kind of one-off operational use cases. Like we were talking about a minute ago. And then the other is production software. And in the use case we were talking about a minute ago, where someone needs to kind of perform some tricky one-off action with a bunch of points and clicks, then now we want an AI to just do a bunch of tool calls. The way I actually see that happening and what we're building towards is code execution. So rather than the model having a bajillion tools, the model has two tools. One to execute code where it just kind of has a text box of like, hey, put in some TypeScript and you're going to use this API's TypeScript SDK. And you're just going to write stripe.transactions.list or stripe.charges.list. And you're going to do stripe.customers.retrieve and stripe.refunds.create. This is really easy for models. They're really good at writing code. And if you give that tool a little bit of sort of a readme where you say, here's an example request, and here's some other resources, some other API calls that you can make. It's really good at extrapolating from patterns if the SDK is sort of an API or well-formed and predictable. And then you give it an additional tool to kind of search the docs and ask questions to the docs. And anything it's not sure about or gets wrong on the first try, you give it the documentation. And what this does for that scenario that we were talking about earlier is you have very, very limited impact on the context window up front. I mean, we're talking about a thousand tokens or something like that, maybe less. And the context impact of doing a whole bunch of paginated list requests, zero. The model will go look for somebody named Dan and it'll double check that the purchase was Stripey Socks. And it might write three nested for loops, but then only at the end when it found the right thing, it'll console.log, found Dan, customer ID, blah, blah, blah, transaction ID, blah, blah, blah. And then create refund, refund ID, 123. And the context hit coming back from all of this is going to be like 10 lines of text. It's really minimal. And all of this will run really, really quickly too. So you don't have a round trip to the model every time you're doing something like this. It's just CPU code. And it runs in a server in the cloud right next to the Stripe API in AWS somewhere, probably. And it goes super, super fast. Okay. So what I am understanding you saying is like the language model has a tool where it can write code and send that code to this tool that whoever the company is, whether it's Stripe or whatever, whoever's MCP server you're using, they'll go and execute that code. And that code is going to interact with their API and then return the results rather than like these sort of, you know, you have 50 different, you have 50 different possible tool calls and, you know, all that stuff. It's just model writes API code and API provider executes that code, runs it on their API and returns the results. Why wouldn't I just, why wouldn't my model just like write the code that I then run myself instead of relying on an API provider to do it? I expect that that will happen a lot more. I will expect, I expect that the code execution tool is going to become the most widely used tool. The problem, one of the problems that we have today is that the code execution tool doesn't work so well with libraries. LLMs have a hard time working with library and knowing exactly what version of the library it's using, using the right version, probably usually the latest version, and not hallucinating, you know, aspects of the API and knowing how to iterate if it hallucinates wrong. And if it can't use any library off NPM or, you know, the Python package index or anything like that really, really well, basically perfectly out of the box, then, okay, well, forget about using a library. At that point, you just have to hit the raw HTTP API. And at that point, in order to figure out what's in there, you need the whole OpenAPI spec and you're back at square one because that document is massive. And furthermore, something that's really scary about that is if you don't have a typed library with static typing where the computer can say, what you're trying to do is wrong, then the LLM will try to make an API request that is wrong. Some percentage of the time. The code execution tool can run a type checker and say, oh, you know, you're asking about stripe.transactions.list, but that actually doesn't exist. Stripe doesn't have a transactions API. You might want payment intents. You might want orders. You might want balance transactions. Which one do you want? And if the API provider is doing a great job building this tool, it'll return the documentation for all of these things in line. It might have its own AI look at what the model is trying to do and come up with a suggestion. And that sub-agent, you know, is well-trained, specified, always updating, and isn't burdened with the context of the full conversation. What do you think of the security model? The security model is really, really interesting. This is another area where we're really starting to think about things at Stainless, and I'm getting really excited about it. So if any listeners are really interested in this and have some ideas or want to talk, you know, please do reach out. At the end of the day, I think the security has to take place at the API layer itself. Right now, you see people trying to implement security by sort of limiting what's exposed through MCP. And that kind of makes sense, but at the end of the day, you could do anything that's in the API under the hood, right? And what people should be doing is using OAuth with granular permissions, with proper scopes. And at that point, the security happens in the right place, which is at the API layer. There's limitations to OAuth scopes, and it's pretty hard to build. So it'd be nice if someone made that easy, but my view, that's kind of the, that direction is sort of the right, the right layer. So going back to my earlier question, I'm thinking about the idea of having a model write code that then the API provider executes to, you know, interact with their API and then returns the results. Would you ever consider just creating a tool use tool that developers use? Because like, for example, I'm thinking about for Quora. Got all these tools. Maybe Gmail is going to build, you know, like a code use thing or whatever, but really I just want, I would probably use what you're talking about inside of Quora, but we would need a tool use tool or, but it's not a tool use tool. It's like a, it's a computer. It's a computer use tool where, and I know OpenAI has this, but it's not really well-built for lots of libraries and stuff. It's not a custom environment. Like I need a computer use tool where I control the environment and I can install different libraries in it and be able to call it anytime to then call any API or it has to have network access basically. Yeah. You guys should build that. We're working on it. Fuck yeah. You're building it for developers who want to access MCP servers or people who are providing MCP servers. We're starting with people who are providing MCP servers, but ultimately I think that we're going to need this to work such that you can give the model a code execution environment where it can hit not only the Stripe integration, but also the Salesforce integration and also anything else. And, but not too much anything else, right? And so one of Tool, like I'm talking about, is that the only way you really, quote unquote, build a tool is with instructions, with prompts. And the full power of everything you could possibly do in the API, in the Gmail API, for example. It's all there in one tool. But sometimes you have specific tasks or specific categories of work that you want to describe in a particular way to help the LLM perform a sequence of actions as productively as possible. And at that point, the only work in engineering that you have to do is prompt engineering. We'll see if it's that quote unquote easy. As we all know, prompt engineering can be really tricky. It's hard. Yeah. But I think that's part of the vision. That being said, we do have some pretty nifty ways with the MTP servers that we generate today to help developers mix and match all the parts of the different tools underlying all the different parts of the API as they compose and write their own tools. This is awesome. So for people who are listening and want to know more from you and more from Stainless, where should they find you? Stainless.com. That's our website. Awesome. Or at least visit stainless.com. Alex, great to have you on. I can't wait to do more of this when you have some of these new things launched. This is really, really fun. And yeah, great to chat. Thanks, Dan. You too. Oh my gosh, folks, you absolutely, positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure, unadulterated knowledge bombs about ChatGPT. Every episode is a rollercoaster of emotions, insights, and laughter that will leave you on the edge of your seat, craving for more. It's not just a show, it's a journey into the future with Dan Schipper as the captain of the spaceship. So do yourself a favor, hit like, smash subscribe, and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you.