Use these MCP server config examples as safe starting points for common setups: filesystem access, GitHub context, search or browser lookup, database access, and multiple servers in one mcpServers JSON object.
These snippets are independent reference examples for developers. They are not official documentation for any MCP client or server package, and you should verify the current server maintainer docs before using a config locally.
For a faster first draft, use the MCP Server Config Generator to create placeholder-based JSON in your browser, then compare it with the examples below before copying anything into Claude Desktop, Cursor, or another MCP client.
Key takeaways
- Most MCP config examples share the same basic shape: a top-level mcpServers object with named server entries.
- Use placeholder environment variables such as ${GITHUB_TOKEN}, ${BRAVE_API_KEY}, and ${DATABASE_URL} in public examples.
- Start with one read-only server, validate the JSON, then add higher-risk tools only after reviewing permissions and secrets.
What an MCP server config contains
An MCP server config tells a client how to start one or more MCP servers. The common shape is a top-level mcpServers object where each key is a local server name and each value contains a command, args, and optional environment variables.
The exact file location depends on the client. Claude Desktop, Cursor, custom apps, and local development wrappers may store configs differently, so use these examples as JSON entry templates and verify the client-specific setup guide before saving them.
- Server name under mcpServers
- command to launch the server
- args as an array
- optional env placeholders
- optional cwd when a server needs a working directory
Basic mcpServers JSON template
Start with the smallest possible config: one server entry, one command, and an args array. Validate the JSON before adding tokens, paths, or additional servers.
This example is intentionally generic. Replace the package name with the server package documented by the maintainer and keep real secrets out of public examples.
- Use valid JSON only
- No comments or trailing commas
- One server first
- Review package documentation
{
"mcpServers": {
"example-server": {
"command": "npx",
"args": [
"-y",
"example-mcp-server"
]
}
}
}Filesystem MCP server config example
A filesystem server is useful when an AI client needs to read or search local project files. Keep the allowed folders narrow, especially when testing a new workflow.
Do not point an example at an entire home directory or production secrets folder. Start with a sandbox project, docs folder, or read-only workspace if the server supports read-only behavior.
- Use explicit folder paths
- Avoid broad home-directory access
- Test with harmless files first
- Document allowed paths for teammates
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/your-name/Projects/example-app",
"/Users/your-name/Projects/example-app/docs"
]
}
}
}GitHub MCP server config example
A GitHub server can expose repository, issue, pull request, and organization context through MCP tools. Use the narrowest token scopes that satisfy the workflow.
Public docs, static pages, screenshots, and commits should only show placeholders such as ${GITHUB_TOKEN}. Put real values in a private local environment setup or secret manager according to the server and client documentation.
- Prefer read-only scopes for first tests
- Use placeholder token names in examples
- Review write-capable tools separately
- Rotate demo credentials after sharing screens
{
"mcpServers": {
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}Search or browser MCP server config example
Search and browser-oriented servers are useful for research, docs lookup, and web context. They also introduce prompt-injection risk because web pages and search results are untrusted content.
Use placeholder API keys in examples and keep browser/search tools separated from destructive actions. If a workflow needs write access, review it with a security checklist before enabling it.
- Treat web content as untrusted
- Use ${BRAVE_API_KEY} or similar placeholders
- Avoid mixing browsing with destructive tools
- Log and redact carefully
{
"mcpServers": {
"brave-search": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-brave-search"
],
"env": {
"BRAVE_API_KEY": "${BRAVE_API_KEY}"
}
}
}
}Database MCP server config example
Database MCP servers should be handled more carefully than simple read-only examples. Use a least-privilege account, prefer read-only roles for exploration, and avoid production databases during initial testing.
The exact package, driver, and connection string format depends on the server. Keep shared examples generic and use ${DATABASE_URL} instead of real credentials.
- Use read-only database roles
- Avoid production for first tests
- Scope access to selected schemas or views
- Never publish connection strings
{
"mcpServers": {
"database": {
"command": "npx",
"args": [
"-y",
"example-database-mcp-server"
],
"env": {
"DATABASE_URL": "${DATABASE_URL}"
}
}
}
}Multiple MCP servers in one config
Many clients can load more than one MCP server from the same mcpServers object. Use clear names and add servers incrementally so troubleshooting stays simple.
A practical developer setup might combine filesystem context, GitHub issues, search, and a database sandbox. Start with read-only capability and move write actions into a separate review path.
- Keep server names unique
- Add one server at a time
- Separate high-risk tools
- Remove stale server entries
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/your-name/Projects/example-app"
]
},
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
},
"brave-search": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-brave-search"
],
"env": {
"BRAVE_API_KEY": "${BRAVE_API_KEY}"
}
},
"database": {
"command": "npx",
"args": [
"-y",
"example-database-mcp-server"
],
"env": {
"DATABASE_URL": "${DATABASE_URL}"
}
}
}
}Pair config JSON with a .env.example file
Config examples are easier to share safely when paired with a .env.example file. The JSON references variable names, and the .env.example documents which variables are required without containing real values.
This pattern helps teams review secrets, rotate credentials, and onboard developers without copying private tokens into documentation.
- Keep real values out of Git
- Document each variable purpose
- Use separate dev and production credentials
- Rotate tokens after demos
GITHUB_TOKEN=your_github_token_here
BRAVE_API_KEY=your_brave_api_key_here
DATABASE_URL=postgres://user:password@localhost:5432/appSecurity checklist before enabling a config
Before enabling an MCP config, review what each server can read, what it can write, which credentials it uses, and how failures are logged. A config is not just installation data; it defines the operating boundary for an AI agent.
For high-risk servers, use a sandbox first, require human approval for writes, and document rollback steps. Treat prompts, web pages, issues, docs, and database rows as untrusted input that can contain malicious instructions.
- Read-only first
- Least-privilege scopes
- No committed secrets
- Sandbox write actions
- Redact logs and errors
- Document rollback steps
Implementation checklist
- Choose the MCP client and workflow first
- Copy one server entry at a time
- Keep args as an array, not a shell string
- Use narrow filesystem paths
- Use placeholder env values in shared examples
- Pair secrets with a .env.example file
- Validate JSON before saving
- Restart or reload the MCP client after edits
- Test read-only actions before write actions
- Run a security checklist before enabling production credentials
FAQ
What is an MCP server config example?
It is a JSON snippet that shows how an MCP client can launch a server with a local name, command, arguments, and optional environment variables.
What does mcpServers mean?
mcpServers is the common top-level object used in many MCP client config examples. Each key inside it names one server entry.
Can I use the same MCP server config in Claude Desktop and Cursor?
Often the server entry is similar, but the file location and client-specific setup can differ. Verify the client documentation before copying a config.
Should MCP config examples include real API keys?
No. Public examples should use placeholders such as ${GITHUB_TOKEN}, ${BRAVE_API_KEY}, and ${DATABASE_URL}. Use real values only in private local setup.
Why is my MCP server config not working?
Common causes include invalid JSON, trailing commas, a wrong command, missing Node.js or npx, a bad local path, missing environment variables, or using the wrong client config location.
Can a static website safely generate MCP server config JSON?
Yes, if generation happens entirely in the browser and outputs placeholder-based templates. It should not collect tokens, call an AI API, store configs, or upload local files.