There are two reasons most people who could benefit from MCP servers are not running any of them. First, they have not heard about MCP. The second, and the one this tool addresses, is that picking the right servers and writing the configuration file is genuinely a small project. Each server has its own command, its own arguments, its own environment variables, its own auth flow. The official Anthropic docs are good, but they describe the protocol, not which specific servers a particular team should install for a particular use case.
The MCP Server Recommender at /tools/mcp-server-recommender/ is the shortcut. You walk a checklist of what your team actually uses (GitHub? Linear? Atlassian? Stripe? Postgres? Sentry?). It builds the matching claude_desktop_config.json and prints it ready to paste.
What is in the checklist
The checklist groups servers by category, mirrored from the broader MCP servers by industry guide:
- Software engineering and DevOps: GitHub (vendor), Azure DevOps (vendor), Playwright (vendor), Sentry (vendor), Microsoft Markitdown (vendor), Filesystem (reference), Git (reference), Web Fetch (reference)
- Project management: Linear (vendor remote), Atlassian Jira and Confluence (vendor remote), Notion (vendor remote), Slack (vendor remote)
- CRM and customer support: Salesforce (vendor remote), HubSpot (community), Intercom (vendor remote)
- Finance and payments: Stripe (vendor remote), Block (vendor remote), PayPal (vendor remote)
- Data and databases: PostgreSQL (reference), Supabase (vendor), Microsoft Clarity (vendor)
- Marketing, content, search: Brave Search (vendor), Ahrefs MCP (vendor remote), Firecrawl (vendor)
- Infra and observability: Cloudflare Workers/KV/R2/D1 (vendor), Netdata (vendor remote)
Each server is labeled by maintenance posture: green for vendor-published (highest reliability), blue for the official MCP reference set (educational and stable), amber for community-maintained (use when no vendor exists; verify before production).
What the output looks like
The tool emits a complete claude_desktop_config.json file with the mcpServers block populated. Local-process servers get their command, args, and env filled in with placeholders for tokens. Remote-hosted servers get their url. Below the config block, a per-server notes panel explains what auth each server expects and how to scope tokens to read-only where the vendor supports it.
A typical config for an engineering-heavy user looks like this:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your_github_pat>" }
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
},
"git": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-git"]
},
"fetch": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-fetch"]
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres",
"postgresql://readonly_user:<password>@localhost:5432/<dbname>"]
},
"sentry": {
"command": "npx",
"args": ["-y", "@sentry/mcp-server"],
"env": { "SENTRY_AUTH_TOKEN": "<sentry_token>", "SENTRY_ORG": "<your_org_slug>" }
}
}
}
You save that as claude_desktop_config.json in the platform-appropriate location (~/Library/Application Support/Claude/ on macOS, %APPDATA%\Claude\ on Windows), replace the placeholder values, restart Claude Desktop, and the model can call those tools immediately.
What the tool deliberately does not do
It does not store or transmit the config anywhere. The output is rendered into the page; what you do with it is your business.
It does not contain a token-leakage warning on every server. The notes panel calls out the auth model per server (e.g., "use a fine-grained PAT scoped to specific repos for GitHub"; "always use a read-only Postgres role"). The general principle is that you scope tokens to read-only by default and elevate only when an agent needs to write.
It does not include MCP servers I cannot personally vouch for. There are dozens of community MCP servers in the broader ecosystem; the tool sticks to vendor-published, official MCP reference, and a small set of well-maintained community servers. The shorter list is more useful than a comprehensive one.
It does not solve the security review. Connecting MCP servers to live systems introduces new attack surface, particularly for write-capable servers. Run the audit your security team would run before pointing any agent at a production datastore.
Why this is on jwatte.com
The mission of this site is free SMB self-help. MCP is one of the most underused productivity step-changes available to a small team that does not have a DevOps engineer to wire up integrations. The tool removes the configuration friction. Once it is in place, the team can have a single Claude Desktop conversation that searches GitHub, queries Postgres, summarizes Sentry issues, drafts a Linear ticket, and posts to Slack, all from one window.
That kind of leverage was previously the kind of thing you bought from Zapier or n8n. With MCP and a vendor-published server stack, the cost is the time to install Claude Desktop and paste a config file.
Related reading
- The Best MCP Servers By Industry for the deep dive on which servers to use for which industries
- The Conversation Has Moved Past The Model for the broader runtime-layer shift the MCP ecosystem sits on top of
- What Actually Fixed My Claude Code Sessions for the prompt-and-process discipline that benefits from MCP-extended capability
- Inside Quadrature Capital and Radix Trading for an example of where MCP integration would extend the kind of research workflows the broader ecosystem is enabling
Fact-check notes and sources
- GitHub MCP Registry: github.com/mcp
- Official MCP organization, reference servers, SDKs: github.com/modelcontextprotocol, modelcontextprotocol/servers, example servers documentation
- Vendor catalogs: microsoft/mcp, github/github-mcp-server, getsentry/sentry-mcp, Atlassian remote MCP announcement, Cloudflare MCP demo day
Connecting MCP servers grants the model real access to your systems. Use vendor-published servers where available; scope tokens to read-only by default; never store secrets in committed config; never expose write-capable servers to public-facing agents without security review.
