MCP adoption is moving from novelty to durable developer usage

At a glance

What this is: This article argues that MCP adoption in Cursor is now showing durable weekly usage, with one-click install and OAuth support marking the turning point and context-rich servers driving repeat use.

Why it matters: IAM and NHI teams should read this as evidence that protocol convenience is now an access-governance issue, because durable AI tool use depends on how identities, context, and data sources are connected.

Context

Model Context Protocol adoption is moving beyond experimentation and into repeat operational use in developer tooling. In Cursor’s case, the article says usage patterns changed materially once the client became easier to install and authenticate, which made MCP less of a novelty and more of a dependable workflow layer.

The governance question is not whether developers can connect tools, but how those connections are controlled when external context becomes part of everyday execution. For NHI and agentic-AI programmes, MCP matters because it creates a structured path between identities, data sources, and actions that now has to be governed as part of normal access design.

Key questions

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Why do one-click install and OAuth support change the risk profile of MCP?

A: They reduce the friction that normally limits adoption, which means more users can connect more tools more quickly. That increases the chance that access paths, scopes, and data sources spread before governance catches up. The risk is not OAuth itself, but the speed and scale at which trust can now be attached to workflows.

Q: What are the signs that MCP usage is becoming operationally embedded?

A: Stable weekly usage, repeated reliance on the same servers, and expansion from single-purpose tools into documentation, database, browser, and project systems are the clearest signals. When those patterns appear, MCP has crossed from experimentation into workflow dependence, and it should be managed like an ongoing control surface rather than a test integration.

Q: Should teams prefer MCP servers that provide live context or synthetic examples?

A: For implementation work, live context is usually more valuable because it exposes versioning, edge cases, and real data relationships that synthetic examples can hide. The trade-off is governance: live context also increases the sensitivity of the connection, so teams need tighter scope review and clearer data boundaries.

Technical breakdown

Why one-click install changed MCP adoption

MCP adoption is sensitive to friction because every additional setup step creates another point where developers abandon the flow. One-click install removes a packaging and onboarding hurdle, while OAuth support turns a manual trust decision into a repeatable authentication pattern. Together, those changes lower the cost of first use and make continued use more likely. In governance terms, the protocol is not just a transport mechanism. It becomes an access pathway whose ease of connection directly affects how widely it spreads across tools and teams.

Practical implication: treat onboarding friction and authentication design as governance variables, not just developer-experience details.

Why context-rich MCP servers win adoption

The most-used servers in the article cluster around documentation, databases, browser state, design assets, and GitHub context because they solve the same problem from different angles: they supply the missing runtime context an LLM cannot infer reliably on its own. That matters because context is what turns a generic assistant into a useful workflow tool. The underlying pattern is that developers do not adopt MCP for abstraction alone. They adopt it when the server returns the specific context needed to act safely and accurately inside real work.

Practical implication: prioritise MCP servers that supply high-value context tied to a clear task boundary and data source.

How stable usage changes MCP governance

Stable weekly usage is the point where MCP stops being an experiment and starts becoming part of operational access posture. At that stage, inventory, authorisation boundaries, and data-source trust all become persistent governance concerns. The article’s usage trend suggests that developers keep returning because MCP reduces the distance between intent and execution. That is useful, but it also means the protocol can accumulate privileged reach quietly if teams do not govern which tools, datasets, and actions are connected behind the scenes.

Practical implication: inventory MCP-enabled tools and review their data and action scope as part of normal identity governance.

NHI Mgmt Group analysis

MCP adoption is now a governance signal, not just a product signal. Once a protocol moves from trial use to stable weekly use, the access problem changes shape. The issue is no longer whether developers will try it, but which tools, data sources, and action paths become part of routine execution. Practitioners should treat that shift as an identity boundary problem, not only a tooling trend.

Convenience is becoming part of the trust model. One-click install and OAuth support do more than improve uptake. They collapse the distance between intent and privilege grant, which means the control plane has to account for how quickly context can be attached to an identity session. That is a governance change, not merely a usability improvement.

Context breadth is the real adoption filter. Documentation, database, browser, design, and GitHub servers are popular because they provide immediate operational value in different parts of the workflow. The named concept here is context attachment surface: the set of external systems an MCP-enabled identity can draw into a live task. That surface now deserves explicit inventory and review.

Durable usage exposes the limits of novelty-based oversight. Early curiosity can hide weak governance because little is repeated. Stable usage creates repetition, and repetition creates operational dependence. The implication is straightforward: if MCP is becoming a normal developer control path, then authorisation, logging, and least-privilege reviews need to follow the same maturity curve.

MCP will increasingly test whether identity programmes can govern tool-bound context, not just user access. Traditional IAM assumes access is granted to a person or service and then reviewed against a known boundary. MCP blurs that boundary by attaching live context to execution. Practitioners should expect this to pull NHI governance, application trust, and developer workflow controls into the same conversation.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: MCP Security Guide

What this signals

Context attachment surface: MCP is turning external documentation, data, design, and repository sources into part of the live execution path. That means governance has to track not only who can connect, but which systems the connection can expose inside a task.

Stable weekly usage is the point where a protocol stops being a pilot and starts becoming part of identity governance. At that stage, the question is no longer whether MCP works, but whether the organisation can inventory and constrain the access paths it creates.

For practitioners

• Inventory MCP-connected tools and data sources List every server, connector, and context source currently reachable through MCP-enabled workflows, then classify which identities can invoke them and what data they expose.
• Review OAuth trust boundaries Check how OAuth scopes are granted for MCP access and whether the scopes match the minimum context needed for each server, especially for database and repository integrations.
• Set explicit server allowlists Define which MCP servers are approved for production use and block ad hoc additions unless they pass the same review as any other privileged integration.
• Monitor high-value context paths Watch for MCP paths that pull live data, rendered browser state, or design assets into agent workflows, because those are the connections most likely to widen blast radius.

Key takeaways

• MCP is crossing from novelty into repeatable workflow infrastructure, which makes access scope and tool inventory more important than feature curiosity.
• The practical adoption drivers are friction reduction and high-value context, especially where live data improves task accuracy.
• Security teams should govern MCP connections like durable access paths, with explicit approval boundaries and regular review of the servers and data sources involved.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Context Attachment Surface: Context attachment surface is the set of external systems and data sources an MCP-enabled workflow can pull into a task. The larger the surface, the more carefully teams must govern inventory, authorisation, and data exposure, because each added connection can expand operational trust.
• OAuth Scope: An OAuth scope is a permission string that defines what an application can do on behalf of a user. In practice, scopes set the blast radius of delegated access, because the token carries the right to read, write, or administer resources until it is revoked or expires.
• Workflow Dependence: Workflow dependence describes the point at which repeated use of a tool or protocol becomes part of normal operational execution rather than an experiment. For MCP, this is the stage where governance must shift from onboarding approval to ongoing review of tools, data paths, and access boundaries.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.