How to Share MCP Config Across a Dev Team
Before You Start
You need a project repository that team members clone and work in, and at least one MCP server that the team shares (like a memory server, a database tool, or a documentation search tool). The MCP client each team member uses (Claude Code, Cursor, or another client) must support project-level configuration files.
Step-by-Step Configuration
Add a
.mcp.json file to the root of your project repository. This file defines the MCP servers that every team member should have access to when working on this project. Because it is committed to the repository, everyone who clones the project gets the same server configuration automatically.
{
"mcpServers": {
"project-memory": {
"type": "url",
"url": "https://mcp.adaptiverecall.com/mcp",
"headers": {
"Authorization": "Bearer ${ADAPTIVE_RECALL_KEY}"
}
},
"project-db": {
"command": "python",
"args": ["./tools/db_server.py"],
"env": {
"DATABASE_URL": "${PROJECT_DB_URL}"
}
}
}
}${VAR_NAME} syntax in configuration values. Check your MCP client's documentation for the exact syntax it uses for environment variable expansion. Some clients resolve variables at startup, others at connection time.
Never hardcode API keys, tokens, or passwords in the config file. Use environment variable references so the config file is safe to commit. Each developer sets the actual values in their local environment, typically through a
.env file (which is gitignored), shell profile, or secrets manager.
Create a .env.example file that documents the required variables without containing actual values:
# MCP Server Credentials
# Get your Adaptive Recall key from: https://app.adaptiverecall.com/settings
ADAPTIVE_RECALL_KEY=your-key-here
# Project database connection
PROJECT_DB_URL=postgres://user:pass@localhost/projectdbAdd .env to .gitignore so actual credentials are never committed. Each developer copies .env.example to .env and fills in their own credentials.
Add a section to your project's README or developer documentation that explains how to set up MCP tools. Include where to get credentials, which environment variables to set, and how to verify the connection works. New team members should be able to get all MCP tools working by following the documentation without asking anyone for help.
## MCP Tools Setup
This project uses MCP servers for AI-assisted development.
1. Copy `.env.example` to `.env`
2. Get your Adaptive Recall API key from the team vault
3. Set `ADAPTIVE_RECALL_KEY` in your `.env` file
4. Set `PROJECT_DB_URL` to your local database connection string
5. Restart your AI client (Claude Code, Cursor, etc.)
6. Verify: ask the AI "What do you remember about this project?"Team members may want additional MCP servers beyond the shared ones, such as personal note-taking tools, experiment servers, or alternative implementations for testing. These go in the global configuration file (like
~/.claude/settings.json), not in the project config. This keeps the shared config clean and focused on tools that everyone needs.
When a developer has both global and project-level configurations, the client merges them. Global servers load first, then project servers add to the list. If a developer wants to override a shared server with a personal variant, they can define a server with the same name in their global config, which takes precedence for their machine only.
When you add a new shared server, update the
.mcp.json file and the .env.example file in the same commit. Mention the change in your pull request description so reviewers know to update their local .env. When a server URL, parameter, or authentication method changes, update the config and notify the team through your normal communication channels.
Team Memory Patterns
A particularly valuable shared server is a team memory system. When the whole team connects to the same memory backend, the AI assistant for each developer can access institutional knowledge that the team has collectively stored: architectural decisions, coding conventions, deployment procedures, and debugging insights. New team members get the benefit of accumulated context immediately, and knowledge does not disappear when someone goes on vacation or changes teams.
Adaptive Recall supports team configurations where each developer has their own API key but all keys point to a shared memory store. Individual usage patterns (base-level activation, access frequency) are tracked per user, so the retrieval ranking reflects each developer's own interaction history while the underlying knowledge is shared.
Configuration for Multiple Clients
Different team members may use different AI clients. Claude Code reads .mcp.json, Cursor reads .cursor/mcp.json, and other clients have their own paths. You can maintain separate config files for each client, but this creates a maintenance burden. A simpler approach is to standardize on one config format and provide documentation for team members who use different clients on how to adapt the configuration.
If your team uses multiple clients, consider creating a script that generates client-specific configs from a single source of truth. A simple Python or shell script that reads the canonical config and writes it in each client's format eliminates drift between configurations.
Give your whole team AI memory that accumulates knowledge. Adaptive Recall supports team configurations where shared knowledge benefits every developer.
Get Started Free