A clear view of the state of MCP across SaaS
This research explores how has MCP adoption changed across SaaS products in just one year.
Tracking 816 SaaS products and screening more than 23,000 entries in the official MCP Registry, Cyclr compared 2025 with 2026 to measure official adoption, server capabilities and category growth. Official adoption doubled, and the ability to run workflows grew almost five times faster than search.
Focusing on the shift towards AI assistants carrying out controlled actions, this report looks at which capabilities are growing fastest, and explores the six types of MCP server now emerging and the categories where demand is outpacing supply.
This report is built for product, engineering, security and go-to-market teams deciding whether, and where, MCP belongs on their roadmap. It shows why the leading vendors set clear limits on what AI assistants can do, and why 57% of SaaS products still have an opportunity to lead their category.
Read the full report below or download your own illustrated PDF version.
The Report Looks Into:
- How official MCP adoption grew across SaaS between 2025 and 2026
- The shift from access to controlled action
- Which SaaS categories are adopting MCP fastest
- How hosted servers are becoming the commercial standard
- The six types of MCP server now emerging across SaaS
- How leading vendors set clear limits on what AI assistants can do
- Where community-built servers show customer demand
- How 57% of the market is still open for MCP
About this report
MCP has crossed from access into action
This report looks at how SaaS companies are adopting the Model Context Protocol (MCP).
MCP is the open standard that allows AI assistants to connect to other software products.
The research covered 816 SaaS products and screened 23,830 active entries in the official MCP Registry.
It compares 2025 with 2026, looking at how many products now offer official MCP support, what their servers allow AI assistants to do, and where customer demand is ahead of what vendors provide.
Who this report is for
- Product leaders deciding whether MCP deserves roadmap investment
- CTOs and architects choosing a delivery model
- Security teams defining control boundaries
- Go-to-market teams determining how MCP should be positioned and measured.
Executive summary
MCP has crossed from access into action
Between 2025 and 2026, the number of products with verified official MCP support rose from 47 to 100. This was measured within the same group of 816 products, and the share offering official support rose from 5.8% to 12.3%.
The more significant change is in what these servers do. The ability to run workflows and carry out operational tasks grew considerably faster than the ability to search for and retrieve information.
| CENTRAL CONCLUSION MCP is becoming a governed execution layer for SaaS products. The opportunity is not to expose more tools; it is to expose safer, more valuable outcomes. |
Five findings:
- Official adoption roughly doubled: 47 to 100 target-product IDs.
- Execution is the fastest-growing capability: official implementations documenting workflow or operational actions rose from 10 to 21 (+110%).
- Hosted delivery and OAuth are becoming the commercial pattern: customer-facing servers increasingly use managed remote endpoints and per-user authorization.
- Execution is bounded, not unrestricted: leading products add scopes, inherited permissions, confirmations, safeguards, rate limits and auditability.
- Most of the market is still open. 57% of the total number of businesses had no verified official MCP server.
How the market changed
Growth is spreading beyond developer infrastructure
Developer tools and DevOps still lead, but MCP adoption has expanded into databases, CRM, sales, collaboration, messaging and product operations. This shows MCP shifting from a developer convenience toward a general product interface for operational teams.
Category implications
- Developer and infrastructure products remain the adoption center, so expectations around OAuth, remote hosting and operational tooling are being set there.
- Business categories are now credible MCP launch markets, particularly where users already act through AI assistants or repeat multi-step workflows.
- Category presence alone is not differentiation. The better opportunity is a distinctive, governed outcome that uses product context competitors cannot easily reproduce.
Where official adoption grew fastest
| Category | 2025 | 2026 | Change |
|---|---|---|---|
| Developer Tools | 5 | 17 | +12 |
| DevOps | 6 | 14 | +8 |
| Databases | 2 | 8 | +6 |
| Sales | 0 | 5 | +5 |
| CRM | 1 | 5 | +4 |
| Product Management | 1 | 5 | +4 |
| Collaboration | 4 | 7 | +3 |
| SMS | 0 | 3 | +3 |
What changed in product terms
- Databases became operational. Newer servers expose guarded query execution, schema inspection, performance insight and sometimes controlled writes.
- Business systems joined the market. CRM, sales, work management, SMS and content platforms increasingly let agents create, update, send, approve and schedule.
- Vendors split MCP surfaces. Hosted and local/CLI variants, read-only and full-access toolsets, and persona-specific servers are replacing the idea of one unlimited endpoint.
- Interactive output appeared. Charts, previews, tables and embedded interfaces create useful AI-client experiences without necessarily granting write access to the source product.
The changing anatomy of MCP
From context pipe to controlled execution layer
In 2025, most MCP servers acted as a pipe that fed product information to AI assistants.
By 2026, more of them allow assistants to carry out tasks within clear limits. Every capability grew, but the ability to run workflows grew fastest.
| Capability | 2025 | 2026 | Growth |
|---|---|---|---|
| Reading, searching and discovering information | 40 | 49 | 23% |
| Creating and updating records | 25 | 35 | 40% |
| Running workflows and operational tasks | 10 | 21 | 110% |
| Visual and interactive results | 1 | 6 | 600% |
| Hosted or managed by the vendor | 34 | 44 | 29% |
| Sign-in through OAuth | 28 | 36 | 29% |
| KEY INTERPRETATION The ability to take action grew faster than the ability to retrieve data, but unrestricted action did not. The dominant pattern is useful action within clearly defined rules. |
Server design patterns
Six server archetypes now visible
Looking across official servers, six broad types have emerged:
- Context and discovery servers search documentation, inspect product details, retrieve records and summarize the current state of the product.
- Record servers create or update specific items, such as tasks, contacts, pages, comments and campaigns.
- Workflow servers run pipelines, automations, approvals, scans, processing jobs and other multi-step operations.
- Infrastructure servers query or change databases, deployments, policies, cloud resources and development systems.
- Communication and transaction servers send messages, publish content, create payment records or take other actions with consequences outside the product.
- Interactive servers display charts, previews, tables or application screens inside a compatible AI assistant.
Design implications
- A single product may need more than one server archetype: a read-only hosted server for customers and a broader local or CLI surface for administrators.
- Tool boundaries should follow persona and risk, not merely the structure of the the product’s underlying API. Fewer, well-scoped tools also make servers cheaper and more reliable to run.
- Rich output can create differentiation without write access; execution depth and interaction richness are separate design choices.
Evidence in practice
Controlled action in practice
The strongest official servers let assistants take real action, but always within deliberate limits.
| Vendor | Design pattern | What it shows |
|---|---|---|
| CircleCI | Hosted server and command-line version, both in preview | The hosted server combines problem diagnosis with the ability to rerun and cancel jobs. The command-line version adds configuration, policy and administrative capabilities. CircleCI’s documentation recommends reviewing any action that changes something. |
| PlanetScale | Guarded database operations | Tools for reading data and tools for changing data are kept separate. Broad UPDATE, DELETE and TRUNCATE commands without conditions are blocked, and any change to the database’s structure requires confirmation from a person. |
| ClickUp | Actions without deletion | Task and collaboration tools support real work, but tools for deleting items are deliberately withheld as a safety measure. |
| Sisense | Visual results from a read-only server | Users can query governed data models and build interactive charts. The server itself remains read-only and applies each user’s existing permissions at row and column level. |
| Jotform | Two separate MCP experiences | A text-based server supports automation, while an MCP App displays previews, submission tables and galleries for visual work. |
| GitLab | Acts under the user’s identity, in beta | The server supports OAuth 2.0 Dynamic Client Registration, which allows AI assistants to register automatically. It acts under the user’s own authorization across GitLab.com, Self-Managed and Dedicated. |
Where the execution boundary sits
A commercial MCP server now defines four things at once:
- which tools the AI assistant can discover
- whose identity and permissions apply
- which actions require review or confirmation
- what is recorded once an action has been carried out
This makes MCP part of the product and its governance, rather than simply a technical connector.
Demand ahead of supply
Community implementations reveal strategic white space
A third-party server is not proof of vendor adoption, but it can be a useful demand signal.
Where several community implementations exist and no official server is verified, developers are already working around the absence of a supported product surface.
| COMMERCIAL IMPLICATION The opportunity is largest where customer demand is visible but official supply is absent — especially when the underlying product owns high-value context or repeatable workflows. |
How SaaS teams should read this signal
- Search community servers for repeated use cases. Repetition suggests unmet demand; one isolated repository may not.
- Interview users who adopted unofficial servers. Ask what task they were trying to delegate, what data they exposed and where trust broke down.
- Do not copy a community tool list wholesale. Use it as discovery input, then redesign around product permissions, tenancy and supported outcomes.
- Consider official MCP as a way to regain control of support, security, observability and product quality where unofficial access is already occurring.
Methodology
Research notes
Fixed research universe
Both periods (2025 vs 2026) use the same 816 target company/product IDs. The refreshed implementation table classifies every target exactly once. The research cutoff is 20 August 2026.
- Adoption counts use unique target IDs. Category charts use the Cyclr category on official implementation records and may include several records for one vendor.
- Endpoint, use-case and capability categories are not mutually exclusive. They measure documented supply, not usage volume.
Observed change set
| 39 retained official | 61 gained evidence | 8 removed / corrected |
Evidence hierarchy
- Vendor-official: first-party documentation, a vendor-owned repository or a publisher namespace attributable to the vendor.
- Third-party/community: a server integrates with the product, but vendor ownership or support is not verified.
- No official MCP found: no public first-party evidence was located by the cutoff; this does not prove private or unannounced work does not exist.
- Registry listings were discovery evidence, not automatic proof of official adoption.
