Installing an MCP server is more than copying an npm command. You need to decide which client will run it, what data it can access, where credentials live, and how you will test the server before real work.
This guide gives a safe, client-neutral setup flow for Claude Desktop, Cursor, and other MCP clients. Use placeholders in examples, then configure real values only in private local settings or platform secrets.
Key takeaways
- Choose the MCP client and workflow before installing servers.
- Start with one low-risk server and one harmless test call.
- Keep real tokens, database URLs, and private paths out of shared examples.
1. Choose the MCP client and server
Start with the client where the workflow will happen: Claude Desktop for personal research and writing, Cursor for coding, or another client for agent infrastructure. Then choose one server category that maps to a real task.
Avoid installing every interesting server at once. A narrow first setup makes it easier to debug startup errors and permission boundaries.
- Claude Desktop for local assistant workflows
- Cursor for coding workflows
- Filesystem for selected folders
- GitHub for repository collaboration
- Database servers for read-only schema and query tests
2. Create an mcpServers config entry
Most clients use an mcpServers-style JSON object with a command, args, and optional environment variables. Public examples should use placeholder values only, such as GITHUB_TOKEN or DATABASE_URL.
After editing config, restart the client so it can discover the server. If startup fails, check command paths, package names, permissions, and environment variable names before changing server scope.
- Use absolute paths when the client requires them
- Keep credentials outside committed files
- Restart the MCP client after config edits
- Verify server discovery before real tasks
3. Test with harmless data
The first test should prove that the server starts and one low-risk tool works. Use a sample folder, test repository, sandbox database, or non-sensitive channel before production resources.
For write-capable servers, run a preview or read-only workflow first. Do not let the first successful startup become production approval.
- Read a sample file
- List a test repository issue
- Query a sandbox table
- Open a public documentation page
- Confirm errors do not reveal secrets
4. Add security review before production
Before connecting private files, production databases, or external write actions, document the server purpose, allowed data, credentials, logging behavior, approval rules, and rollback plan.
Use the security checklist generator if you need a browser-only review artifact without uploading configs or secrets.
- Least-privilege credentials
- Read-only roles first
- No broad home-directory access
- Human approval for writes
- Redacted logs and errors
Implementation checklist
- Pick one client and one server
- Use placeholder-only public config examples
- Restart the client after config edits
- Run one harmless test call
- Keep real secrets private
- Review permissions before production data
FAQ
What is the easiest MCP server to install first?
A filesystem server scoped to a sample folder is often the easiest first test because it does not need third-party API credentials.
Can I install MCP servers with npm?
Many servers run through npx or npm packages, but the exact command depends on the server maintainer and client config format.
Where should MCP secrets go?
Real tokens and database URLs should stay in private local config, environment variables, or platform secrets, not in shared examples or committed files.
Do I need a different setup for Claude and Cursor?
The server concept is the same, but client config paths, restart behavior, and UI details differ. Verify the current docs for your client.
Should I connect production databases immediately?
No. Start with sandbox data or read-only roles, then review logging, scopes, and approval rules before production access.