Question 10
Domain 1Situation: Your team wants to add a GitHub MCP server for searching PRs and checking CI status via Claude Code. Each of six developers has their own personal GitHub access token. You want consistent tooling across the team without committing credentials to version control. Which configuration approach is most effective?
Correct answer: C
Explanation
Using the project ".mcp.json" gives the whole team the same Claude Code MCP setup, while "environment variable substitution (${GITHUB_TOKEN})" keeps personal tokens out of version control. Documenting the required variable in the README lets each developer supply their own credential without hardcoding secrets.
Why each option is right or wrong
A. Have each developer add the server in user scope via claude mcp add --scope user.
User-scope setup avoids shared credentials, but it does not provide consistent project-wide configuration.
B. Create an MCP server wrapper that reads tokens from a .env file and proxies GitHub API calls, then add the wrapper to the project .mcp.json.
A custom wrapper adds unnecessary complexity when environment variables already solve secret injection cleanly.
C. Add the server to the project .mcp.json using environment variable substitution (${GITHUB_TOKEN}) for auth and document the required environment variable in the project README.
Claude Code’s project-scoped MCP configuration is the right place to standardize a server for everyone on the team, because a checked-in `.mcp.json` is shared by all contributors to that repository. Using `${GITHUB_TOKEN}` in the auth field avoids storing any personal access token in Git history, and the README can instruct each developer to export their own token locally before running the project.
D. Configure the server in project scope with a placeholder token, then tell developers to override it in their local config.
Placeholder secrets in shared config encourage brittle overrides and can confuse the source of truth.