Top 10 MCP servers in 2026, and how to run them safely

A Model Context Protocol server is the piece of software that turns a product’s API into tools an AI agent can discover and call. By October 2026 there are thousands of them: the Agentic AI Foundation announcement in December 2025 already counted more than 10,000 active public servers. Most are thin wrappers that nobody maintains. A small number are run by the vendor whose system they expose, ship a hosted endpoint, and have been exercised hard enough by security researchers that their failure modes are documented.

This is a ranked list of those ten, for platform and engineering teams connecting agents to code, browsers, documentation, work tools, payments, production data and design files. It favours servers that are official, hosted, well scoped and widely adopted, and for each one it records what went wrong in public and what the vendor now recommends. The second half covers what does not live inside any single server: the current specification, the official registry, and how to run all ten behind a gateway so that credentials, tool lists and audit records are not scattered across laptops.

If you are choosing servers specifically for a coding agent, the companion piece on MCP servers for coding agents goes deeper on that use. If you are choosing the gateway, see the MCP gateway comparison.

How we ranked

Every server was assessed from its own documentation, repository and release history as of early October 2026, plus published security research. Six criteria, in roughly this order of weight:

1. Maintenance. Run by the vendor that owns the system, with recent releases. Community servers were considered, but none beat an official equivalent.
2. Transport. A hosted streamable HTTP endpoint scores above a local stdio process, because it centralises patching and removes long-lived tokens from developer machines.
3. Auth model. OAuth with scoped, revocable consent scores above personal access tokens or API keys in environment variables.
4. Tool scoping. Read-only modes, toolset selection and project scoping. This is the single most useful safety control a server can offer.
5. Security track record. Public findings, CVEs and the vendor’s response. A finding is not disqualifying; an unanswered one is.
6. Adoption and breadth. Client support, and how much of the underlying product the tools reach.

The ranking reflects general usefulness to a team that already uses the product. A Figma server is worthless to a team without Figma, so treat the order as a tiebreaker, not a shopping list.

The ten servers at a glance

1. GitHub MCP server

The GitHub MCP server is GitHub’s own, MIT-licensed, and one of the most adopted MCP servers of any kind. Version 1.14.0 shipped on 2 October 2026. It runs as a hosted endpoint at https://api.githubcopilot.com/mcp/, or locally as a Docker image or Go binary over stdio, with GitHub Enterprise supported through GITHUB_HOST.

Strengths. Breadth and scoping. The tools are grouped into 21 toolsets, including issues, pull requests, repositories, Actions, code security, Dependabot and secret protection. Locally you choose toolsets with --toolsets, individual tools with --tools, and skip every write tool with --read-only. The remote server exposes the same controls as URL paths (/readonly, /x/{toolset}) and headers (X-MCP-Toolsets, X-MCP-Readonly), so an administrator can hand out a URL that only ever lists read-only issue tools. Auth is OAuth through a browser login or a personal access token, and each tool declares the OAuth scopes it needs.

Limitations. GitHub is where the best-known MCP attack was demonstrated. In May 2025 Invariant Labs showed a “toxic agent flow”: a prompt injection planted in an issue on a public repository led an agent to read the user’s private repositories and publish their contents in a pull request on the public one. Invariant was clear that this was not a bug in the server code but a consequence of an agent holding a token that spans public and private repositories. GitHub’s later “lockdown” mode, which hides public issue content from users without push access, is described in its own docs as “a best-effort content filter, not a security boundary”.

Best fit. Any team whose agents touch code. Start with the remote endpoint, read-only, and one or two toolsets; widen only when a workflow needs to write.

2. Playwright MCP

Playwright MCP is Microsoft’s browser-automation server, Apache 2.0, and one of the most widely used servers on this list. It drives a real browser through Playwright and hands the model the page’s accessibility tree rather than screenshots, which makes interactions deterministic and cheaper than pixel-based approaches. The version line is still 0.0.x; 0.0.83 was released on 28 September 2026.

Strengths. It needs no vendor account and does one job well: navigating, filling forms, clicking, reading pages and generating tests. Capability groups switch on with --caps (vision, PDF, devtools, network, storage, testing), and --allowed-origins and --blocked-origins restrict where the browser may go. It is the reference choice for agents that verify their own front-end changes or reproduce bugs in a real page.

Limitations. It is the one server here that is still primarily local, by default a stdio process with an optional HTTP port, and it has no authentication of its own. The README states plainly that the server “is not a security boundary”. That was demonstrated by CVE-2025-9611, rated 7.2 (High) under CVSS 4: versions before 0.0.40 did not validate the Origin header, so a malicious website could use DNS rebinding to reach a locally running server. A browser controlled by an agent also carries the user’s cookies and sessions wherever it goes. Microsoft itself now recommends its Playwright CLI with skills over MCP for coding agents, calling it more token-efficient, and keeps MCP for long-running autonomous workflows that need persistent browser state.

Best fit. QA and front-end agents, and any workflow that has to operate a website without an API. Run it in a container or a dedicated browser profile, set allowed origins, and pin a version at or above 0.0.40.

3. Context7

Context7, from Upstash and MIT-licensed, solves a narrow problem that every coding agent has: the model’s training data is older than the library version in your lockfile. The server resolves a library name to an ID and returns current, version-specific documentation and examples, through two tools, resolve-library-id and query-docs. It runs as a hosted endpoint at https://mcp.context7.com/mcp or as the npm package @upstash/context7-mcp (4.1.1 at the time of writing), with an API key recommended and a free tier available.

Strengths. Small surface, large effect. Two read-only tools are about as low-risk as an MCP server can be in terms of what an agent can do with it, and the token cost of loading its definitions is trivial compared with servers that expose dozens of tools. It reduces a class of errors, hallucinated or deprecated APIs, that no amount of prompting fixes.

Limitations. What it returns is community-contributed, and the README says so: Upstash “cannot guarantee the accuracy, completeness, or security of all library documentation”. In early 2026 Noma Security’s “ContextCrush” research showed that library owners’ custom rules were served to agents verbatim and unsanitised, and that a GitHub account was enough to register a library. Its proof of concept steered an agent into reading .env files, sending the secrets out and deleting files. Upstash fixed it within five days of the 18 February report by sanitising rules. The lesson generalises: a read-only documentation server is still an input channel for instructions.

Best fit. Every coding agent, with the caveat that it should run alongside approval prompts for shell and file writes, not instead of them.

4. Atlassian Rovo MCP server

The Atlassian Rovo MCP server is generally available and reaches Jira, Confluence, Jira Service Management, Bitbucket, Compass, Loom and several other Atlassian products from one hosted endpoint, https://mcp.atlassian.com/v2/mcp. The legacy SSE endpoint stopped being supported after 30 June 2026, and the v1 endpoints are scheduled for deprecation.

Strengths. Enterprise controls that most servers lack. Requests run with the signed-in user’s permissions, respect the organisation’s IP allowlists and are logged for audit. Rather than listing every tool up front, the server exposes discover-and-execute methods, which keeps the initial tool list small; a tools=all override exists for gateways that want the full list. Authentication is OAuth 2.1 by default, with API tokens available once an administrator enables them, either as basic auth or as a service-account bearer key.

Limitations. Auth is uneven across products: Jira Service Management and Bitbucket tools work only with an API token, and Compass tools only with OAuth, so a team using all three cannot pick one model. The other limitation is structural. In June 2025 Cato Networks’ “Living off AI” proof of concept showed an outside attacker filing a service-management ticket containing a prompt injection, which ran with the support engineer’s privileges when their AI assistant processed the ticket and wrote internal data back into it. Simon Willison’s write-up called the pattern insecure by design: private data, untrusted input and an outbound channel in the same session. We found no CVE and no server-side fix, because the server behaved as intended.

Best fit. Teams already on Atlassian Cloud who want agents to triage, summarise and update work items. Keep agents that read externally submitted tickets away from write tools.

5. Notion MCP

Notion’s hosted server, documented in Get started with Notion MCP, runs at https://mcp.notion.com/mcp over streamable HTTP, with an SSE fallback. It has replaced the older open-source notion-mcp-server, whose README now says it is no longer actively maintained and points users to the hosted version.

Strengths. Notion’s tools are designed for agents rather than mapped one to one from the REST API. The supported tools page lists search, fetch, page creation and updates, database and data-source queries, comments and Custom Agent sessions; the page states 32 tools. Auth is OAuth only, so there are no integration tokens to leak from a config file, and workspace owners manage connections in settings while organisation admins can monitor and revoke them through the Admin API.

Limitations. OAuth-only cuts both ways: Notion says non-interactive authentication is still a work in progress, which makes the hosted server awkward for headless agents and CI jobs. Search and data-source queries are limited to 20 calls per 10 seconds, and file uploads are capped at 20 MiB. There is no read-only mode on the hosted server; the agent can do whatever the consenting user can do in the pages they shared. A workspace wiki is also exactly the kind of mixed-trust content, pasted emails, imported documents, meeting notes, that carries injected instructions.

Best fit. Knowledge-work agents that draft, file and look up documents. For an agent that only needs to read, consider sharing a narrow set of pages at consent time and wrapping the server in a gateway allow-list that exposes only search and fetch.

6. Slack MCP server

Slack’s official server became generally available on 17 February 2026, alongside its Real-time Search API. It runs at https://mcp.slack.com/mcp over streamable HTTP and replaced the reference Slack server in the original MCP servers repository, which was archived on 29 May 2025.

Strengths. It is the most tightly governed server on this list. Per the Slack MCP documentation, clients authenticate as confidential OAuth apps with a client ID and secret, there is no dynamic client registration, and only apps published in the Slack directory or built internally can connect. Admins approve apps, MCP activity lands in Slack’s audit logs and IP allowlists apply. Each of the 20 tools maps to specific OAuth scopes, such as search:read.public for search and chat:write for posting, so a read-only deployment is a matter of not requesting write scopes.

Limitations. The same tightness makes it slower to adopt: a team cannot point an arbitrary agent at it without going through app approval, and rate limits run from Slack’s Tier 2 to Tier 4 depending on the method. The old reference server and community forks that used bot tokens (xoxb-) are still in circulation and do not carry any of these controls. Slack is also an outbound channel: an agent that can both read a private channel and post to a shared one can move data between them.

Best fit. Organisations that want agents to search conversation history and post summaries under admin control. Grant search scopes first and add posting only to agents that need it.

7. Sentry MCP

Sentry’s server, hosted at mcp.sentry.dev, connects agents to errors, traces, logs, replays and Sentry’s own Seer analysis. The code now lives in the getsentry/toolkit repository under the Functional Source License (FSL-1.1-Apache-2.0), which converts to Apache 2.0 after a delay but is not an OSI-approved open-source licence today. The npm package was at 0.42.0 on 25 September 2026.

Strengths. It closes the loop for debugging agents: an agent can search issues, pull a stack trace and trace details, and ask Seer for a root-cause analysis without anyone pasting logs into a chat. Tools are grouped into skills (inspect, seer, docs, triage, project management) that can be enabled or disabled with ?skills= or ?disable-skills=, which is a workable stand-in for a read-only mode: enabling only inspect keeps the agent out of project and alert configuration. The hosted server is OAuth only, and Sentry recommends scoping the connection to an organisation and project.

Limitations. There is no dedicated read-only flag, and some tools are destructive, such as deleting alert rules. Sentry describes the server as designed primarily for human-in-the-loop coding agents rather than as general-purpose access to Sentry. The stdio transport, needed for self-hosted Sentry, is still described as a work in progress and uses a user auth token with write scopes. The AI-powered search tools need an LLM provider configured, and Seer is not available on self-hosted instances.

Best fit. Engineering teams on Sentry’s SaaS who want coding agents to start from the real error instead of a description of it. Enable the inspect and seer skills only.

8. Supabase MCP

The Supabase MCP server, Apache 2.0, gives an agent a Supabase project: SQL, migrations, logs, advisors, edge functions, storage and branching. The hosted endpoint at https://mcp.supabase.com/mcp uses OAuth 2.1, with a personal access token as the alternative; the local CLI and self-hosted versions offer a reduced tool set and no OAuth.

Strengths. It has the best-documented set of safety switches of any database server. project_ref confines the agent to one project and removes account-level tools; read_only=true runs every query as a read-only Postgres user; features= enables only the tool groups you name, with storage and branching off by default. Supabase’s own guidance is unusually direct: connect to production only when the task needs production evidence, use project scoping and read-only mode, approve tool calls manually and use branching for changes.

Limitations. Supabase is the canonical example of why those switches exist. In July 2025 General Analysis showed an attacker submitting a support ticket that, when a developer’s agent read it through a connection using the service_role key, caused the agent to query a table of integration tokens and write them back into the ticket, bypassing row-level security entirely. The researchers noted that read-only mode would not have prevented the read, only writes. Supabase now wraps SQL results in a warning not to follow embedded instructions and says itself that this is not foolproof.

Best fit. Development and staging projects, where an agent writing migrations and reading logs saves real time. Treat production access as an exception that requires read-only mode, a single project and a human watching.

9. Stripe MCP

Stripe’s MCP server runs remotely at https://mcp.stripe.com or locally via @stripe/mcp from the MIT-licensed stripe/ai repository. The hosted server exposes ten tools, four of which are generic: search the API, describe an endpoint, read (any GET) and write (POST, PATCH, PUT, DELETE). Together they reach roughly 150 API methods, alongside account info, documentation search, an implementation planner and preview analytics and balance tools.

Strengths. Stripe has thought harder than most about agents that can move money. The OAuth consent screen lets the user choose live or sandbox accounts and set permissions per environment; administrators can switch MCP access off per environment and revoke sessions. Certain writes, including refunds and outbound payments, require a human to approve them at a URL, and the approval expires after 24 hours. From 31 October 2026 the server will reject full-access secret keys and any restricted key not tagged for agent use, returning a 401, which forces clients without OAuth onto purpose-made agent keys.

Limitations. A generic write tool is broad by design: scoping depends on the restricted key’s permissions or the OAuth grant, not on which tools are listed. Acting on behalf of Connect accounts requires a restricted key and a Stripe-Account header because OAuth is not supported there. Stripe’s own documentation tells users to enable human confirmation of tools and to take care combining Stripe with other servers to avoid prompt injection. We found no published CVEs.

Best fit. Support and finance agents that look up customers, invoices and subscriptions, and developers building Stripe integrations in a sandbox. Live-mode write access belongs behind approvals and, ideally, a gateway that logs every call.

10. Figma MCP server

Figma’s server turns design files into context for code generation. Figma “strongly recommends” the hosted endpoint at https://mcp.figma.com/mcp; a desktop server at http://127.0.0.1:3845/mcp needs the desktop app in Dev Mode and cannot write to the canvas. The server is closed source.

Strengths. Read tools such as get_design_context, get_variable_defs, get_screenshot and get_code_connect_map give a coding agent the structure, tokens and component mappings of a frame rather than a flattened image, which is what makes generated front-end code match a design system. Write tools such as use_figma and generate_figma_design work in the other direction. The tools page gives a total of 39 tools, 17 of them remote only, though its own per-category counts do not add up consistently.

Limitations. Access is metered by plan and seat. Per the rate limits page, a Starter plan with a view or collab seat gets 20 tool calls a month; Dev or Full seats get 200 a day on Starter and Professional and 600 a day on Organization and Enterprise, with per-minute limits from 10 to 20. Only clients listed in Figma’s MCP catalogue can connect, and enterprise-managed authorisation is currently limited to Claude through Okta Cross App Access. We found no published security findings.

Best fit. Front-end teams with paid Dev or Full seats who want agents to implement designs against their component library.

What actually differs between them

Feature lists blur together quickly. Four things separate a server you can hand to a whole organisation from one you would keep to a single developer.

Hosted versus local

Nine of the ten now offer a hosted streamable HTTP endpoint, and for most of them it is the recommended path. That matters more than it sounds. A hosted server is patched by the vendor, authenticates with OAuth so the user grants scoped consent that can be revoked centrally, and never asks anyone to paste a long-lived token into a JSON file. Local stdio servers inherit whatever is in the environment. The incidents that hit local tooling hardest were not in vendor servers at all: CVE-2025-6514 in the mcp-remote bridge (CVSS 9.6) allowed command execution through a crafted authorisation endpoint, and CVE-2025-49596 in Anthropic’s MCP Inspector (CVSS 9.4) let a malicious web page run commands through an unauthenticated local proxy. Playwright’s DNS-rebinding CVE belongs to the same family.

Scoping controls

GitHub and Supabase are the clear leaders. Notion is the weakest: whatever the consenting user can do, the agent can do. Where the server has no control, a gateway allow-list is the only way to narrow it.

Security record

Five of the ten have a public finding against the server or its pattern of use: GitHub (Invariant Labs), Playwright (CVE-2025-9611), Context7 (ContextCrush), Atlassian (Living off AI) and Supabase (General Analysis). Stripe publishes an explicit warning about combining its server with others because of prompt injection. The common thread is what Willison calls the lethal trifecta. In almost every case the server did exactly what it was told; the agent was told the wrong thing by content it read through another tool. Server-side fixes help at the edges, but the controls that work are scoping, approvals and keeping untrusted input away from sessions that hold write access.

Figure 1: Rank your servers by what a hijacked agent could do with them, and spend scoping effort from the production column outwards.

Licence and openness

Six have permissive public repositories (GitHub, Playwright, Context7, Supabase, Stripe, and Atlassian’s repository for the Rovo server), Sentry’s is source-available under FSL, and Notion, Slack and Figma are hosted services without public server code. For a hosted server this matters less than it would for a library, because you are not running the code; what you need instead is the vendor’s audit logging and revocation, which Slack and Atlassian document best.

The specification and the registry in October 2026

The current specification is version 2026-07-28, and it is the largest change since streamable HTTP. It removes protocol-level sessions, the Mcp-Session-Id header and the initialize handshake: every request now carries its protocol version and client capabilities, and servers must implement a new server/discover call. Server-initiated requests such as elicitation and sampling are replaced by a multi round-trip pattern, tasks move into an official extension, and Roots, Sampling and Logging are deprecated. On the authorisation side, clients must validate the RFC 9207 iss parameter and bind credentials to the issuing authorisation server, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, which the 2025-11-25 revision introduced as the recommended path. Deprecated features stay for at least twelve months.

For server choice, the practical consequence is that the authorisation model has settled. Since the 2025-06-18 revision, MCP servers are OAuth resource servers and clients must send RFC 8707 resource indicators, so tokens are bound to the server they were issued for. The security best practices make token passthrough “explicitly forbidden”: a server must not accept tokens that were not issued for it. Vendor servers that implement this properly are the ones that score well above. Expect a period in which some clients speak 2026-07-28 and some servers still expect sessions; check client compatibility before upgrading anything.

The official MCP Registry launched in preview on 8 September 2025 and was still in preview in October 2026, with an API freeze at v0.1. It stores metadata only and points to packages on npm, PyPI or Docker Hub. Server names use reverse-DNS namespaces such as io.github.username/server, and publishers prove ownership of a namespace through GitHub, DNS or HTTP challenges. That verification is useful: it tells you a server under com.stripe was published by whoever controls stripe.com. It is not a security review. The registry leaves scanning to package registries and downstream aggregators, and does not cover private servers. The September 2025 case of a malicious postmark-mcp package, which quietly copied every email it sent to an outside address from version 1.0.16, is the reminder: the name on a package is not the vendor unless you have checked.

Figure 2: Most servers on this list resolve at the first question; the third question applies on top of whichever answer you reach.

Running MCP servers behind a gateway

Every control in the sections above lives inside one server, configured by whoever set it up. Ten servers means ten consent screens, ten token types, ten sets of flags, and no single place to answer “which agent called stripe_api_write last Tuesday, and with what arguments”. An MCP gateway puts one endpoint between agents and servers and moves those decisions there. The MCP gateway explainer covers the mechanism in depth; this section maps it onto the ten servers.

A gateway is useful here for five things.

1. Central auth. The gateway holds the upstream OAuth tokens or keys, so agents authenticate once to the gateway and never see Stripe or Supabase credentials. Per-user OAuth keeps upstream permissions tied to the human.
2. Tool allow-lists. The gateway decides which tools each caller sees in tools/list. This is how you give Notion a read-only mode it does not have, or expose only Sentry’s inspect tools to a support agent.
3. Guardrails. Checks on tool arguments and results can stop a secret or personal data leaving through a tool call, which addresses the outbound leg of the lethal trifecta.
4. Audit logs. One record of caller, server, tool, arguments and latency for every call, rather than ten vendor logs in ten formats, some of which do not exist.
5. Shadow MCP. Inventory and enforcement for servers that individual developers configure on their own machines.

Bifrost, the open-source Apache 2.0 gateway built by Maxim AI, is one example of how this works in practice. As an MCP gateway it connects to upstream servers over stdio, HTTP or SSE and acts as both an MCP client to those servers and an MCP server to agents such as Claude Desktop or Cursor. Upstream auth can be none, static headers, OAuth (with PKCE, discovery and token refresh), per-user OAuth, per-user headers or token exchange. By default tool calls returned by a model are suggestions; the application executes them explicitly, and automatic execution is opt-in per tool, which is the approval step the Stripe and Supabase guidance asks for.

Tool filtering is an intersection: the tools configured for a server, the tools allowed for the caller’s virtual key, and any narrowing in request headers. An empty list means deny, and a header can narrow a key’s allow-list but never widen it. That makes “GitHub read-only issue tools plus Sentry inspect” a property of a key rather than of each developer’s setup. When a team connects many servers at once, Code Mode replaces the full tool list with four meta-tools and a sandboxed scripting environment; Bifrost’s published benchmark reports input tokens down 92.8 per cent at 508 tools across 16 servers, with pass rates unchanged on the same query set. Those are the vendor’s own figures.

Policy sits on top. Bifrost’s AI governance features cover SSO with SCIM, role-based access, virtual keys scoped to models and MCP tools, budgets, and export of audit data, with self-hosted, VPC, on-premises and air-gapped deployment. Its enterprise AI guardrails can apply secrets detection, regex and PII checks, model-based judges or third-party providers to MCP traffic, with rules that can match on the MCP client, tool name and arguments. The MCP gateway page describes logging every tool call with tool, server, virtual key and latency; the separate enterprise audit log records administrative changes as signed events.

Figure 3: Each step that the ten servers implement differently, or not at all, is done once at the gateway.

Shadow MCP on laptops

A network gateway only governs traffic that is sent to it. A developer who adds a community Postgres server to their coding agent’s config file, with a production connection string in an environment variable, is invisible to it. That is the MCP version of shadow AI, and it is where the riskiest servers on any list tend to end up: local, unpinned, holding broad credentials.

Bifrost Edge addresses this from the endpoint side. Deployed to macOS, Windows and Linux machines through MDM tools such as Jamf, Intune or Kandji, it routes AI traffic from desktop apps and agents into the Bifrost gateway without base-URL changes. For MCP specifically, Edge MCP governance reads the MCP configuration of supported apps on each machine (Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, OpenCode), builds a fleet-wide inventory, and lets administrators allow, deny or hold new servers pending review, enforcing a denial on the device even for an app that had the server configured before the policy existed.

Limitations. A gateway adds a hop and a component to operate, and it is only as good as its allow-lists. It cannot fix a server that is too broad by design, such as Stripe’s generic write tool, beyond hiding it or checking its arguments. Guardrails that call external models add latency per check. And none of this removes the need to scope upstream credentials narrowly in the first place.

Recommendations by constraint

You are starting from nothing. Connect GitHub (remote, read-only, two toolsets), Context7 and Sentry (inspect skill). That gives a coding agent code, current documentation and real errors with almost no write surface. Add Playwright when it needs to see a page.

Your agents read content from outside the company. Support tickets, public issues, inbound email, shared documents. Do not give the same session write access to anything else. This is the pattern behind the GitHub, Atlassian and Supabase findings, and no server setting fixes it.

You handle money or production data. Stripe and Supabase only in sandbox or staging by default. In production, Supabase with project_ref and read_only, Stripe with OAuth per environment and human approval on writes, and every call logged at a gateway.

You need non-interactive agents. Prefer servers with a service-account or key model: Atlassian’s admin-enabled API tokens, Stripe’s agent keys, GitHub’s fine-grained tokens. Notion’s hosted server is not yet a good fit.

You have more than a few dozen people using MCP. Put the servers behind a gateway with per-team allow-lists before the tenth server, not after. Compare options in the MCP gateway comparison and, if you also route model traffic, the LLM gateway comparison.

You cannot see what developers have installed. That is an endpoint problem, not a gateway one. Inventory first; policy follows.

What to do this week

Pick the servers your agents actually use from the table above and, for each one, answer three questions: is this the vendor’s own server, is it the hosted endpoint, and is it scoped as narrowly as the server allows? Replace any community server that has an official equivalent. Turn on read-only modes where they exist and add a gateway allow-list where they do not. Pin local servers to exact versions. Then find out what is configured on laptops that nobody approved, because in most organisations that list is longer than the one you started with.

Feature claims are drawn from public documentation and vendor announcements as of October 2026; check current docs before deciding.