Transcript#
This transcript was generated automatically and may contain errors.
All right, we're a little bit past the hour, so good morning, good afternoon, good evening, wherever you're coming from. Thank you so much for joining us today. I'm Matt Leary and I'm a product manager here at Posit, and specifically I'm a product manager on Posit Connect. I'm joined today by Neil Richardson, who's the VP of Engineering, and we're excited to talk to you about the Model Context Protocol, or MCP.
We've been working here at Connect to make Connect just a great place to host your MCP servers, and so that's really what I want to have the discussion about today. I'm going to turn it over here to Neil in just a second, and he's going to talk about what is MCP, why might you reach for it as a tool to use, and when is it good to use.
After that, I'm going to come back and talk to you about how you can use and host MCPs on Connect, and then we'll finish and leave enough time for a Q&A. So thank you very much for joining us again, and with that, Neil, I'll turn it over to you.
All right, thanks a lot, Matt. Like Matt said, I'm going to start off by talking about what MCP is and when you might want to use it, and I'm going to dig into some of the security considerations as well, and how you can design your MCP servers to help you harness the power of AI safely. And then Matt's going to show you how to deploy them on Connect successfully.
We hope that you really come away from this just like feeling empowered, feeling like you have the skills and tools you need to build MCP servers and to deploy them to Connect, and that really MCP fits within, you know, existing patterns of building things that you already know.
How MCP came to make sense
So I want to start with a story about how I came to understand what MCP was all about and what it was for. As Matt said, I am VP of Engineering at Posit, and, you know, over my career, I've worked in various facets of open source and data and enterprise tooling.
Connect is a platform for deploying and sharing custom apps and dashboards and reports and APIs, things that you write in the language and framework of your choice, whether that's Shiny or Streamlit or FastAPI. Connect now supports Node.js apps as well, Quarto, of course, and so on. And you can also host MCP servers on it as well.
Like so many people in the engineering industry, we found ourselves last year getting more and more into using Claude Code. And one of the great things about this moment in our industry is that there's so many things that seemed hard for us to do or kind of out of reach before, but now they're available to us. We have this agent, this Claude Code, we have tooling around this where it has all of the context that it needs in order to take an idea and turn into something that works.
So increasingly, we found ourselves thinking like, all right, Claude's really good at solving this problem. I wonder what else I could point it at. What else is out there that maybe we have found to be hard and challenging that maybe it's not so challenging anymore?
And so a number of months ago, I started looking at how we were responding to customer support queries. So again, as many of you probably know, Posit uses Zendesk for support. So you all can file tickets there, and our support team will respond to them. And if it's something that has a well-established answer, they can respond to you with that. But if it's like a bug report or something that's a little bit more complex or even a feature request, it gets escalated to the engineering team.
And I thought, well, you know, Claude is really good at reading the code base and developing an understanding of how things work and finding bugs. What if we could just point Claude at all of the context that's coming in from a Zendesk ticket? Because there'll be the whole backstory of what the issue was, sometimes a full like server diagnostic bundle with all sorts of useful detail there that, you know, for a human, it takes effort. What if I could just have Claude do that for us?
Claude can burn through the code base and make all sorts of connections. So I wanted something that was kind of like this. Hey, Claude, help me with this Zendesk ticket. But this doesn't work. Because Claude will try to go request it, but it runs into authentication. And I can't provide my credentials to log into Zendesk to Claude in this way. In fact, I probably wouldn't want to have like my username and password just in the model context there. And, you know, but even if I could solve that problem, I'd run into the next problem, which is that the Zendesk REST API is really not designed for AI agents to be able to make efficient and secure use of it. It has tons of endpoints, very verbose resources, and endpoints that allow me to not only read things, but also write and delete things. And I wouldn't want to give an AI agent that sort of access.
So this is what MCP was designed for. It offers a solution to this. So it provides a way for you to authenticate securely with APIs without giving your credentials to the agent. And by writing a custom MCP server, you can control exactly what tools are made available and what capabilities they expose. So this improves not only your agent's performance, but also it allows you to protect against a range of security challenges that could come about. And then by hosting an MCP server on Posit Connect in particular, you can easily share it with others and allow other people to use this.
What MCP is — and is not
I want to start by just saying what MCP is. And actually, I want to start by saying what it is not. Because I, you know, with all of the buzz around AI that's out there, MCP is not magic. It's not vector search. It's not AI. It's not any of these things.
You could put AI behind an MCP server. You could put a database or a vector search behind it. You could put whatever behind it. MCP is not that. MCP is really just a specification for providing tools to LLMs. So, tools are just, you think of it as a function that the LLM can call.
So, when your agent harness is spinning up, it connects to MCP servers that are configured for it. And so, it can see in that sense a definition. This is what the MCP server is for. Here's all of the tools that exist, all the functions. Here's what their inputs are. And here's what it's going to return. And so, then the model will then know, if I'm asked to do something about this, I have these tools available. I can call that tool. And so, MCP is just a standard for servers that host tools, as well as a way that you can register them in your client, which is any AI application. Could be Claude Code, could be Posit Assistant, could be any number of harnesses out there.
There's two main kinds of MCP servers, local and remote ones. So, the local ones are something that runs on your machine. And as you see from this example command here about how to add it to Claude Code at the command line, it's calling UVX or NPX or something like that that is literally going to run code. And often it may be code that is being downloaded from GitHub. If you're a security person, you're probably screaming and pulling at your hair right now. There's lots of convenience that comes with that. And, boy, there's lots of things that could go wrong with that. A nice thing about local MCPs is they can access your local file system and do things with that. A terrifying thing about local MCPs is that they can access your local file system and do things with it.
Remote MCP comes with a different set of trade-offs. And I'm going to be focusing on remote MCP for a number of reasons. Remote ones, as I say, like they run somewhere else. They run in Posit Connect. They run wherever you run applications. And as you see in the command to add them, two things I want to call out. First is I am giving a URL to the way that you distribute, the way you share access or at least the existence of a remote MCP server. And second is that, you know, it says HTTP. Because remote MCP goes over HTTP.
So, remote MCP servers can't access your local file system. That gives you some security benefits there. It also limits some of the things that it can do. But on the other side, it may be able to provide access to resources that you only have access on your server that you couldn't have locally. And that has some advantages as well.
But as I mentioned, you know, if you look at the remote MCP, you know, it's saying it's going over HTTP. That really points out what I think is a really important insight here. Is that MCP is an API standard. It's a standard for how to design APIs that AI applications can use. So, you've probably worked with REST APIs that work over HTTP and you sit, get, and put and post JSON. That is a convention for how APIs over HTTP work. This is just a different one. And so, a remote MCP server is really a JSON RPC server with a set of well-known endpoints and a schema for how tools are defined.
MCP is an API standard. It's a standard for how to design APIs that AI applications can use.
So, in practical terms, that means if you follow this MCP specification, any AI application is going to know what to do with it. How to discover what tools are available and how to call them. And in practice, going to call them by making a post request over HTTP and getting a response from that.
So, for me, when I made this connection for myself, like, it really helps demystify this. This is not some, you know, super buzzy AI thing. Yes, it plugs into a lot of buzzy things. It turned it into something that I can reason about. Because, you know, someone who's been working for many, many years in software and in data, I've worked with tons of APIs over HTTP. I've built libraries to work with them. I've built them. And so, like, it turned into something that was very familiar. It is something that I knew what it was. And so, it was not far out to go make my own. And I think you know what this is, too. And your coding agents know what this is, too. So, this is not something that is foreign that is out of your reach. This is something that you can build.
MCP adoption, backlash, and when to use it
When the MCP standard came out at the end of 2024, I believe, Anthropic announced it. It's now governed with an industry consortium under the Linux Foundation. So, it's got some amount of open governance. There was a lot of excitement when it first came out. After much enthusiasm, there was a bit of a backlash. And in fact, you know, many people found out that, like, why do I need a big MCP server for something when there's already a perfectly good CLI and Claude Code or Codex knows how to call command line utilities from the shell? This is just a waste. Which led some people to say that, you know, MCP is dead. Obviously, I disagree. And that's why we're having this talk here.
You know, I think it's fair to say that there was a lot of examples of MCP servers being written and put out that, you know, in retrospect or with the tools that we have today, don't really need to be an MCP server, aren't really the best fit for the use case. But there are many valid use cases and places where MCP really is the right tool for the job.
So, I want to step through a few of these criticisms and really put into context of when MCP is great, particularly remote MCP, and when some other tool is better. So, we're really talking about MCP versus a command line utility or even a skill. So, the agent skill standard is another open standard for AI things that I believe came out of Anthropic as well. But, you know, skills are markdown files that your agent can read lazily to, like, be able to do something else.
And skills are really great for explaining how to compose tool calls that an agent already has. So, if the agent can already use bash and call things that are in the command line or, you know, web fetch or other sorts of tools, if all you need to do is instruct the agent which tools to compose together, then a skill is the right thing for the job. But often, though, you know, what we're talking about is not just skill versus MCP or command line, but, like, skill plus MCP versus skill plus command line utility. Because often you do want to have this extra narrative that explains how best to take advantage of the tools that you're providing by one of these other means.
So, one of the critiques of MCP initially was that MCP servers take up too much of this precious context window that your model has. Because the way that some of these model harnesses worked at the time was that you load, you connect an MCP server, all of the tool definitions, all of those, all that text goes into the model context up front. And that just takes up a lot of tokens. And so, you know, if you've got ten MCP servers that you might use sometime and each of them have 100 tools and you're probably not going to use all of those within every session, that's just wasted context. You're burning tokens. You're burning money. And it's also kind of distracting the model from what actually matters.
And people noticed, like, well, the gh command line utility that, for driving GitHub, that's actually already in the training data for these models. So, Claude already knows how to use gh to do things. Why do I need to burn all of these tokens on MCP when gh is already there? So, I think this really points to the case where a command line utility is really the right tool for the job. And so, it is the strongest case when the command line utility already exists and is widely available and is already in the training data. So, the model already knows how to use it and when to use it and what for. And you don't need to waste tokens explaining how. And, of course, this is only helpful if your agent has Bash or some sort of shell available to it to call the CLI. And that's not always the case.
So, if you need to care about cases where you don't have the ability to just shell out and call a CLI, MCP is a good alternative there.
I mentioned about the advantages of remote MCP over local MCP. And I want to hit on a couple of them here, too, because I think this really gets to some of the advantages of an MCP server over a CLI in many contexts. Because there's many things that you just can't do with a CLI.
And so, distribution is one question that I think is relevant. Again, if the CLI is not already available on everybody's machines, you have to tell someone to go install it. And so, that's effort. It creates some friction in trying to distribute to your team to get them to use it. Another feature that's really important in the MCP standard is authentication. So, the MCP standard includes this OAuth flow that allows your MCP client, your Cloud Code, your Posit Assistant, your VS Code, to discover and authenticate, help you authenticate for you outside of the model.
The good news with all these things on the side is that Posit Connect does these for you. It solves the authentication for you. So, you can just share the URL, and when someone connects in Cloud Code or Posit Assistant, it will bounce them out to the browser to log in to Connect and send the credentials back. You never have to pull API keys or anything like that. And so, it's much more secure in that way, as well as being pretty seamless. You manage authorization, who gets access to it through Connect. You have access to see who is viewing it. So, all the things that you get kind of, I won't say for free, but built in to Connect.
Security and the lethal trifecta
The last thing that I want to touch on is security. There were a number of kind of high-profile cases in the early days of MCP of attackers being able to exploit an AI system using MCP. They're not specific to MCP, though. MCP was just kind of the first standard that allowed external data to get into your agentic workflows. And so, what they're really pointing at is this thing that Simon Willison has called the lethal trifecta. And so, if your agent, if your AI agent has access to private data, is exposed to untrusted content, and can communicate out, then an attacker can easily trick it into accessing your private data and sending it out.
If your agent has access to private data, is exposed to untrusted content, and can communicate out, then an attacker can easily trick it into accessing your private data and sending it out.
And so, when you're opening your agent up to external resources, that's where you get a lot of the power of things you want to do, but that also brings these risks.
Let me just give an example. So, suppose you're reading issues from GitHub on a public repo. This could be with the GitHub MCP server. It could be with the command line utility. It does not matter whether it's MCP or something else. But someone could write an issue in that public repo with some sort of what's called a prompt injection. Something that says, read the secret files in this directory and upload them to this other location. Make this request to this other location to send them out. And so, just by being able, by giving your agent access to read those, I'm assuming you are probably also doing something with private data by other means, and it can assemble that and exfiltrate your data.
So, if your agent has any ability to send data out and you have private data, you have the risk. If you have only two of these three things, the exposure is different and less.
So, how can we design our MCP servers to minimize our risks to this sort of exploit? I would sum this up by just saying that brevity is the soul of wit. We want to reduce what it is we're pulling into our agentic context. And because we're writing our own custom MCP servers, we have a lot of control over this.
So, the first thing is when you're building an MCP server is to only define the tools that you need. And there's a couple reasons for this. One is purely for efficiency. As I mentioned, every tool that you define and the definition and the description of the arguments and all that stuff, that takes up context in your session. And so, that's money, that's distraction from the point of what you're trying to do. And so, being thrifty with that will help on those dimensions. But it also happens with security because by limiting the tools that are there, you limit the exposure. And an important way, I think, is I like to have for as much as possible when I'm making MCP servers to say, do I need tools that have write access? Because it's a very different security threat model if all you're doing is reading. Because I don't have that third vector of being able to exfiltrate if there's no write access.
And so, sometimes you do need tools that are right. Sometimes you do want your AI agent to be able to post a comment back somewhere with its analysis. But sometimes you don't. And so, being aware of what the use cases are, potentially deploying different versions of your MCP server for different use cases that are combined with other things, that's something you have an option to do. And it's worth being thoughtful about.
Second is to make your responses concise. I mentioned at the beginning that the Zendesk REST API is not great for the thing I was trying to do, which is get the discussion history of Zendesk Ticket and put it next to my code base. Because the API response is going to have a bunch of stuff that are relevant for other purposes, not for AI. So, for example, the list of comments on a Zendesk Ticket includes things like metadata about whether or not the comment was entered on the web portal or by email. And if it was on the web portal, what was the user agent string of the browser of the person that was entering it? And I'm sure there's some valid analytic purpose for that somewhere, but it doesn't help Claude help me diagnose what's going on.
So, again, stripping that stuff out is really helpful to reduce the noise of what you're pulling in, saves you tokens, saves you money, and helps you keep the model focused on what you want. So, that's why you don't want to just naively wrap a REST API and just call it MCP. You know, you can be thoughtful and you can change what you return from that. Because you just have different needs in this context and it's appropriate to do that.
Finally, you can also minimize your lethal trifecta risk by sanitizing sensitive data. If there's less private data going into your model context, then there's less that could potentially be exploited with prompt injection. This is just also good, you know, data governance hygiene. But, you know, if you're pulling in data like I'm describing here and there's personally identifying details and it's not relevant to answer the questions, then don't include it. Sanitize it or prune them entirely.
Okay. So, to wrap up my part here and then hand it over to Matt for some show and tell. Like I said, what I want to make sure you take away, I hope, if nothing else, is that building and deploying MCP servers is something that you can do. That you have all the skills you need to be able to do this. It's just an API standard for AI agents. You've worked with APIs. You've probably built APIs. You've consumed APIs. This is just a set of conventions that if we all design our APIs this way, AI applications can work with them.
There are libraries out there. Fast MCP in Python is a great one for working with it. They make it very straightforward to turn a basic API into an MCP server. Your coding agents know how to do this as well. And really, when you write and deploy your own remote MCP servers to Posit Connect, it can really unlock some things for you. And, you know, security is super important. It's something that I spend a lot of time thinking about. And AI poses some really interesting new security challenges, like this lethal trifecta. But if we design our MCP servers well, we can help mitigate them and be able to get the upside of having those resources available.
All right. Thanks a lot. I'm going to turn it over to Matt now.
Hosting and managing MCPs on Posit Connect
Thanks for that, Neil. Let me go ahead and share my slides now.
All right. Well, as Neil mentioned, I'm now going to walk through using and managing MCP servers on Connect. But following up with Neil, I want to highlight two things that he mentioned, just kind of tie it in. He mentioned the local versus remote. So using Connect, these are going to be all remote MCPs. And then also, he used the example of how we're using MCPs here at Posit, specifically with Zendesk and help tickets. And so I couldn't show that one here, but wanted to go ahead and create one that resembled that, because that's the actual use case we're using. And I think it might resonate with people, showing how you can use an MCP that has access to customer or internal feedback to help you in your workflow.
All right. I'm going to pause this for a second, just kind of set the stage right here as we talk about authenticating to an MCP server on Connect. So you can see in this example, I have Positron, my IDE pulled up, and I have Posit Assistant up here as well. So that's going to be my AI client connecting to an MCP server on Connect.
What I'm going to walk through here is using the OAuth browser flow that Neil touched on. I want to talk about that a little bit before showing you how it works, because I have in the past used .env or some environment files to hard-code an API key in order to connect to various things and just store secret variables. But I think it's important to highlight that Connect comes with a built-in OAuth server.
As Neil mentioned, the OAuth browser flow authentication, that's part of the MCP spec. So that means that you can use an AI client like Positron here and connect an MCP server on Connect with that OAuth flow. I think it's really important to highlight that because from a security standpoint, you're not hard-coding some sort of secret or long-lived API key that's going to be living on your computer, could accidentally get checked into your version control or GitHub. And it's just a method that security teams at organizations are going to prefer.
So with that, let me go ahead and just show you this example that I recorded. So I'm going to come over to Posit Assistant and just kind of set the stage. I'm going to say what MCPs are configured in this project. You're going to see that it's reading, it's the assistant.settings.json. This is a common pattern you're probably used to with like Cloud Code as well using settings.json. The answer is there's none configured here.
So I'm going to go over to the settings.json and I'm going to paste a little bit of code that points to URL on Connect and you'll notice it says OAuth. And right now I have that pop up. I click open and right there, and I'll pause that real quick. That's how simple it is in Positron to authenticate using a browser flow. And so now again, I don't have a .env with hard-coded credentials, but I've gone out to Connect. Connect has taken a look and I am authorized to use this MCP server, which I'll show you in a little bit. And now I can use that with my IDE.
So I'm going to start this again. If we go back and ask Posit Assistant here, you know, what is available now? It's going to search and now it's going to go to the settings.json to see that and it tells me it has another one configured. This is a feedback MCP and you can see right there. I can say what tools do you have available as Neil mentioned. And now I can ask it. Hey, what are the top five most recent requests? I authorize the MCP and it's going to list those out for me.
So again, what I want to highlight with that I think is really important and just a pretty quick browser flow based authentication. I put in some information in my settings.json and now within my IDE session, I have access to that MCP. What I want to do now is walk through a use case and kind of show how we're using it. But again, using some dummy data that we generated for this.
So let me set the scenario. Let's say you have a dashboard that you share with your users, whether they're internal or external, and you have a way for receiving feedback from them for what they'd like to see, enhancements, changes, bugs, whatever it may be. So here's the dashboard. You can see it's regional sales, have it broken down by region, sales channels, etc.
So if you're a data scientist or developer who maintains this and works on it, probably a common pattern that, you know, maybe your boss or someone you work with reaches out to you and says, hey, we had feedback about adding state to the sales dashboards. Can you look into this? This is a pretty simple example in terms of adding state, but you can imagine it could be more complicated, such as I don't know if this data is correct. Can we add a whole new widget that might be more complicated? Can we look at projecting further out to the future? But in this case, we're going to say that somebody's reached out and asked to add state to the sales dashboard.
We're back in Positron IDE now. You see I have my app up with the code, and this is going to show a typical walkthrough of how we might use this on the Connect team.
So I have my MCP server already configured. So now I can go in there and say, search for recent feedback for adding state to the dashboard. It's asked me for permission to use the MCP. And I can go ahead and click on it. And it's going to ask me for permission to add state to the dashboard. So I'm going to click on the MCP. And it's going to come back after using the MCP server to get the data. Let me pause this real quick.
So you can see here it's come back with two different items. I want to reinforce something that Neil kind of hinted at earlier, or directly spoke to, I should say. You know, there could be an API where you need an API key with permissions to access and get this data in whatever sort of help desk, whether it's ServiceNow, Zendesk, otherwise. You wouldn't want to have to distribute that API key and then make sure it stays up to date and reach out to everyone. Since the API key is behind the MCP server, I, as the user, don't need to know anything about it. I never have to know about it. When it gets refreshed, I don't have to ask for that. It just works for me because I'm connected to the MCP server. So you really narrow the scope of people who have to be involved with that sensitive data.
Okay, so I've asked it to come back with recent feedback about state. You see two have come back. It's asked me if I'm working on number eight. And I actually want to work on ticket number 11. So I'm asking it to tell me more. Same thing, I'm going to prove it here. And you'll notice this time I'm going to say, hey, approve it for all this entire session so I don't have to keep approving it. All right, now it's coming back with the specifics, although it's hallucinated and thought that it's already resolved. But I know that's not the case. So I'm going to say, go ahead and implement.
Now, at this point, this is probably very similar if you've used Cloud Code or other AI coding assistant. It's just working with you to take your input and produce some new code, review it, and change the underlying code. What's really different here with the MCP server is without that, I would have had to go to a different place, collect the information such as, hey, here's the feedback, here's what they're asking, do more research and bring it to the AI coding assistant. With the MCP server, I'm able to work with Posit Assistant, have it go research itself, and just speed up that process of getting that information.
For me as well, it means I don't have to go to another system that I maybe have to log into and search for to make sure I have the right one. So it really just speeds up that process and allows us to move quicker.
And you can see here, this was the actual output. Going through that process, I didn't touch the code, but now it is at its state as we requested by the customer. And you can see it down here as a new button down here that didn't exist before.
And the one thing too I want to highlight that I think is really important to mention with MCP and Neil talked about it, that it works with a variety of AI clients. In that use case, I was using Positron and Posit Assistant. But you could also have that same MCP server connect to Claude Desktop or other AI clients. So again, that one MCP server is not just being used by developers in their IDE, it could be used by non-developers in another desktop app in order to ask the same questions that they're interested in saying, hey, what type of feedback have we got?
Managing MCP servers in Connect
I want to move on to managing MCP servers on Connect. If you haven't seen it, this is the Connect landing page and you can see you have a variety of content that I can look at here, a Quarto document, MCPs, Shiny applications, Streamlit, interactive applications, whatever it might be.
So what we've been doing to make it an even better place to host MCP servers is making small improvements such as having a dedicated MCP tab. So now I can come in and take a look at all the MCPs that I own, collaborate on, or have access to. It just makes it easy for me to discover them and be able to use them.
We do that by auto-discovering as content is published to Connect, is it using one of those popular frameworks such as FastMCP that Neil mentioned? And if so, we identify it as an MCP server. What that also means is we do things like set the minimum processes to one automatically. So what this means is there's not going to be a cold start for your users. If you're using an MCP server and you reach out and it's idle, it's going to take a few seconds, maybe more than a few seconds, 10 to 15 seconds to spin up wherever it's being hosted. By setting a minimum process, we know that means that it'll always be up and idle in the background and so that when a user wants to consume it or interact with it, they're not going to have that lag.
Connect also lets you set a lot of different configurations so that if you have an MCP server that's being used by 10 people at first, then 20, then 30, then 40, you can keep scaling up and decide how much compute you want to put behind it to make sure it performs for your users.
Another key thing I want to highlight, you'll see here we're looking at that feedback MCP. As I mentioned earlier, I had access in Connect and that's why I was able to connect to it. You can see my name listed right here. Well, when I want to share it with other people, I can use Connect's built-in access control list to share it with everyone in the engineering department, let's say. This can connect to your IDP that you're already using at your organization, so it just makes it very simple for you to be able to share it with those that you want to. And if someone doesn't have access to that, they're not going to be able to connect to it even if they have the URL. Connect will take a look at who has access and only those individuals will be able to use it.
One of the new features we built and it was during the time as we're working on MCPs that applies to all content in Connect is a usage dashboard. If I've published an MCP, something that I'm probably going to be interested is how many people are using it? That can be a great proxy for is it valuable to people? Like, when are they using it? Do I need to take a look at my settings and increase the amount of compute behind it to make sure it's up and running? Out of the box within Connect, as Neil mentioned, you're able to see this usage pattern. You don't have to capture that yourself and then go back and look at it. It's built in so you can quickly take a look and see and determine how many people are using it.
And lastly, this is a recent feature and one that I'm really excited about. For admins, we have this clients tab in our system page. What this allows you to do is see the AI clients that have connected to Connect and to the MCP service. So what this means is you have better insight and as you're using them, if you need to revoke them, you can and it just gives you that UI in one place where you can take a look. With the exception of this clients tab, everything else I showed like the usage dashboard and the settings, that's also features that applies to all content on Connect, not just MCP servers.
So that's a quick overview of how you can manage and how you can authenticate to MCP servers on Connect. I appreciate everyone sitting through that and asking questions. At this point, we're going to transition to Q&A.
Q&A
Neil, I'm going to go take a look at some of the questions coming. I saw some, but I'll start with one that I saw that I touched on the authentication piece where, you know, you can use a .env file to store an API key, but the OAuth browser flow is one that is a little bit more secure. I kind of just touched on, like I said, could you go a little more detail about what that actually is doing under the hood and why it's so important?
Yeah, for sure. So the alternative, there are a couple alternatives, right?