How an AI application authenticates to a third-party service via MCP, in the ideal case, then the two cases where it gets complicated.
The Ideal Case: The Service Publishes Its Own MCP Server
1. The app contacts the MCP server, which responds with where to get a token. 2. The user logs in on the service's own page: the app never sees their password. 3. The service issues a token scoped to this server and to the rights accepted. 4. The app presents this token on every call. 5. The MCP server acts with the user's rights, provided it's correctly implemented: it's the one that enforces the boundary. The dashed arrow only exists in enterprise settings (the "Enterprise-Managed Authorization" extension, aka Cross App Access).
Third-party serviceHosts the MCP server and reuses its existing authorization server.
DeveloperIntegrates a standard MCP client. No service-specific code, no passwords.
UserLogs in and accepts the requested rights. Nothing else.
ITSets in one place which apps can access which tools.
Complication 1: The Service Has No Official MCP Server
Two nested authorizations, and one more party to trust. MCP doesn't handle token #2: it only forbids reusing token #1 against the service. Each intermediary server fends for itself, with regular OAuth in the best case, a plaintext API key in the worst.
Complication 2: On Whose Behalf Does the AI Act?
Chat started by a user
Autonomous agent
Who's present
The user, who sees what the AI does
No one
Identity used
The user's own, via the connector they authorized (access often persists beyond the conversation)
Either a user token refreshed in the background, or its own identity (service account)
Main risk
Accepting rights without reading them
An old authorization still being used for actions no one reviews anymore
MCP support
Well covered
In progress Enterprise-managed authorization extension, agent identities at Okta and Microsoft. The practice is still immature.
In both cases, IT controls the application (which software, which tools) and the user their own rights. In principle, the AI never exceeds the intersection of the two; in practice, it depends on how rigorous the servers are and on the rights granted.
Common Pitfalls and Paths to a Fix
As of September 28, 2026. Each pitfall is followed by its fixes, with their status.
Shipped available (spec or products)
In progress proposed or rolling out
Best practice yours to apply
Open no fix in sight
Designing a Server
Copying Your API As-Is80 routes become 80 tools: the AI gets lost and chains five calls for a simple task.Best practiceDesign tools around tasks. Lock in frequent call chains as declarative workflows (Arazzo plus an open-source engine) or as composite tools written in code.In progressArazzo 1.2: a step could directly call an MCP tool or a command.
Oversized Responses2,000 lines of JSON saturate the context and degrade responses.Best practicePagination, filters, summaries, AI-readable errors. Return only the fields that matter (Arazzo 1.1's Selector allows this).Best practice"Code mode": the AI filters the data in a sandbox before reading it.
Long-Running OperationsA multi-minute export ends up timing out.Shipped"Tasks" extension (July 2026): the call returns immediately, the client then tracks progress. Client adoption still to watch.
Deploying at ScaleSessions didn't play well with load balancers and serverless.ShippedStateless protocol since the July 28, 2026 version, routing via HTTP headers, cached tool lists. Server and client migration is still pending.
Usage
Incomplete ClientsMany only handle tools: a server works in one client and not another.ShippedThe spec has refocused: little-adopted features deprecated (sampling, roots), new features shipped as optional extensions.Best practiceTest against the clients you actually target.
Non-Deterministic BehaviorThe model chooses which tool to call, with no guarantee of the outcome.Best practiceEvaluations against real scenarios. Lock critical call chains into a workflow.ShippedA server can request confirmation mid-call before a sensitive action.
Painful DebuggingA vague description, a conflict between servers, transport, or the model's own choice: the logs are scattered.Best practiceMCP Inspector during development, a gateway that traces every call in production.In progressTraceability is on the 2026 roadmap's "enterprise" workstream, still loosely defined.
Hidden Context CostEvery connected tool eats up space before the first question is even asked.Best practiceConnect fewer servers. Choose clients that load tools on demand (tool search), or go through "code mode".
Security
Tool PoisoningA tool description can hide instructions the AI follows and the user never sees.Best practiceOnly install servers from trusted publishers, review descriptions, filter through a gateway.OpenThe protocol only offers recommendations, no actual protection mechanism.
Changes After ApprovalAn approved server later changes its tools. The user isn't necessarily notified.Best practicePin server versions, have a gateway detect description changes.OpenThe protocol flags that a tool list has changed, but doesn't require re-approval.
Combining ServersWhat Simon Willison calls the "lethal trifecta": private data + untrusted content + a way to send data out: each server is fine on its own, their combination enables the leak.Best practiceNever bring all three together in the same session. Require human confirmation before any outbound send.OpenEntirely up to clients and gateways.
Ecosystem and Governance
Trust in ServersNothing guarantees that a server found online is trustworthy.In progressOfficial MCP registry for discovery.OpenNo certification, no systematic audit.
"Shadow MCP"Servers installed by employees without IT's knowledge.ShippedEnterprise-managed authorization MCP extension (Cross App Access). Agent identities available at Okta (Agent SSO, August 2026) and Microsoft (Entra Agent ID). They only cover servers that go through the directory: a local server quietly installed on the side slips past them.Best practiceA single MCP gateway that filters, traces, and enforces the rules.OpenOperational discipline: agents with no owner or expiration date, rights that keep piling up.
MCP Isn't Always NecessaryFor developer use, a command line or API doc is often enough. It's a debate, not a consensus.Best practiceReserve MCP for cases where it delivers standard authentication, governance, or access from consumer-facing clients.