Back to blog
The age of agent experience: now with MCP servers
Auth & identity
Jun 4, 2025
Author: Julianna Lamb

Revisiting our thesis on agent experience
Back in February, we wrote about the dawn of the Agent Experience (AX)—a new design paradigm emerging alongside the rise of AI agents like ChatGPT Operator, Cursor, and Claude Code. These agents aren’t just generative tools; they have agency, navigating interfaces and executing tasks on behalf of users. Our early thesis: just like humans, agents need secure, seamless ways to access data and take actions. Designing for AX would require no longer just thinking about developers as your user, but also agents. And with this comes the challenge of identity, access, and authorization for agents.
We advocated then, and still do, for OAuth as the gold standard for agent authentication. At the time, one key piece was still missing: a standardized, scalable way for agents to access external systems over the internet, beyond browsing and scraping.
That missing piece has arrived.
The MCP breakthrough: a standard for agent interoperability
The Model Context Protocol (MCP) is rapidly becoming the standard protocol for AI agents; in recent weeks, Google, Microsoft, and OpenAI have all launched first class support for MCP. It’s standardizing how agents interact with APIs, tools, and workflows across the web. Initially built for local servers, the release of remote MCP servers has opened the door for agents to connect to any internet-accessible application, so long as they offer an MCP server.
But this evolution brings new challenges. Agents needed a secure, user-authorized way to act on behalf of humans in these remote systems. Without it, we risk falling back on inefficient or insecure practices like sharing API keys or over-permissioning agents with blanket credentials.
MCP servers, and why they matter
MCP servers are the bridge between AI agents and external tools. They interpret requests, handle tool execution, and now, thanks to recent MCP spec updates, support OAuth 2.1-based authorization for remote access.
This unlocks a future where:
- Any AI agent can discover and register with any MCP server in real time
- Users can grant granular permissions through familiar OAuth flows; no password sharing, no opaque access
- Applications can audit, monitor, and revoke agent activity like any other OAuth-based third-party integration
- Developers don’t have to reinvent the wheel, MCP servers plug into a growing ecosystem of tools, languages, and agent platforms
You might be asking, why are MCP servers the answer to agent experience and not existing REST APIs. There are two challenges with existing APIs that MCP and OAuth solve out of the box. The first is the MCP protocol vs REST API protocol:
- REST APIs are designed primarily for human developers to integrate with manually, they assume human context, static documentation, and hand-written glue code.
- MCP is built for autonomous agents. It provides machine-discoverable metadata, a standardized contract for tool invocation, and predictable flows that agents can navigate dynamically.
- Because MCP is purpose built for agents, that enables flows totally outside the scope of regular REST APIs. For example, the draft version of the MCP spec implements elicitation, allowing MCP servers to ask clients to dynamically create UI and ask users questions on the fly.
- Unlike REST, which varies widely in implementation and structure, MCP enforces consistency. That means no more worrying about query parameters or body parameters, XML, HTML form post, etc. With MCP, everything is a JSON RPC; every server behaves the same way, reducing agent-side complexity and increasing interoperability.
Second, API key auth presents many challenges to overcome that OAuth solves for, such as:
- API keys are by default static, hard to rotate, and don’t have a standardized way of scoping effectively, and while you could build around this, for it to solve the agent use case, it would need to be consistent across APIs so that agents have a standard pattern and format to interface with. We’ve had REST and OpenAPI for decades and they are still used as patterns and suggestions versus a true standard.
- API keys typically lack user context and don’t enforce per-user permissions, and while you could design API keys to solve for this, OAuth already presents a standardized and widely adopted way of doing so.
In contrast, OAuth and MCP servers give us:
- Scoped, revocable access
- Transparent user consent and visibility
- Seamless onboarding for agents via dynamic client registration
- Greater interoperability with the consistency that MCP enforces
- The ability to treat agent actions with the same level of scrutiny and control we apply to human users
MCP servers have the potential to be groundbreaking for agents, I’d go as far as to say that MCP servers are to AX what REST APIs were to DX.
How OAuth and MCP servers work
OAuth is a widely-adopted protocol designed to securely facilitate authorization between services on the internet, there are a multitude of applications for it such as 3rd party integrations, device authorization, session sharing across domains, and many more including remote MCP servers. At its core, OAuth revolves around three key roles:
- Authorization Server (Identity Provider): Validates the user's identity and issues access tokens
- Resource Server: Holds the protected data or resources, granting access only if the request includes a valid access token
- Client: An application or agent requesting access to resources from the Resource Server by obtaining tokens from the Authorization Server, inheriting permissions explicitly granted by the user

In the context of MCP servers, this translates clearly:
- MCP Clients act as OAuth Clients, requesting permission and obtaining scoped access tokens
- MCP Servers function as OAuth Resource Servers, providing protected data or tool access only upon verifying valid access tokens
- OAuth Authorization Servers, your application needs to become one, this is where Stytch can help turn your app into an identity provider and manage identity validation, token issuance, and consent management
When a user authorizes an MCP client, i.e. the agent, the OAuth flow ensures:
- Access tokens are scoped explicitly, restricting permissions to only the actions approved by the user (e.g., granting the "read:docs" scope but denying the "edit:credit_card" scope).
- Access is dynamically adjustable, revocable, and transparent, with detailed audit trails and logging to monitor activity.
This structured integration ensures that users and developers enjoy a seamless, secure experience, making it easier to adopt agentic workflows instead of having to manage cumbersome connection experiences involving static API keys or environment variables, which often lead to insecure practices or complicated UX. OAuth is an accessible and well understood pattern, API keys and env vars are usable only by deeply technical users. To make it easy for anyone to use agents, we need to build experiences that are accessible to technical and non technical users alike.
Make your app agent ready: Stytch + MCP servers
At Stytch, we’re helping developers become agent ready by making it easy to secure remote MCP servers. Our Connected Apps product enables any app to become an OAuth compliant identity provider, meeting MCP server requirements out-of-the-box. We handle the complexities of:
- Consent flows: allow the user to grant and revoke access to specific scopes and permissions
- Dynamic client registration: allow agents to register as a client of your MCP server on demand
- Audit logging to understand who is taking a given action (agent or human), which agents have access to your app and with which scopes and permissions, and more
- The complexities of token issuance, refresh, revocation, and validation
- Role-based scopes and human-in-the-loop approval paths
This means developers can focus on building AI-powered workflows, without having to build complex auth infrastructure and stay up to date with the latest updates to specs and protocols.
The revised AX thesis
Our original thesis was that designing for agents means making your APIs agent-friendly, consent-driven, and OAuth-secured.
But with the adoption of MCP servers, designing for agents also means exposing your product via MCP servers—standardized, discoverable interfaces that any AI agent can connect to, with authentication powered by OAuth.
The new AX stack is: → Open, machine-parseable APIs → OAuth for agent authorization → MCP Servers for standard data and tool access
Looking ahead
We're still early in the agent revolution. But the landscape has shifted rapidly. In just a few months, the industry has gone from demos of agents to building real-world agent workflows with secure, scalable infrastructure.
If your product isn’t usable by agents via MCP and if it doesn’t support OAuth-based delegation, you risk getting left behind.
The good news? You don’t have to build it all yourself.
With Stytch Connected Apps, you can be agent-ready in days—not months. Whether you’re starting from scratch or integrating MCP into your existing stack, we’re here to help you become part of the open AX ecosystem.
Ready to build remote MCP servers? Get started here.
The future of the internet isn’t just human. It’s agent-driven—and it’s here.
Authentication & Authorization
Fraud & Risk Prevention
© 2025 Stytch. All rights reserved.