Manual MCP setup per developer

Manual MCP setup per developer is the phase where MCP servers exist and work, but each developer is responsible for installing and configuring them independently. There is no centralized deployment, no standardized configuration management, and no enforcement that everyone has the same servers running. One developer might have Git and Jira connected; another has only Git; a third has Git, Jira, and a Postgres server they set up themselves; the fourth hasn't bothered at all.

This is the natural first organizational state after the proof-of-concept phase. Someone (usually Victor, or whoever is most enthusiastic about AI tools) gets MCP servers working on their machine, shares instructions in Slack or a README, and then each other developer follows the instructions with varying degrees of success. The setup process involves editing JSON configuration files, managing API credentials, installing npm packages, and troubleshooting server startup failures. Some developers get it working in an hour; others spend an afternoon and give up.

The problems with this state are not in the MCP servers themselves - they work fine once configured. The problems are in the organizational layer: no consistency of what's available, no auditing of what credentials are in use, no mechanism to push updates when server configurations change, and a support burden that falls on whoever did the original setup. When the Jira API token expires, every developer who configured it manually needs to update their own configuration individually.

Manual setup per developer is a transition state, not a destination. It proves MCP is valuable enough to invest in properly. The investment it motivates is a centralized MCP platform - where the organization manages server deployment, credential management, and configuration versioning as infrastructure rather than as individual developer homework.

• Creates the experience that motivates centralization - developers who struggle with manual setup understand viscerally why a centralized platform is worth building; the pain is the motivation
• Produces inconsistency that impacts team effectiveness - when half the team has Jira MCP connected and half doesn't, code review conversations, agent-generated artifacts, and knowledge sharing happen at different context levels across the team
• Exposes the credential management problem early - manually configured API tokens expire, get revoked, or get committed to config files; this surfaces the security problem at small scale where it's fixable, before it becomes an enterprise risk
• Generates requirements for the centralized platform - the specific friction points developers encounter during manual setup become the feature requirements for the MCP platform: centralized credential storage, auto-updates, standardized configurations
• Limits MCP adoption by making it a hurdle - developers who find the setup confusing or time-consuming don't complete it; manual setup creates an adoption ceiling based on technical comfort level rather than actual value

1. Write a definitive setup guide - document every step: which MCP servers to install, what credentials to create, what the configuration file should contain, and how to verify each server is working. Include troubleshooting for the 3-4 most common failure modes. This guide is the minimum viable "centralization" before a proper platform exists.
2. Standardize on a configuration template - provide a template MCP configuration file that developers copy and fill in with their credentials. This ensures every developer configures the same servers with the same settings. Post it in the repository rather than a wiki so it versions with the code.
3. Automate credential provisioning - instead of having each developer create their own API tokens, create a shared service account with the appropriate read permissions and distribute the token through a secrets manager. This eliminates per-developer credential management and makes rotation a one-step operation.
4. Create a validation script - write a script that tests each configured MCP server and reports whether it's returning data correctly. Developers run this after setup to confirm everything works. It also serves as the diagnostic tool when something breaks.
5. Track who has what configured - maintain a team register of which developers have which MCP servers configured. This isn't for enforcement; it's for support. When someone asks "why does my agent not know about my Jira tickets," the register tells you immediately whether they have the Jira server configured.

Letting credentials accumulate without rotation. Manual setup creates a sprawl of individually-created API tokens with different expiry dates and permissions. Without centralized tracking, tokens expire silently, causing mysterious MCP server failures. Establish a credential rotation schedule at the moment of initial setup, before the sprawl begins.

Assuming the setup guide stays current. MCP server APIs change, configuration formats evolve, and new servers become available. A setup guide written six months ago may be partially or completely outdated. Assign ownership of the guide to a specific person with a quarterly review responsibility. An outdated setup guide is worse than no guide because it creates false confidence.

Not detecting configuration drift. Developer A sets up MCP servers in January following the guide. By March, the guide has been updated, two new servers have been added, and one old server has been replaced. Developer A doesn't know. Their agent setup is three months stale while everyone else has the current configuration. Without a mechanism to detect and correct drift, the team's effective MCP coverage decreases over time as configurations diverge.

Treating "works on my machine" as done. A developer who gets MCP servers working in their environment has proven the servers work, not that the setup process is repeatable. Until three developers with different technical backgrounds have followed the setup guide and succeeded without help, the setup process is not reliable enough to call done.