MCP server setup guides

dbt Labs publishes this one themselves, so — as with Tableau — the question is not which project to trust but which flavour to run. The remote server, reached over HTTP at /api/ai/v1/mcp/ on your dbt platform host, needs nothing installed and is the right default if the agent is going to read metadata and query metrics. It cannot run dbt CLI commands or Codegen, and it never will: those tools need a checkout on disk. The self-hosted server, started with uvx dbt-mcp beside your client, is the one for development workflows — it is the only flavour that can run dbt build, dbt test or generate a staging model, and it can still reach the platform APIs on top. The surface is large either way: 61 tools across nine toolsets, more than most clients will happily show at once, which is why the enable/disable configuration below matters more here than on a five-tool server. Read the gotchas before your first run; two of the three most common failures are silent by design.

• →Why does the dbt MCP server hang on first run instead of returning an error?
• →Why are the dbt CLI tools missing from my tool list?

Three different things have been called the Snowflake MCP server, and only one of them is the answer now. The Snowflake-managed server is a first-party, Generally Available feature that you create with SQL — it is a database object, not a package — and reach over HTTPS; nothing installs anywhere. Snowflake-Labs/mcp, the local Python server most older tutorials point at, carries a deprecation notice at the top of its own README and has not shipped a release since 1.4.2 in May 2026; do not start there. isaacwasserman/mcp-snowflake-server is a genuinely independent community project that is still a reasonable choice if what you want is a plain read/write SQL bridge with no Cortex in it. The managed server is the one this guide covers. Its surprises are not installation problems — there is no installation — but governance ones: a tool can be visible and still refuse to run, and the role your session ends up with is usually not the role you think you selected.

• →Is the Snowflake-Labs/mcp server still the right Snowflake MCP server to install?
• →Why can my client see a Snowflake tool but not invoke it?

Three different servers answer to "redis mcp" and the one most tutorials still paste is the retired one. `npx @modelcontextprotocol/server-redis` was Anthropic's reference implementation; the package is marked "Package no longer supported" on npm, its last publish was 2025-04-25, and its source now sits in `modelcontextprotocol/servers-archived`. It installs without complaint, which is why people are still running it. Redis maintains its own server, `redis/mcp-redis` — 567★, pushed the week this guide was verified — and it is a Python package, not an npm one, so the muscle-memory `npx` command cannot reach it. The third, `redis/mcp-redis-cloud`, is a control plane for the Redis Cloud account and cannot touch a single key. The other thing worth knowing before you connect it: unlike every other database server in this cluster, this one has no read-only flag. The guard is a Redis ACL user, and you create it yourself.

• →Is @modelcontextprotocol/server-redis deprecated?
• →Why is there no npx command for the Redis MCP server?

This is the one server in the database cluster where the deprecation notice is not the interesting part — the install route is. Elastic's standalone server is deprecated in favour of the Agent Builder MCP endpoint, which is true and which every listing repeats. What none of them say is that at version 0.4.0 the project stopped shipping to npm. `@elastic/mcp-server-elasticsearch` is marked deprecated on the registry and frozen at 0.3.1, published 2025-07-01; releases since then — up to v0.4.6 — exist only as the Docker image `docker.elastic.co/mcp/elasticsearch`. So the `npx -y @elastic/mcp-server-elasticsearch` block in nearly every write-up still installs and still connects, and quietly gives you a server without the `esql` tool. The repo itself is alive (704★, Apache-2.0, not archived, pushed the day this guide was verified) because security fixes still land there. Read the version question first, the deprecation question second.

• →Is the Elasticsearch MCP Server deprecated?
• →Why does npx @elastic/mcp-server-elasticsearch still work?

There is only one MongoDB MCP server — `mongodb-js/mongodb-mcp-server`, maintained by MongoDB — so unlike Postgres you do not have to pick. What you do have to pick is which half of it you are turning on, because it is really two servers sharing a process. The database half talks to a deployment over a connection string and gives you `find`, `aggregate`, `explain`, index and schema tools. The Atlas half is a control plane: it creates clusters, database users and access-list entries, and it authenticates with Atlas Service Account credentials, not with your connection string. Set only `MDB_MCP_CONNECTION_STRING` and the Atlas tools never register; that is the single most common "the tools are missing" report, and it is configuration, not a bug. The other thing to know before you paste anything: `readOnly` defaults to false. MongoDB puts `--readOnly` in every example in its own README, which is a fair signal about what the default should be for an agent pointed at a real database.

• →Is the MongoDB MCP server read-only by default?
• →Why are the Atlas tools missing from the MongoDB MCP server?

Nearly every "connect Claude to Postgres" article still tells you to run npx @modelcontextprotocol/server-postgres. That server is retired. Its repository moved to modelcontextprotocol/servers-archived — a repo GitHub itself marks archived, described as "Reference MCP servers that are no longer maintained" — and the npm package carries a deprecation notice: "Package no longer supported." It still installs and still runs, which is exactly why the advice keeps propagating. What you get is one tool, query, executing read-only SQL, plus table schemas exposed as resources. No index advice, no health checks, and nothing has shipped in it for a long time. The live server people actually mean when they say "the Postgres MCP server" is Postgres MCP Pro (crystaldba/postgres-mcp, 3,184 stars) — nine tools, an explicit access-mode switch, and index tuning that runs real EXPLAIN plans against hypothetical indexes. This guide sets up the live one and tells you when the archived one is still the right call.

• →Is @modelcontextprotocol/server-postgres deprecated?
• →Which Postgres MCP server should I use?

The Neon server is remote-first — there is nothing to install, you point a client at https://mcp.neon.tech/mcp and authorize in a browser — and that makes the interesting configuration entirely a matter of what you put in the URL. Three query params (readonly, category, projectId) decide whether the agent can write, which tool categories exist at all, and whether it can see one project or your whole account. This matters more here than on most servers because the default surface is roughly thirty tools spanning project creation, deletion, migrations and auth provisioning, and because Neon says plainly in its own README that the server is "intended for local development and IDE integrations only" and that it does not recommend running it against production. The other thing worth knowing before you start: the migration tools are two-phase on purpose, and the branch they create is what makes "let the agent change my schema" a defensible idea rather than a reckless one.

• →Can I use the Neon MCP server in production?
• →Why does the MCP server not see my organization's projects?

Most of what goes wrong with this server is not the server. It is that `CLICKHOUSE_*` names two unrelated things and people configure one while thinking about the other: the variables that decide how this process dials your database, and the `CLICKHOUSE_MCP_*` variables that decide how MCP clients reach this process. The README calls that out explicitly, and it is worth internalising before you paste anything, because the failure mode is an opaque HTTP or TLS error in the server log rather than a message that says "wrong scheme". The second thing to know is that safety here is two-tier and off by default in a way that is genuinely useful: reads work with no flags, writes need `CLICKHOUSE_ALLOW_WRITE_ACCESS=true`, and `DROP`/`TRUNCATE` need `CLICKHOUSE_ALLOW_DROP=true` on top of that. And if you only want to see whether a ClickHouse-shaped agent is useful at all, you can point it at ClickHouse's public playground and never connect a cluster of your own.

• →Why does the ClickHouse MCP server fail to start with HTTP transport?
• →I set CLICKHOUSE_SECURE=false because my MCP server is behind an ingress. Why did the database connection break?

Almost every third-party write-up of this server still tells you to mint a personal access token and run a local npx process. That is the old shape. Supabase now runs a hosted server at https://mcp.supabase.com/mcp using OAuth 2.1 with dynamic client registration — you paste a URL, a browser opens, you pick the organization, and there is no PAT to rotate. What replaces token management is URL configuration: three query parameters (read_only, project_ref, features) decide whether the agent can write, which project it can see, and which tool groups exist at all. Supabase itself is blunt about the reason those parameters matter — the docs tell you not to point this at production, and the prompt-injection example they give is a support ticket whose body contains the instructions.

• →Do I still need a Supabase personal access token for the MCP server?
• →Why does authentication fail in the Claude Code IDE extension?

Mixpanel does not publish an MCP server. That is the first thing worth knowing, because several catalogs — including this one until August 2026 — listed a "Mixpanel" server marked official with no repository behind it. What Mixpanel actually ships for agents is mixpanel-headless, a Python CLI it describes as "designed with coding agent use in mind", and ai-plugins, a set of Claude Agent Skills. Neither speaks MCP. So the practical answer to "which Mixpanel MCP server do I install" is a community one, and there are three worth separating. dragonkhoi/mixpanel-mcp is the adoption leader at 19 stars and 19 forks and has by far the widest tool surface — 19 tools over the Query API — but its last commit was March 2025 and it has no working published package. mrfentmen/mixpanel-mcp is the actively maintained one and is on npm, but it is seven tools and its published binary does not run (see the gotchas). moonbirdai/mixpanel-mcp-server is a different job entirely: it writes events into Mixpanel rather than reading them out. This guide sets up dragonkhoi/mixpanel-mcp, and tells you when not to.

• →Why does the server exit immediately when I set the credentials as environment variables?
• →Does the Mixpanel MCP server work with EU or India data residency?

There is only one Tableau MCP server worth considering and Tableau publishes it themselves, so the decision here is not which project to trust — it is which of the three ways to run it you want. The hosted server at mcp.tableau.com is the right default for Tableau Cloud: it speaks OAuth 2.1, each user signs in as themselves, and the permissions already configured on your site are what the agent gets, with nothing to deploy. The self-hosted npm package is for Tableau Server, and for Cloud customers whose security review will not allow a vendor-hosted endpoint; you supply a Personal Access Token and the server runs beside the client, which means it runs with that token’s permissions for everyone who talks to it. The third path, the Tableau Desktop authoring build, is the one people find by accident and lose an afternoon to — it exists in the repository, it is not in the published npm package, and its README is a single heading with no body. Read the gotchas below before you pick.

• →Why does pip install tableau-mcp fail?
• →Why are the Tableau Desktop authoring tools missing?

Searching "Docker MCP" returns two completely different products and the names do not help you tell them apart. This page is ckreiling/mcp-server-docker, the community server that hands an assistant your Docker daemon — containers, images, networks, volumes. Docker’s own Docker MCP Gateway is not a rival implementation of that; it manages no containers of yours at all, it is a CLI plugin that runs *other* MCP servers inside containers behind one endpoint. If the sentence you want to type is "why does the postgres container keep restarting", you are in the right place. If it is "give Cursor and Claude Desktop the same twenty tools without twenty stdio processes", you want the gateway instead. The other thing to settle before installing: this server can create, recreate and remove containers, and Docker is not a sandbox, so it reaches the host. Decide up front whether it points at a throwaway engine or a real one.

• →Is this the same as Docker’s official Docker MCP Gateway?
• →Can I safely put secrets in containers the assistant creates?

The Argo CD MCP server is argoproj-labs/mcp-for-argocd, and it is the one the ecosystem has settled on — there is no competing implementation with meaningful adoption, so the "which server" question that dogs most MCP setups does not apply here. The question that does matter is exposure. The tool list includes delete_application, sync_application and run_resource_action, so this is a write path into your delivery pipeline, not a read-only dashboard. The server binds loopback by default and that default is doing real work; the two sections below on tokens and network exposure are the ones to read before you move it anywhere.

• →Does ARGOCD_API_TOKEN secure the HTTP endpoint?
• →Why does overriding argocdBaseUrl to another instance fail?

There are two ways to give an assistant access to Jenkins and they differ in where the code runs. The official Jenkins MCP plugin installs into the controller from the update centre, which means the controller starts answering MCP itself — excellent if you administer Jenkins, impossible if you do not. This one, lanbaoshen/mcp-jenkins, runs beside Jenkins as an ordinary Python process and talks to it over the REST API with your own credentials, so you can point it at a controller you have no admin rights on. It is also the wider of the two tool surfaces, and the only one that can read your plugin inventory.

• →Is run_groovy_script safe to leave enabled?
• →Large requests time out. What do I change?

Searching "railway mcp" turns up four things and only one of them is current. `railwayapp/railway-mcp-server` was the official repository; it is archived, last pushed 2026-05-23, and still clones and builds. `@railway/mcp-server` on npm is a deprecated compatibility shim — its own npm metadata says "Railway MCP is now bundled into the Railway CLI. Use `railway mcp`". `jason-tan-swe/railway-mcp` is an unofficial community server, untouched since June 2025. The live one is not a package at all: it ships inside the Railway CLI, and `railway mcp` starts it. There is also a genuine name collision — several of the top GitHub hits for "railway mcp" are Indian Railways train-status servers, unrelated to the PaaS. The decision that actually matters once you are in the right place is Local versus Remote, and it is not a transport preference: they expose different tool sets, and picking on convenience silently costs you tools.

• →Is @railway/mcp-server deprecated?
• →What is the difference between Railway Local MCP and Remote MCP?

Sentry is explicit that this is not a general-purpose wrapper around the Sentry API — it is built for human-in-the-loop coding agents, and the tool selection is skewed to debugging workflows rather than administration. The default deployment is remote, at https://mcp.sentry.dev/mcp, running on Cloudflare's remote-MCP infrastructure, so for Sentry SaaS there is nothing to install. The stdio transport exists mainly so self-hosted Sentry installs have a path, and the README describes it as still a work in progress. The one configuration decision that catches people out is unrelated to transport: the AI-powered search tools need their own LLM provider key, and without one they simply do not appear.

• →Why are search_events and search_issues missing from my Sentry MCP tools?
• →Why does Authorization: Bearer <sentry token> not work on the remote server?

Vercel MCP is a remote, OAuth-only server at https://mcp.vercel.com — in Beta, on all plans, with nothing to install. Two things about it are unusual enough to plan around. First, Vercel only accepts connections from AI clients it has reviewed and approved, so "my client cannot connect" is often not a bug you can fix. Second, nearly every tool takes a required teamId, which means an agent that has not yet called list_teams or read your .vercel/project.json will fail its first few calls in a way that looks like a permissions problem and is not. Vercel is also explicit about what a connection grants: the same access as your own Vercel user account.

• →Why can my AI client not connect to Vercel MCP?
• →Why do Vercel MCP tools keep failing with a missing teamId?

"The Cloudflare MCP server" is not one thing, and picking the wrong one is the main way this goes badly. There are two families. The Cloudflare API MCP server at https://mcp.cloudflare.com/mcp exposes the entire Cloudflare API — over 2,500 endpoints across DNS, Workers, R2 and Zero Trust — behind exactly two tools, search and execute, using the Code Mode pattern. Separately there are sixteen product-specific servers, each on its own *.mcp.cloudflare.com/mcp hostname, with curated tools for one area: Observability, Workers Bindings, Radar, Browser Rendering, DNS Analytics, CASB and so on. The rule of thumb: if the task spans products or touches an endpoint nobody wrote a tool for, use the API server; if you want a small, legible tool list for one product — and want to see the tool names in your client — pick the product server. The two repos are different too, which is why star counts and issue trackers disagree: the API server is cloudflare/mcp, the sixteen are cloudflare/mcp-server-cloudflare.

• →Which Cloudflare MCP server should I install?
• →Why does my client fail to connect to the /sse endpoint?

There is nothing to install. The Datadog MCP Server is a hosted endpoint on your own Datadog site — `https://mcp.<your-site>/api/unstable/mcp-server/mcp` — and you authorise it with OAuth from inside your client, not with a package and a pair of keys. Two things decide whether the setup goes well. First, use the vendor plugin or connector for your client rather than a hand-written config: Datadog ships one for Claude Code, Claude, Cursor, VS Code/Copilot, JetBrains and OpenCode, and the docs say to remove any earlier manual entry so the two do not fight. Second, choose your toolsets. The default `core` toolset is deliberately small; the full catalogue runs to hundreds of tools across two dozen toolsets, and `toolsets=all` will eat a large share of your context window before you have asked anything.

• →Does the Datadog MCP server need DD_API_KEY and DD_APP_KEY?
• →Is there an npm package for the Datadog MCP server?

There are two GitLab MCP servers and they are not competing implementations of the same thing — they are different products that happen to share a name. GitLab ships one inside the application: no package, no token, answering at https://<your-instance>/api/v4/mcp, authenticating by OAuth Dynamic Client Registration. zereight/gitlab-mcp is the community one: 1,889 stars, npm @zereight/mcp-gitlab, a personal access token in a config file, and 217 tools against GitLab's REST and GraphQL APIs. The decision is almost always made for you by your instance version, because the built-in server needs GitLab 18.3 or later with settings an administrator has to turn on. If you are on an older instance, or you do not control those settings, the community server is not a downgrade — it is the only one that will connect.

• →Why does the GitLab MCP server not appear or fail to authorise?
• →Do I need a personal access token for the GitLab MCP server?

Filed under browser automation everywhere, and that is the part of it worth the least. Clicking and typing is ten of roughly fifty-six tools, and Playwright does that job with a smaller context footprint. What only this server has is the panel side of Chrome: record a real performance trace and get back the same insights the Performance panel computes, run a Lighthouse audit, read console messages with source-mapped stack traces, and walk a heap snapshot through twelve dedicated tools. The decision that actually matters at install time is not which browser server to use — it is which browser it drives. By default it launches its own Chrome against a dedicated profile under $HOME/.cache/chrome-devtools-mcp, which is signed in to nothing; the two flags that fix that, --autoConnect and --browserUrl, are also the two ways an agent ends up holding your real logged-in session. Read that part before the tool list.

• →Does Chrome DevTools MCP use my normal Chrome profile?
• →How do I make it use a browser I am already signed in to?

The most-copied Context7 setup on the internet references a tool that has not existed since December 2025. get-library-docs was removed in v2.0.0 and replaced by query-docs, and the rule snippets, Copilot config blocks and blog posts that name it are all still circulating — including the README published with the current npm package, 4.0.2, which carries a GitHub Copilot config listing "tools": ["get-library-docs", "resolve-library-id"]. The repository README is the one that is current. Two other things are worth knowing before you install: the recommended path is now the ctx7 CLI rather than a hand-written MCP entry, and it can set Context7 up with no MCP server at all, as a skill that shells out to CLI commands. Which of those two you pick is the actual decision here, and it depends on how much of your context window you are willing to spend.

• →Why does get-library-docs not work in Context7?
• →Do I need an API key for Context7?

Two different servers are called Playwright MCP, and this is the community one. It is genuinely popular — 5,633 stars, MIT, featured in most directories — and it does things Microsoft's does not: it records a browsing session into a runnable Playwright test file, it emulates 143 real device profiles by name, and it can fire HTTP requests with no browser involved at all. The fact none of those listings mention, checked against GitHub and npm on the day this guide was verified: the repository has not been pushed since 2025-12-13, and npm 1.0.12 was published 2025-12-12, with 32 issues open. It is not archived and the package is not deprecated, so nothing warns you — it simply installs and runs a build that is eight months old while Microsoft's server ships continuously. Pick this one for the codegen and device-emulation features specifically. Do not pick it because it came up first.

• →Which Playwright MCP server should I use — Microsoft or ExecuteAutomation?
• →Is ExecuteAutomation Playwright MCP still maintained?

Playwright MCP drives a real browser through Playwright's accessibility tree rather than screenshots, so it needs no vision model and its output is structured text a language model can act on deterministically. Before you install it, read the project's own caveat: Microsoft now says that if you are using a coding agent, you may be better served by the Playwright CLI with skills, because CLI invocations avoid loading large tool schemas and verbose accessibility trees into the context window. MCP is the right choice for agentic loops that want persistent browser state and iterative reasoning over page structure — exploratory automation, self-healing tests, long-running autonomous workflows — and the wrong choice if you mostly want a browser occasionally in a session already full of code.

• →Why does Playwright MCP fail when I open it in a second client?
• →Should I use Playwright MCP or the Playwright CLI with skills?

BlenderMCP is two pieces, and people who install one and not the other account for most of the "it connects but nothing happens" reports. `addon.py` runs inside Blender and opens a socket server on port 9876; the `blender-mcp` Python package is the MCP server your client speaks to, which relays commands into that socket. So Blender has to be open, the addon has to be enabled, and you have to have pressed "Connect to Claude" in the BlenderMCP sidebar tab before any tool call can work. Requirements are Blender 3.0+ and Python 3.10+, and the install is via uv — the project is emphatic that you install uv with its official installer, not `pip install uv`, which may not create the `uvx` command your client needs.

• →Why does Blender MCP connect but nothing happens in Blender?
• →Where do I download addon.py now that the GitHub repo 404s?

There is no npm package for this server. `@github/mcp-server` returns 404 on the npm registry, so every `npx @github/mcp-server` line circulating in listings and blog posts fails on the first run — that is the single biggest source of wasted time here. GitHub ships it three ways instead: a hosted remote server at api.githubcopilot.com that needs no install, a Docker image, and a Go binary you build yourself. Take the remote server unless you are on GitHub Enterprise Server, which the remote server does not cover.

• →Why does npx @github/mcp-server fail?
• →How do I make the GitHub MCP server read-only?

Most listings for "figma mcp" still hand you the desktop setup, and Figma's own docs no longer lead with it: the remote server at mcp.figma.com/mcp is now the recommended one, with the desktop server kept for specific organisation and enterprise cases. The difference is not cosmetic. Roughly a third of the tools — creating files, generating designs, uploading and downloading assets, searching connected libraries — exist only on the remote server. The desktop server's advantage is that it reads what you have selected in the running app.

• →Should I use the remote Figma MCP server or the desktop one?
• →Why do I only get a handful of Figma MCP tool calls?

Zendesk does not publish an MCP server of its own — there is no developer.zendesk.com MCP page, which is why every result for this query is a community project. The one that has taken the name is reminia/zendesk-mcp-server: 114 stars, Apache-2.0, Python, and the only one of the eight on GitHub with meaningful adoption. It is deliberately narrow. Six tools cover tickets and comments, one resource hands over the Help Center, and two prompts do ticket analysis and reply drafting. It does not touch macros, triggers, automations, views, CSAT, organizations, Talk or Guide authoring, and directory listings that say otherwise are describing the Zendesk API rather than this server. If you need writes beyond ticket fields and comments, you are looking at building against the API yourself, not at this.

• →Why does uvx install a different version than the GitHub repo?
• →Can I give the assistant read-only access to Zendesk?

Zapier MCP is not a package you install, and the GitHub repo people find first is not the server. github.com/zapier/zapier-mcp distributes a client-side plugin — guided onboarding, a demo, role-tailored skills — while the server itself is hosted by Zapier and reachable at one URL: https://mcp.zapier.com/api/v1/connect. That is the whole install. The registry entry com.zapier/mcp confirms it as a streamable-http remote, and Zapier is explicit that SSE is not supported, which is the single most common reason a connection attempt fails. The other thing worth knowing before you start is that the tool list is not fixed: your agent discovers and enables actions during the conversation through a set of meta-tools, so the 9,000+ apps and 40,000+ actions figure is a ceiling reached on demand, not a list you configure up front.

• →Why will my client not connect to Zapier MCP?
• →Do I need to install anything to use Zapier MCP?

There are now two live answers to "Airtable MCP", and most write-ups only know the older one. domdomegg/airtable-mcp-server is the established community server: an npm package you run locally over stdio, authenticated with a personal access token, with 16 tools covering records, schema, fields and comments. Airtable also runs an official hosted server at https://mcp.airtable.com/mcp — it answers with OAuth protected-resource metadata, and Airtable's own CLI points at it as its default endpoint. Take the community server when you want the token scoped by hand, a pinned version and a process on your own machine. Take the hosted one when you would rather authorise with OAuth and skip credential management, accepting that Airtable calls the surface experimental and says tool names and arguments may change without notice.

• →Why does the Airtable MCP server start but see nothing?
• →Is it safe to run Airtable MCP in HTTP mode?

The Google Drive MCP server that everything links to is Anthropic's, and it was retired: the repository moved to modelcontextprotocol/servers-archived, which was archived on 2025-05-28 and has had no commits since. Its npm package, @modelcontextprotocol/server-gdrive, is still published — latest version 2025.1.14 — so npx installs it without complaint and it still works, which is exactly why it keeps getting recommended. What is worth knowing before you install it is how small it is. It exposes one tool, search, and returns file names and MIME types; everything else is MCP resources under gdrive:///<file_id>, and it authenticates read-only. The maintained alternative is taylorwilsdon/google_workspace_mcp — 3,020 stars, MIT, PyPI workspace-mcp 1.24.1 — which carries 16 Drive tools including writes and covers eleven other Workspace services on the same connection.

• →Is there an official Google Drive MCP server?
• →Why does the archived Google Drive MCP server only find files and not read them?

Google does not publish a Gmail MCP server. That single fact resolves most of the confusion around this term: the two MCP repositories in the googleworkspace GitHub organisation are for building on Workspace APIs, not for reading your mail, so every working Gmail setup is community-built. The one to install is taylorwilsdon/google_workspace_mcp — 3,021 stars, MIT, on PyPI as workspace-mcp — which covers Gmail as one of twelve Workspace services behind a single connection. The one most guides still name is GongRzhe/Gmail-MCP-Server, archived on 2025-08-06 with an npm package unpublished since the same day. It still installs cleanly, which is exactly why it keeps getting recommended.

• →Is there an official Google Gmail MCP server?
• →Why does @gongrzhe/server-gmail-autoauth-mcp still show up everywhere?

Asana ships an official MCP server and it is hosted, at https://mcp.asana.com/v2/mcp — so there is nothing to install, and one thing to create. V2 will not accept a generic OAuth client: you register your own app at app.asana.com/0/my-apps, get a client ID and secret, and set a redirect URL that matches your client exactly. The other fact worth reading before you connect it is that MCP apps in Asana do not use permission scopes at all. Authorising grants the full tool set, including deletes, and the only thing bounding it is what your own Asana account can already see.

• →Does the Asana MCP server have permission scopes?
• →Why does Asana search return nothing on my workspace?

There is no separate "Jira MCP server" from Atlassian. Jira is one product surface of a single hosted server — the Atlassian Rovo MCP Server — that also carries Confluence, Jira Service Management, Bitbucket Cloud and Compass, so connecting it once gives you all of them your account can see. The part that trips people up is the endpoint: the URL in most blog posts and in a lot of copied config is https://mcp.atlassian.com/v1/mcp, and the URL Atlassian now recommends is https://mcp.atlassian.com/v1/mcp/authv2. Both still resolve, and the older Server-Sent Events endpoint /v1/sse is still supported but explicitly on the way out — Atlassian tells custom clients to move off it. Use /mcp/authv2 for a browser OAuth 2.1 login, which is what almost everyone wants; /v1/mcp is the one the docs point at for API-token configurations. Nothing installs locally either way, so there is no package to fail and no version to pin.

• →Which Atlassian MCP endpoint should I use — /v1/mcp or /v1/mcp/authv2?
• →Why do I get "Your site admin must authorize this app"?

Confluence has no MCP server of its own. It is a product surface on the Atlassian Rovo MCP Server, the same hosted endpoint that serves Jira, so if you already connected for Jira you already have the Confluence tools and there is nothing else to install. What is worth reading separately is the tool surface, because it is shaped nothing like Jira's: content is addressed by page ID rather than by a human-readable key, search is CQL and not JQL, and comments split into two distinct types with separate create and read tools. Most disappointing first sessions with Confluence over MCP come from one of those three, not from the connection.

• →Do I need a separate Confluence MCP server if I already set up Jira?
• →Why does Confluence search ignore what I asked for?

Three different things get called "the HubSpot MCP server", and the one most write-ups describe is the one you probably do not want. The current answer for working with CRM data is a hosted remote server at https://mcp.hubspot.com, authorised with OAuth against a user-level app. Separately there is a Developer MCP server, installed locally through the HubSpot CLI with `hs mcp setup`, whose job is helping you *build HubSpot apps* — not query contacts. And there is the original May-2025 public beta, an npm package configured with a private-app access token; that is the version nearly every blog post still copies, and it is not what HubSpot documents today.

• →Does the HubSpot MCP server use a private app access token?
• →What is the HubSpot MCP server URL?

n8n-MCP is not a workflow execution engine, and expecting it to be one is the single biggest source of disappointment with it. What it is: a searchable reference to 2,412 n8n nodes (829 core, 1,583 community) with 99% property coverage, 66.5% operation coverage, 2,352 workflow templates, and validators that check a node config or a whole workflow *before* you deploy it. Give it your instance's API credentials and it gains a second half — 16 management tools that create, update, deploy and inspect workflows on that instance. It is also a community project by Romuald Czlonkowski (22.6k★, MIT), not something n8n publishes, and it is unrelated to n8n's own MCP Server Trigger node, which points the other way: that node makes an n8n workflow *into* an MCP server for clients to call.

• →Can n8n-MCP execute my n8n workflows?
• →Is n8n-mcp the official n8n MCP server?

There are two Notion MCP servers, both from Notion, and picking the wrong one is the most common way this setup goes sideways. The hosted remote server at mcp.notion.com/mcp needs no install and no token — you authorise it with OAuth from inside your client. The local npm server, @notionhq/notion-mcp-server, is the older one; its README now says Notion is only actively supporting the remote server and may sunset the repository. Use the remote server unless you specifically need to run the process yourself, pin a version, or point it at a self-managed deployment.

• →Why does Notion MCP search return nothing even though my token works?
• →Why did post-database-query stop working?

This server does not read your vault off disk. It talks to the Obsidian Local REST API community plugin over HTTP, which means Obsidian has to be running with that plugin enabled for any tool call to succeed — the single fact that explains almost every failed first attempt. The upside of the design is that you get Obsidian's own search and its heading- and block-aware patching rather than a naive file walker.

• →Why do all Obsidian MCP tool calls fail with a connection error?
• →Claude says it cannot find uvx — how do I fix it?

Linear's MCP server is first-party, remote, and centrally hosted — there is no repository to clone and no package to install, which is why this page has no GitHub link. You point a client at an HTTPS endpoint and authorise it. The detail worth knowing before you set it up is that there are two endpoints, and the read-only one is the better default for anything you are not supervising closely.

• →Is there a GitHub repo or npm package for the Linear MCP server?
• →How do I give an AI client read-only access to Linear?

The reason this server exists is that it will run in a workspace where you cannot install a Slack app. It accepts your own browser session tokens (xoxc plus xoxd) as an alternative to OAuth, so there is no admin approval step and no bot in the member list. That is also the reason to think before installing it: those tokens are your full user session. Two safer modes exist — a user OAuth token (xoxp) or a bot token (xoxb) — and each trades away some capability, which the table below spells out.

• →Why can't the Slack MCP server post messages?
• →Do I need a Slack admin to approve this?

Most write-ups of "the Stripe MCP server" describe a local npm package you run with your secret key. That is not what Stripe documents any more. The server Stripe operates is remote — https://mcp.stripe.com — and the connection mechanism it wants is OAuth, so the thing you paste into a client is a URL, not an API key. Two consequences follow, and they are the whole reason this page exists: the sessions you create are revocable from the Dashboard rather than being as long-lived as a key, and an administrator has to switch MCP access on per environment before any of it works. Secret-key auth still exists, but it is the fallback for clients that cannot do OAuth and the path for autonomous agents, where the guidance is to use a restricted key rather than a live secret key.

• →Is the Stripe MCP server an npm package I install locally?
• →What happened to the stripe/agent-toolkit GitHub repo?