MCP Guides by Client and Server Type
There are two ways people arrive at an MCP setup guide. Some already know which server they want and need the config for the editor in front of them. Others know they want their AI assistant reading Jira, or querying a warehouse, and have not settled on a tool yet.
So the library is indexed both ways below. The client hubs collect everything documented for a given editor, including the client-agnostic material on credentials, transports and debugging that carries over regardless. The category hubs group servers by the system they talk to, which is the faster route when you are comparing options rather than following instructions.
Browse by client
Pick the app you are configuring. Each hub opens with the general setup path for that client before listing individual server guides.
Cursor IDE
Cursor reads its MCP configuration from an mcp.json file, and the shape of that file is the same no matter which server you are adding. What changes between servers is the credential: some want an API token in an env block, some hand off to a hosted endpoint over OAuth, and a few reuse a CLI session you have already authenticated.
103 guides
Claude Desktop
Claude Desktop stores its servers in claude_desktop_config.json, and the most common reason a new server never shows up is that the file was edited in the wrong location or the app was not fully restarted. The troubleshooting guide below walks that failure down step by step.
25 guides
VS Code and Copilot
VS Code reaches MCP servers through Copilot agent mode, and Continue.dev offers a second route into the same editor for people who would rather run an open-source assistant. The two use different config files, so the guides below cover each separately.
20 guides
Windsurf
Windsurf has its own MCP configuration path, so a walkthrough written for Cursor will not transfer line for line. The setup guide below covers the Windsurf side, and the comparison piece looks at where the two editors differ on MCP support.
19 guides
Browse by server type
Grouped by the system on the other end of the connection, since servers that talk to the same kind of system tend to share the same credential model and the same failure modes.
Issue tracking
Issue trackers are the integration people reach for first, because the alternative is alt-tabbing to a browser every time a ticket number comes up in a code review. Each server here exposes some mix of searching issues, reading a ticket, and writing status changes back.
9 guides
Docs and knowledge
The servers in this group answer a different question from the tool-calling ones: instead of doing something, they put the right text in front of the model before it writes any code. That covers internal wikis, shared drives, the files on your own disk, and the current docs for whatever library you are using.
10 guides
Code and CI/CD
These servers put your repositories, pipelines and API collections in reach of the assistant, which is what turns "explain this stack trace" into "explain this stack trace and show me the commit that introduced it". Most of them are token-based, and the token scope is the whole security story.
7 guides
Databases
Database servers are the highest-leverage and highest-risk group on the site. An assistant that can read your schema stops guessing at column names, but the same connection can run a statement you did not intend, so most of these guides spend real time on read-only credentials.
19 guides
Cloud and deployment
Infrastructure servers tend to skip the API-token dance. AWS reuses the credential chain you already configured with the CLI, Fly.io and Railway generate the config from their own command line tools, and several platforms hand off to OAuth in the browser.
15 guides
Observability
The appeal here is short: the assistant already has your code open, and these servers give it the runtime evidence to go with it. A stack trace from Sentry or a spike from a Datadog dashboard turns a vague bug report into something specific.
6 guides
Design and content
Design and CMS servers close the gap between where content is authored and where it gets shipped. The Figma server reads file structure through the REST API, which is what makes design-to-code prompts possible without anyone exporting assets by hand.
8 guides
Communication
Messaging servers are how an assistant reports back to people rather than just to you. They are also the group where scopes deserve the most attention, because a bot token that can post anywhere is a bot token that can post anywhere by mistake.
8 guides
Payments and business tools
This group covers the systems that hold customer and revenue data, which changes the calculus on access. Reading a subscription to debug a webhook is routine; letting the same connection create charges is a decision that needs to be deliberate.
11 guides
Identity and secrets
Identity providers are an unusual thing to hand an assistant, and the guides here treat them that way. Managing tenants, applications and users from chat is genuinely useful during setup work, but the same connection reaches the system that guards everything else.
5 guides
Search and automation
Search and browser servers exist because a model working from training data alone will confidently describe an API that changed months ago. These fetch the current page instead, whether that means a search result, a rendered site, or a cited answer.
11 guides
New to the protocol?
If you have not set up a server before, read the plain-English introduction to MCP first, then the breakdown of tools, resources and prompts, which explains why some servers can act on your behalf and others only supply context. When you are ready to wire something up, the authentication guide covers the credential patterns you will meet, and the server-side security checklist is worth a pass before anything reaches production. The full article index has everything else.