Agent ready episode 2 with Stainless: auto-generating an MCP server & client

It’s time for the second episode of our agent-ready video series. This time, we’re focused on what it takes to build usable, scalable toolsets for AI agents. Joining the conversation are Reed McGinley-Stempel, founder and CEO of Stytch, and Alex Rattray, founder and CEO of Stainless.

Video overview

In the past, users were limited to what SaaS apps exposed through their dashboards - uploading CSVs, manually provisioning resources, toggling features in the UI, and so on. MCP shifts this model by letting AI agents handle tasks directly, but for it to work, APIs must be intentionally crafted to be AI-accessible. The challenge is that most MCP servers are built from one of two flawed approaches: Naively generating tools from OpenAPI specs with open source generators doesn't work well. You end up with too many tools, bloated definitions, and long sequences of API calls that LLMs can’t reason through. Starting simple and manually creating a few high-value tools works at first, but quickly hits scaling issues. Most APIs have 50+ endpoints, and only a subset is relevant. LLMs don’t need every request param or response field. So how do you choose what to expose, and how to simplify it?

In this session, we’ll explore what it takes to build usable, scalable toolsets for AI agents. We’ll share early experiments, including approaches for selecting, filtering, and chunking tools, and highlight where things still break down, especially around orchestration and reasoning.

Full transcript

Reed: Welcome back to our Agent Ready Series where we're talking with different founders and engineering leaders around how to turn your applications and make them agent ready, and what does that mean in different contexts. I'm Reed, co-founder and CEO here at Stytch, and I'm joined today by Alex Ratray, who is the founder and CEO at Stainless.

Reed: Now, could you tell us a little bit about what Stainless does before we dive in and just maybe a brief intro? Sure. Um, so I started Stainless after working on the API platform team at Stripe, where I did API docs and also SDKs. Stainless is best known for the SDKs that we generate for companies like OpenAI and Anthropic and CloudFlare.

Alex: And, um, we generate MCP servers as well. Awesome. Well, I'm really excited about today's topic. Gets a little bit meta around everything where, um, because, you know, I think Stainless role in the ecosystem as being someone that helps companies. Maintain, build net new APIs. Obviously, dovetails really nicely into [00:01:00] this moment that we're having around MCP servers, which is the question that a lot of applications are having that we talk to when they ask, you know, how do we become agent ready?

Reed: Is, how should I think about what is the interface for those agents to take actions within my application? What should those APIs look like? How should I support them? And so super excited to dive into that. Maybe before we get into kind of the nitty grit gritty of, you know, MCP, um, I'd love to hear just a little bit more about like, how you think about the opportunity in front of us from like a user experience if we can drive this type of, you know, different experience.

Alex: Yeah, yeah. I think it's such a fascinating, uh, time. And you know, I've been an API person for, for a while now. And if you rewind, I think 15 years ago, uh, and you look around the tech, the world of technology, you would see most companies building, user interfaces, most SaaS companies

Alex: There weren't a lot of like real API companies, uh, most companies didn't have an API. Now most companies have an API if you're doing sort of any kind of business to business SaaS sort of work, [00:02:00] but everyone's still logging into a user interface, right? So, if I'm a user of, of Stytch, I'm gonna log in to manage my projects and so on.

Alex: If I'm a user of Stripe, I'm gonna be spending a lot of time in the dashboard, maybe offering refunds to customers or seeing how our revenue did last month or something like that. Uh, configuring, etc. And if you look at the day-to-day life of a lot of people working in software, really any industry, if you're you tend to spend a lot of time logging into a bunch of different apps, admins, dashboards and clicking around a lot, you know, opening up modals and filling out forms, browsing through lists of, you know, rows of, of information and, you know, you got your list views and your detail views.

Alex: And, anyone doing full stack application work knows all about this stuff. And we're getting to a point where I think everyone, a lot of people would rather just be talking to ChatGPT or Claude or Cursor. And rather than saying, “okay, I need to go refund [00:03:00] somebody's order for these socks.” Let me go click around a Stripe dashboard and find the right person and figure out how to do the refund and then figure out how to make a discount for the next time.

Alex: You just go into the chat window, you're already in and say, “Hey, you know Reed didn't like his socks. Can we refund them?” And see an agent that's gonna go make the list API call to find the customer named Reed, and see the order that he made that had to do with socks and run the refund action and, you know, maybe create a discount, maybe even use another API to send a sorry email if he didn't like, you know, the, the wool or whatever it was. And so on and so forth. And so being able to do all of your work in one place that's really intelligent and a huge part of the promise of agentic ai. In order to do that, obviously, you know, your AI chat, your agent is gonna have to be able to connect with all these services and take all sorts of different actions.

Reed: Yeah, no, certainly. And I, I think one of the things, you know, I've thought about as it relates to this topic is [00:04:00] it feels like, you know, especially since I, I run a core infrastructure company, but obviously we have to have UI and you know, interfaces for things like the dashboard managing different elements of projects, as you mentioned earlier.

Reed: And that's great, like we're happy to do it, but it does seem like there are a lot of resources that we put into how we want to onboard this user to share in unfurl information as they go. Obviously sometimes you're mimicking other patterns that you see elsewhere. Sometimes those patterns don't work, so you have to invent your own patterns.

Reed: And overall, I think the end developer, end user, ends up with actually a lot of kind of mental friction that they have to go through every time they onboard to a new use case or application. And so just another kind of example of kind of like the socks example that you had though. But I think about it every time I'm using another B2B SaaS application where, you know, maybe it's only 30 seconds I'm wasting, you know, clicking around trying to find how do I do something.

Reed: But that does feel like both, there was a lot of design and engineering work that went into whatever was created on the end output there. And it's all standing in the way of me actually getting, becoming [00:05:00] stickier on the platform and the core functionality. And so, to your point, like I think one of the things I get excited about is it feels like there might be a lot of.

Reed: Non-differentiated things that we are reinventing the wheel on when it comes to management interfaces, SaaS interfaces, etc. And if we can get beyond that to this more natural language ability to access those things, I'm really excited about what that unlocks.

Alex: Yeah. Software companies are building capabilities, right?

Alex: And you want to expose your capabilities as cleanly and naturally and flexibly as possible to your customers so that they can take best advantage, most easily of, of the novel stuff that you're bringing into the world. Yep.

Reed: Definitely. Awesome. Well, I'd love to maybe take it a step further in terms of specifics on, in particular MCP- model context protocol.

Reed: Um, how does this relate to this kind of promise for agentic applications, use cases, etcetera? Would love to hear a little bit more about how you think about it at Stainless.

Alex: Yeah. So MCP has, you know, I, I think everyone watching this is aware, has, has hit a real nerve and, [00:06:00] and found a lot of traction in being a universal way that agents can talk to other software systems, right?

Alex: At Stainless, like we think of ourselves as the API company, and what we care about is computers, talking to computers, right? And so this really fits squarely in what we love to think about. We're usually thinking about production software, talking to production software. But if you want to have an agent talking to production software of some kind, then you're probably gonna have to use HTTP and make an API request over the internet in some way, shape, or form

Alex: And you're also gonna have to let the agent find some way of making that request. And so MCP is a way that, I actually think of it kind of like an SDK. For an LLM. So if you're a Python developer and you want an easy, smooth, and interpretable way, of making an API request where you kind of know you're not gonna get it wrong, then you want a well typed Python library.

Alex: To do that. And if you are an agent, well, you could sort of [00:07:00] YOLO a random API request with curl into the, into the void. And some of the time that's actually gonna work great. But a lot of the time for things that are a little bit more nuanced, it won't. And you really want to know, you kind of want that red squiggly line, that type of head experience.

Alex: As a model to say. “Okay, what are the tools available to me?” Mm-hmm. Um, so if I like NPM install Stytch and then Stytch tab as a developer, like what are the options available? That's what MCP brings is a list of, tools like that menu. Yep. And then within each of those tools, the documentation of what parameters, what types they are, what's their description, and so that way the model knows exactly how to interact with, for example, to Stytch API or, or, or any API that is exposing an MCP server.

Reed: I, I love that you use the term YOLO there. That's something I'll use to describe it in the future to folks that, yes, the agent without this may be YOLO’ing into the void when it's trying to figure out how to use this tool.

Reed: And I think that was just a really good kind of analogy there. I love to make this tangible [00:08:00] for the folks that obviously are familiar with MCP, but might not be, um, you know, familiar with the piece that we were talking about, uh, a little bit earlier on how this can abstract, like the onboarding to how do I use this, you know, new SaaS platform, this new SaaS product.

Reed: So one of the things that we were talking about before we started hitting record is Stainless. You know, you don't use Stytch. You haven't been in the Stytch Dashboard before. We just released MCP server last week, so we figured, why don't we just, uh, do a live demo here, see how you take it for a spin, what it's able to, produce from a developer experience and kind of talk through both like that experience, but also how that applies to other kind of MCP use cases that you're seeing in terms of, uh, exposing APIs this way to agents.

Alex: Great, so let's start. I'm sharing my screen now. I'll admit I have not used Stytch before today. Yeah. I've heard great things. And so, what I did here is I installed your MCP server, which uh, disclaimer is not generally stainless. You guys built this yourself?

Reed: We did, although I think, you know, you were showing me some of the other kind of maintenance elements that Stainless gives you. So I think one of the questions I'll have for the team afterwards is should we go look at Stainless for running this kind of in perpetuity, but today this is just a built in house.

Alex: Yep. Amazing. Here I’ve got Claude Code Up, which is one of the many, tools you can use for agentic coding or chat. I could also be doing this in Claude Web or Claude Desktop. I think this is a fairly technical audience and this is a tool I'm familiar with. So, I've asked, uh, for a little bit about Stytch.

Alex: Great. Let's use their MCP server to create a new project and try it out. And what I'm not doing right now is loading your documentation, which I think I've heard is great documentation from poking around. Okay, so I've got a create project call. It's gonna do a demo project. Sounds like a great project.

Alex: Name consumer. Sure. Yeah. And so I'll allow that tool to go [00:10:00] through. It's doing some stuff for me in the background. It's even going through doing the configuration, some credentials create a public token. Is that a good idea? Sure. Yeah. Great. And a secret. Yep. Awesome. And I guess now we're gonna see if it works.

Alex: Cool. Get consumer SDK config. Let's do it, all right. Now, normally, what would be my next step in getting started with this Stytch integration here?

Reed: You might set up redirect URLs. This is typically something that—the way that we thought about this was: historically, years ago, you'd have to go into the dashboard and add the redirect URLs by hand. Then we got a lot of requests for people who were trying to maintain multiple projects programmatically to get Terraform support. And then, obviously, with MCP, the question has been: can we now extend that to agents to be able to take that on their behalf? One of the reasons you need a redirect URL is, let's say that you're using a passive reset or a magic link or an OAuth flow. We need to know where [00:11:00] to send that user back, and the reason that you need to allow listed is for security reasons. So maybe let's see if we can set a redirect URL. Great.

Alex: And here we see it told me a little bit about my— I guess we're gonna have to roll these secrets later, before this video goes live. But we'll say: let's add a redirect URL—maybe stainless stock. App stainless.com/Stytch redirect.

Reed: Sounds good. I'm curious to see if it requires an HTTPS specification, but probably not.

Alex: Test. I hope it's smart enough. Looks like it is. It's added that for me, and it's allowing login and sign up, which defaults to log in. That seems— Pretty appropriate. Cool. And it— It ran into a bug, and it's trying to figure it out by itself. Ficking? I do love the quad code. All right, now it's gonna try again. Is it gonna have better luck this time?

Reed: It [00:12:00] should, though. Hit. Hit. Go ahead, and let's see. I'm kind of curious where the agent's running into things. Perfect.

Alex: Okay, great.Pretty straightforward. They figured it out by itself. I didn't have to do anything. And, uh, I guess I have a, a Stytch integration ready to go which is pretty incredible. That was really, really easy for me to do.

Alex: And in comparison, this is the Stytch Dashboard. I haven't seen it before today. I could look around for projects—where are the projects? Oh, actually, something makes more sense here—the first project is up here. This is, frankly, a really awesome-looking dashboard.

Alex: You guys probably put a lot of work into it. I can see all this stuff, but it might have taken me a little bit more time to find. Even if this would have been faster, even if it would have been more pleasant, I’m probably integrating Stytch in the context of something else.

Alex: I’m building a somewhat bigger OAuth flow, so maybe I say, “Great, now let's pull it into the website code.” There's no code in this directory, so it would probably get confused. I won’t ask it to do that. But that’s a small example of why you might want to expose a lot of your dashboard functionality—your admin functionality, admin API—through an MCP server so people can use chat if that’s what they want to do. That’s great.

Reed: Can you briefly go back to the dashboard? I think it cements something we were talking about earlier. Even if I would say our engineering team is proud of the dashboard they’ve made, every time a new user onboards to this, they’re making mental shortcuts—heuristics—about where they think projects would be: do they go to this dropdown, do they go to project overview, redirect URLs?

Reed: Maybe you find that you’re still scanning—reading tens of words every time you’re trying to find one of these things—looking for heuristics and clues. Yes, that’s easy in isolation, and maybe it takes 10 seconds here, 20 seconds there. Maybe you get lost one time and it’s a minute. But all of that is friction you don’t want to add to the customer experience, whether it’s the end user or developer.

Reed: The other piece I think about is your point that if you’re building this in the context of other things you’re touching, or using other services and you’re in cloud code, it’s much easier for you as a developer—or even in a consumer context where it’s not in code—to stay in a flow state. You don’t have to deal with a net new, slightly different variant of a SaaS dashboard or a consumer dashboard or app that you have to navigate.

Reed: So, to your point, it’s a super exciting future—even if a lot of these things are early. Adoption’s been great. We were getting pushed by our developers to support something like this. I’m sure Stainless—you guys make it easy for people to generate MCPs. I’m curious, when did you ship the Stainless MCP and what was the demand like from your own developers for that?

Alex: We started shipping an MCP offering—an MCP server generator—a couple of months ago. We saw a lot of interest and uptake. People were asking, “Is this going to be useful for our business, for our customers?”

Alex: Now, on the face of it, it’s a very straightforward task to translate an OpenAPI spec to an MCP server. An MCP server definition is just JSON schema. OpenAPI spec is also just JSON schema. In theory, you can take the same stuff and move it to a different file format.

Alex: For each one of the tools, you just make a simple fetch request, or whatever your equivalent is. That sounds really nice, and we were able to get a demo out quickly that enabled that. There are a bunch of little paper cuts you run into along the way—other tricky things like how you do references for components. For people familiar with OpenAPI spec or JSON schema, that’s a little different. You have to change that. Not all of the MCP clients can handle anyOf versus oneOf versus allOf, so you have to simplify things.

Alex: But the basic mechanics are straightforward. What we started with was: every endpoint in your OpenAPI spec has a tool in your MCP server. A lot of people think that’s the only way you can do it. It’s the simple, obvious thing, but it actually has a lot of problems if your API is of any significant size.

Alex: If you’ve got five or ten endpoints—simple API calls—that’s going to go great. If you’re a typical real business with dozens or more engineers, you probably have dozens or hundreds of endpoints in your API. A lot of times the request parameters are pretty rich and complicated. You have a lot of important documentation around them.

Alex: And as you see, the documentation matters. We need to know [00:17:00] that “login” was uppercase. It figured it out, but there’s a lot there. What ends up happening if you upload your entire large API—let’s talk about Stripe, for example—Stripe now has many hundreds of endpoints. If you were to map every single thing to a tool, you’d end up with tens of thousands of tokens for context used up just in those tool definitions. Most of the time you’re not going to use most of them.

Alex: The API calls are also going to be a little unintuitive in many cases to the LLM. You often have to make a sequence of tool calls—fetching data, finding the read user, then making an update based on that. You have to pull the ID from here and put it over there. A lot of times, that gets lost along the way. You’d rather have one tool like “refund based on name” or something similar. That would be more intuitive to an LLM, just like a great SDK call is more intuitive [00:18:00] to a developer.

Alex: But then you get into a combinatorial problem. There’s a lot you can do with an API, and context window limitations—how many tools you can use and describe well—put a tight limit on it. People say not to use more than 20 or 40 tools in one session, which is a very tight limit. Stytch alone has many more endpoints than that. If you wanted to use Stytch alongside your cloud provider or deployment provider at the same time, you can’t fit it all in the model’s head. That’s a problem.

Alex: So we’ve rolled out a variety of tools to help people filter. You might want to use the Stytch API’s MCP server but only use the projects resource—so --filter resource=projects—or --operation=read to only get operations that won’t mutate anything. But there’s more we’ll need in order for this to scale. Ultimately, you don’t want to have to think in advance about the limitations you’re imposing—whether as an API provider or consumer—you just want everything to work.

Reed: When you work with customers or partners that you’re helping generate MCPs or maintain them, how do you advise them to start simple? I think you covered a few of those elements, but I’d love to understand: if I’m a Stainless customer, what are some of the pointers I’d get? Maybe the technologies I’d use in your dashboard.

Alex: If you went to Stainless or even looked at best practices from the MCP team at Anthropic or other resources online, the current industry wisdom is to choose a handful of happy-path use cases you think people will really want to use in an agentic context, and handcraft a few tools there. Maybe it makes one API call, maybe a handful.

Alex: For Stripe, it could be a refund flow or charging a customer. For Stytch, maybe it’s setting up a new project and doing the whole flow we just saw. That could all be one tool. You can “Stytch” that together—pardon the pun—using the MCP servers we generate. In addition to giving you the tools, we give you the building blocks so you can mix, match, and ship your own easily. It’s all just TypeScript code with a great SDK underneath.

Alex: That’s where I’d say to start. You can also expose the entire API through a few simple mechanisms. If you’re not sure what those use cases are—which is common—or if you think you might be surprised by what users try in practice, we have a [00:21:00] dynamic mode. Instead of generating one tool for every single endpoint in your API, we create three tools total, no matter the API size:

1. List Endpoints – “Tell me what’s inside the Stytch API” or “What’s inside the Stripe API.”
2. Get Endpoint – Describe what’s in a given endpoint like CreateProject.
3. Invoke Endpoint – Actually call the endpoint.

Alex: This dynamic approach barely uses any context until it’s needed. The tradeoff is that the user has to watch it happen—it’s three calls instead of one—so it’s a little slower. But it’s a good way to test the waters and see what people are interested in trying, then go from there.

Reed: That’s great. If someone supported that initially and wanted to monitor what users were actually trying, what’s the best [00:22:00] way to get observability and monitoring?

Alex: We send headers with every request, so you’d just check your API logs on your side. We’re not in the middle, so we don’t get any telemetry ourselves.

Reed: Okay.

Alex: You’d see what’s coming through with the MCP header.

Reed: Okay, cool.

Alex: On the user agent.

Reed: Awesome. I think you might have one other thing to show us. I wanted to make sure we could go a little deeper on this use case of building or maintaining an MCP server.

Alex: You bet. Really quick—I wanted to show what it’s like to set some of those things up. This is the Stainless SDK Studio. For example, Replicate, an AI company, is one of our customers.

Alex: This is how they set up and configure their TypeScript SDK. It’s also where they can add an MCP server, which they then ship to NPM as replicate-mcp. Here, they’ve chosen not to enable all resources—only the ones they want to expose.

Alex: You can see their collections list endpoint and a corresponding “get collection” in their MCP server, and so on. If they wanted to take the “dump the whole kitchen sink” approach, they’d just change this flag to true and be off to the races.

Reed: Okay, great. Out of curiosity, from the use cases you’ve seen uptake on for building MCP servers, are there any trends in terms of company verticals that adopt faster? I’m sure AI moves faster than others, but are there other specific, interesting trends you’ve noticed in use cases or company types?

Alex: This is something everyone is—and should be—looking into. We’ve talked with [00:24:00] everyone from Fortune 500-type companies you wouldn’t necessarily associate with the “Replicate” world. As with any new tool, if your business has early adopters in your customer base, you should probably at least experiment with it.

Alex: Where it has the most traction is when you have an audience that logs into your SaaS app a lot and is also forward-thinking. For example, internally at Stainless, we use a company called Pylon for customer support. Our support engineers use that MCP server every single day because they can link between the support case and information from GitHub, Linear (our ticket tracker), internal notes in Notion, and more—all in one [00:25:00] chat without switching tabs. It’s pretty incredible. That’s daily, active use.

Alex: The other customer use case we’ve seen is less frequent but powerful: reporting and analytics. I was talking with Mux, one of our customers, which provides video APIs. You can now ask, “How did my videos perform yesterday?” and it can make multiple API requests, analyze the data, and—depending on the MCP client—write Python code to process it. That’s incredible.

Alex: People may only run reports once a month, so it’s not daily use, but when they do, it saves significant time. In many cases, they wouldn’t have done the analysis before because the friction wasn’t worth the effort.

Reed: That’s a good point—it’s not just about going faster at something they would have done before, but enabling things they wouldn’t have done at all. The Mux case is a great example. The support engineer example is interesting too—when we get a feature request, we need to tag it in Linear, but there’s friction moving from the support flow into Linear. Not everything makes it into Linear. That’s true at any software company.

Reed: I’m really interested in those cases that get dropped today because humans are friction-averse. That’s a great use case.

Reed: Before we wrap up, are there any major takeaways you’d want people watching this video to remember if they were thinking about building an MCP server for their own resources—something that’s a great developer and user experience upfront and as it evolves?

Alex: There’s a lot to consider. First, this is still in a very experimental stage. Expect the ecosystem to evolve in three months, then again in six months. That’s the background reality, and it affects how you approach engineering.

Alex: OAuth is critical. We’re seeing a lot of API customers exploring MCP and realizing, “We need to add OAuth to our API now.” Doing that yourself is a lot of work.

Reed: You’re lobbing it up for me—I appreciate it. It’s great timing, because we have a video that walks through how to turn your app into an OAuth 2.0-compliant identity provider. You can layer that on top of your [00:28:00] API out of the box. Maybe there should be a tighter integration between Stytch and Stainless.

Alex: I agree. This isn’t a sales pitch—there’s no commercial arrangement—but the hardest part for our customers going live with a remote MCP server is authentication. We have one-click deploy to Cloudflare, but OAuth is often the blocker.

Alex: We’re adding other options like that, but you need OAuth, and we want that to be one click—and it can be. That’s a major factor because many companies won’t adopt without it. The usability of OAuth for remote MCP is dramatically better.

Alex: The other thing to consider is that your API responses must be small so the model doesn’t get lost or overwhelmed. In fact, there’s an upper limit on how many bytes you can return, and many API endpoints exceed that. You have to think about filtering that down. Our MCP servers [00:29:00] offer a JQ filter tool that the model can use within the same API request to only get the narrow bits of data it needs. That’s been powerful, but you want something in that direction.

Alex: Also, think about request flows. If you have a chain of requests—anything where developers would, when writing a code integration, be copying and pasting a series of API calls from your documentation—you should, at the current state of the art, pull that into one tool. Otherwise, it’s limiting and brittle. At Stainless, we’re working on general solutions to make that a one-shot process, though they’re not released yet.

Alex: The last thing I’d say is that while we’ve been talking about MCP for API use cases—where people want to do operational things with the MCP server in their day-to-day work—the MCP tool category with the most live traction today is actually on the documentation side. For example, developers in Cursor integrating with Stytch might say, “Hey Cursor, do my Stytch integration for me, and link it to my database,” and so on. Your MCP server likely offers documentation and information to guide an AI coding agent—very different from a chat agent—in the right direction. These are totally separate use cases, but you don’t want to forget the documentation one, especially if you’re shipping an API that you want people to use for production integrations.

Reed: Awesome. That’s great. I think all of this is invaluable for folks navigating the MCP landscape. Thank you so much, Alex. As a final note, if people want to read more about how Stainless helps with this, or follow the topics you post about, how should they find you or Stainless?

Alex: Stainless.com is our website—it has everything there. I’m @ratrayalex on most social platforms.

Reed: Awesome. And thank you to the audience for joining us as we continue with the Agent Ready video series.