Which MCP servers should a company start with?

The ones that wrap systems your team already uses daily and that the vendor hosts: GitHub or GitLab, your issue tracker (Jira, Linear), your docs (Confluence, Notion), and Playwright for browser testing. They are well maintained, use OAuth, and have narrow, understandable scopes.

Are official MCP servers safer than community ones?

Generally yes. A server run by the vendor is maintained, uses proper OAuth, and cannot be typosquatted. Community servers can be excellent but need a review of their tool descriptions and a pinned version before approval.

Where do I find MCP servers?

The official MCP Registry is the closest thing to a canonical catalogue. Clients such as Claude, GitHub Copilot and Cursor expose their own directories on top of it, and most vendors document their server on their own site.

Can I use MCP servers with ChatGPT and Gemini as well as Claude?

Yes. Remote MCP servers work with any client that implements the protocol, which now includes ChatGPT, Gemini, Copilot, Cursor, VS Code, Claude and Claude Code.

The best MCP servers for teams in 2026

There are thousands of MCP servers. Most teams need about ten. This list is the set that keeps showing up in the company rollouts we run, grouped by what they connect to, with the notes that matter when you approve them for more than one person.

Two rules of thumb shaped the list. Prefer servers hosted by the vendor of the underlying system, because they use real OAuth and cannot be typosquatted. And read the tool list before approving: the best server is the one whose tools match what your team should be able to do, not the one with the most tools. If you have not seen what an MCP server is, start there.

Developer tools

GitHub. The official server covers repositories, issues, pull requests, code search, actions and security alerts. Remote, OAuth, hosted by GitHub. It is the single most used server we see. Watch the scopes: the default grants more than an agent that only reads issues needs, and the 2025 prompt-injection demonstration used exactly this server. Give it a token scoped to the repositories the agent works on.

GitLab. Equivalent coverage for GitLab projects, merge requests and pipelines. Self-hosted GitLab instances can run the server inside the same network, which is the right answer for regulated environments.

Azure DevOps. Work items, repos, pipelines and boards. Widely used in Microsoft-centric Nordic and German companies. Runs against your organisation with a PAT or Entra identity.

Sentry. Issues, stack traces, releases. Very useful for "explain this error and propose a fix" workflows in Claude Code. Read-only by nature, low risk.

Context7. Not a system connector but a documentation source: it feeds up-to-date library docs to the model so it stops hallucinating APIs. Popular with Cursor and Claude Code users. Low risk, high value for code quality.

Project management and docs

Atlassian (Jira and Confluence). The official remote server covers both. Jira tools include creating and transitioning issues; hide the destructive ones for most users. Confluence access is the classic source of untrusted content, so pair it with read-only sessions.

Linear. Clean, fast, remote, OAuth. Tools map closely to how teams actually use Linear. A good first server for product teams.

Notion. Pages, databases and search. Notion workspaces mix internal and external content, so treat results as untrusted.

Slack. Reading channels and posting messages. Posting is a write action with real consequences; require approval or restrict to specific channels.

Data

Snowflake, Postgres, BigQuery, Databricks. Each has a server, official or well-maintained. The rule for all of them: a read-only database role, an allowlist of schemas, and a row limit. A database server with a read-write connection string is the highest-risk thing on this page.

Filesystem. The reference local server. Start it with an explicit list of allowed directories and nothing else. Never on the home directory.

Google Drive and SharePoint. Document search and reading. Both are large pools of untrusted content and often contain personal data; think about where the server runs and what leaves the region.

Browser and testing

Playwright. Microsoft's server lets the agent drive a real browser: navigate, click, fill forms, take screenshots, run tests. Excellent for QA and for agents that need to check a web app. The browser sees whatever the agent visits, so it is also an injection vector; run it in an isolated profile without logged-in sessions.

Chrome DevTools. Google's server for performance traces, network inspection and debugging in a live Chrome. Useful for front-end teams.

Infrastructure and cloud

Azure. Microsoft's server covers a wide range of Azure services. Scope it to the subscriptions and resource groups the agent needs. For EU companies running on Azure it is the natural way to give an agent operational visibility without handing out portal access.

AWS. Amazon publishes a family of servers per service rather than one. Same scoping advice.

Docker and Kubernetes. Community and vendor servers exist for both. Anything that can run containers or apply manifests is effectively remote code execution; require approval per call.

Automation and business systems

n8n and Zapier. Both expose their workflows as MCP tools, which turns any automation your ops team has already built into something an agent can trigger. Powerful and a wide blast radius; approve per workflow.

Stripe. Payments, customers, invoices. Read tools are fine for support agents; write tools should be behind approval and probably a separate, restricted key.

ERP, CRM and finance systems. Fortnox, Visma, SAP, DATEV, HubSpot, Salesforce and Dynamics all have official or community servers of varying maturity. This is the category where most companies end up writing their own narrow server instead: read-only, a handful of tools, hosted inside the tenant. Our MCP gateway guide explains why.

How to evaluate a server before approving it

Who runs it? Vendor, well-known maintainer, or an unknown package? Prefer the first.
Remote or local? Remote with OAuth is easier to govern. Local needs version pinning and directory restrictions.
What are the tools? Read the list. Count the write, send and delete tools. Decide who gets them.
What do the descriptions say? Descriptions that reference other tools, files outside the server's purpose, or secrecy are disqualifying.
Where does it run? For remote servers, which region. For EU data, this decides the answer.
What will it return? If results can contain content others control, plan for injection: read-only sessions, result inspection, approval on writes.

Running them together

Ten servers across fifty developers and three clients is where the list stops being the hard part. The hard part becomes who is allowed which tools, where the credentials live, and what the log says. That is the job of a gateway.

Walma AI Hub hosts approved servers, including internal ones over ERP and CRM systems, inside the customer's Azure tenant in an EU region, and applies one policy and one log across Claude, GPT, Codex and Cursor. If you are choosing your first ten servers, we are happy to walk through the list with you.