MCP Ecosystem and Servers
Four months after MCP's release, the community had built over 1,000 servers. That is not a slow start - that is an explosion. Every major developer tool now has one. Databases, code editors, project management systems, communication platforms, cloud providers - all have MCP servers maintained by either the vendor or the community.
A senior developer relations engineer at a mid-size SaaS company described the situation this way: "We connected Claude Desktop to GitHub, Linear, Postgres, and our internal runbook filesystem on a Tuesday morning. By Wednesday, engineers were asking questions like 'which Linear tickets are related to the auth service slowdown we saw last week?' and getting actual answers - not general guidance, but answers based on their actual tickets, their actual codebase, their actual database. The AI went from a general assistant to a teammate who knew our stack."
This is what the MCP ecosystem enables. Not AI assistants that know about generic things, but AI assistants that know about your things - your repositories, your databases, your documentation, your incidents. The ecosystem makes this accessible without building custom integrations for every tool.
Understanding the ecosystem - what is available, how to evaluate it, how to configure it, and how to decide when to build your own server versus using an existing one - is practical knowledge that immediately accelerates what you can do with AI-assisted development.
Why This Exists
The Integration Library Problem
Before MCP, every AI application that needed tool access had to maintain its own integration library. The GitHub integration for one application's AI was different from the GitHub integration for another. Both had to be updated independently when GitHub changed their API. Both had different authentication approaches, different error handling patterns, different rate limiting strategies.
The result was a fragmented ecosystem where every organization was solving the same problems independently. Security vulnerabilities discovered in one integration were not automatically fixed in others. Best practices discovered by one team were not shared with others. The work was duplicated thousands of times across thousands of organizations.
MCP's standardization creates a different dynamic: tool providers build and maintain a single server, which all MCP clients benefit from immediately. Security improvements propagate to everyone. Performance optimizations are shared. The GitHub MCP server maintained by Anthropic is reviewed by thousands of users, improved by dozens of contributors, and updated promptly when the GitHub API changes.
Ecosystem Momentum
Three dynamics drove rapid adoption after MCP's November 2024 release:
Low implementation barrier. Building a basic MCP server is a weekend project. The mcp Python SDK reduces the core implementation to defining tool schemas and handler functions. Within days of the spec release, the community was shipping servers.
High reuse multiplier. Any server created by one developer can be used by every MCP client immediately. Building an MCP server for Notion benefits every Claude Desktop user who uses Notion - without those users needing to do any integration work.
Network effects. As more servers become available, MCP clients become more powerful. As clients become more powerful, more users adopt them. As more users adopt them, more tool providers build servers. The two-sided market feeds itself.
:::tip 🎮 Interactive Playground Visualize this concept: Try the MCP Architecture demo on the EngineersOfAI Playground - no code required. :::
Historical Context
The MCP server ecosystem grew in three phases following the November 2024 specification release.
Phase 1 (November–December 2024): Official launch. Anthropic shipped seven official servers simultaneously with the spec: filesystem, GitHub, Google Drive, Slack, Postgres, Puppeteer, and Brave Search. These served as reference implementations and demonstrated the range of what MCP servers could cover.
Phase 2 (January–February 2025): Community explosion. Open-source contributors rapidly expanded coverage. The awesome-mcp-servers GitHub repository grew from a few dozen entries to several hundred. Major developer tool vendors - JetBrains, GitLab, Notion, Linear, Stripe - began shipping official servers. The MCP community Discord reached 5,000 members.
Phase 3 (March 2025+): Enterprise adoption. Enterprise software vendors including Salesforce, SAP, and ServiceNow announced MCP server development. Enterprise security firms began auditing community servers. MCP registries with quality scoring and security scanning emerged.
Official Anthropic Servers
Anthropic maintains reference implementations at github.com/modelcontextprotocol/servers. These are the gold standard: well-documented, actively maintained, and designed as examples of best practices.
filesystem
Package: @modelcontextprotocol/server-filesystem (npm) / available in Python reference
What it does: Provides controlled read/write access to local file system directories. Supports listing, reading, writing, searching, and moving files. Configured with an explicit list of allowed directories.
Key tools: read_file, write_file, list_directory, move_file, search_files, create_directory
Best for: Reading documentation, config files, local code. Writing generated files. Organizing workspace contents.
Security note: Scope the allowed directories tightly. Giving access to the entire home directory is a significant risk.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"/Users/yourname/projects/current",
"/tmp/ai-workspace"
]
}
}
}
github
Package: @modelcontextprotocol/server-github (npm)
What it does: Full GitHub integration - repositories, pull requests, issues, code search, file contents, branches, commits. Requires a GitHub personal access token.
Key tools: list_repos, get_file_contents, search_code, search_issues, create_pr, list_commits, get_pr, create_issue
Best for: Code review assistance, issue triage, searching across codebases, PR summarization.
Required scopes: repo (for private repos) or public_repo (for public only). Add read:org for organization context.
{
"mcpServers": {
"github": {
"command": "npx",
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
}
}
}
}
postgres
Package: @modelcontextprotocol/server-postgres (npm)
What it does: PostgreSQL database access - schema inspection, read-only queries by default. Connects to a database and exposes its tables as resources, with tools for querying and schema inspection.
Key tools: query (SELECT only by default), list_tables, describe_table
Best for: Data analysis, answering questions about database contents, schema documentation, debugging data issues.
Security note: Use a read-only database user. The server's default mode allows SELECT only - do not configure write access unless you have explicit human-in-the-loop controls.
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": [
"-y",
"postgresql://readonly_user:password@localhost:5432/mydb"
]
}
}
}
slack
Package: @modelcontextprotocol/server-slack (npm)
What it does: Slack workspace integration - read messages from channels, search message history, post messages, list channels. Requires a Slack Bot Token.
Key tools: list_channels, get_channel_history, search_messages, post_message
Best for: Searching for context from past discussions, summarizing channel activity, posting AI-generated summaries or reports.
Required scopes: channels:read, channels:history, chat:write, search:read
puppeteer
Package: @modelcontextprotocol/server-puppeteer (npm)
What it does: Headless browser automation - navigate to URLs, take screenshots, fill forms, extract page content, interact with web UIs.
Key tools: navigate, screenshot, click, type, get_page_content
Best for: Web scraping, testing web UIs, capturing screenshots for documentation, extracting data from pages that require JavaScript.
Note: Requires Chrome/Chromium installed on the host machine.
The Community Ecosystem
Beyond official servers, the community has built hundreds of servers covering nearly every major tool category.
Developer Tools
| Server | What It Does | Popularity |
|---|---|---|
mcp-server-git | Local git operations - status, diff, log, commit | Very High |
mcp-server-docker | Docker container management - list, start, stop, logs | High |
mcp-server-kubernetes | Kubectl operations, pod management, log access | High |
mcp-server-aws | AWS SDK operations - S3, EC2, CloudWatch, Lambda | High |
mcp-server-terraform | Terraform plan, apply, state inspection | Medium |
mcp-server-datadog | Metrics, logs, monitors, dashboards via Datadog API | Medium |
Databases
| Server | What It Does |
|---|---|
mcp-server-mysql | MySQL/MariaDB queries and schema inspection |
mcp-server-mongodb | MongoDB collection queries and document access |
mcp-server-redis | Redis key inspection and query |
mcp-server-sqlite | SQLite file database queries |
mcp-server-snowflake | Snowflake data warehouse queries |
mcp-server-bigquery | Google BigQuery queries |
Productivity and Communication
| Server | What It Does |
|---|---|
mcp-server-notion | Notion page and database read/write |
mcp-server-linear | Linear issue management and project tracking |
mcp-server-jira | Jira issue search, create, update |
mcp-server-confluence | Confluence page read and search |
mcp-server-gmail | Gmail read, search, draft |
mcp-server-calendar | Google Calendar event management |
AI and Search
| Server | What It Does |
|---|---|
mcp-server-exa | Exa AI-powered web search with semantic search |
mcp-server-perplexity | Perplexity AI search integration |
mcp-server-arxiv | arXiv paper search and abstract retrieval |
mcp-server-wikipedia | Wikipedia article search and retrieval |
MCP Registries
Several registries have emerged to help discover and evaluate MCP servers:
GitHub: modelcontextprotocol/servers - The official repository. Contains official Anthropic servers plus a curated list of community servers with basic documentation.
awesome-mcp-servers - Community-maintained GitHub repository with categorized server listings. Good for discovery; limited quality signal.
mcp.so - Community registry with search, categories, and basic server metadata. Growing rapidly but limited quality scoring.
Glama MCP Registry - Includes automated security scanning and quality scoring. More useful for enterprise evaluation.
What to Look for in a Registry
When using any MCP registry, registries are primarily for discovery. Evaluation must be done by you. A server listing does not imply:
- Security review
- Code quality
- Active maintenance
- Compatibility with your environment
- Suitability for production use
Evaluating Third-Party MCP Servers
Before connecting any community MCP server to a production environment, evaluate it against these criteria:
Security Evaluation
# A checklist you should mentally (and sometimes literally) run
# before deploying any community MCP server
class McpServerEvaluation:
"""Structured evaluation framework for third-party MCP servers."""
def __init__(self, server_name: str, repo_url: str):
self.server_name = server_name
self.repo_url = repo_url
self.checks: dict[str, bool | str] = {}
def check_source_availability(self) -> None:
"""Is the source code publicly available and reviewable?"""
# Cannot safely use a server whose code you cannot read
self.checks["open_source"] = True # Verify manually
def check_path_validation(self) -> None:
"""For filesystem servers: does it validate paths correctly?"""
# Look for: Path.resolve(), relative_to(), or equivalent
# Red flag: startswith() string comparison for path validation
self.checks["path_validation"] = "Review source"
def check_sql_injection_prevention(self) -> None:
"""For database servers: are queries parameterized?"""
# Look for: f-string SQL construction (BAD), asyncpg $1 parameters (GOOD)
self.checks["sql_parameterized"] = "Review source"
def check_credential_handling(self) -> None:
"""Are credentials only read from env vars, not hardcoded?"""
# Look for: os.environ.get(), no hardcoded strings for tokens
self.checks["env_var_credentials"] = "Review source"
def check_maintenance_health(self) -> None:
"""Is the server actively maintained?"""
# Check: last commit date, open issues, response to bug reports
self.checks["last_commit_recent"] = "Check GitHub"
self.checks["issues_addressed"] = "Check GitHub issues"
def check_version_pinning(self) -> None:
"""Can you pin an exact version for repeatable deployments?"""
# npm: check for specific version tags
# pip: check for proper version releases on PyPI
self.checks["version_pinnable"] = "Check npm/PyPI"
def generate_report(self) -> str:
return f"""
MCP Server Evaluation: {self.server_name}
Repository: {self.repo_url}
Required before production use:
{''.join(f" [{'' if v is True else '?'}] {k}: {v if v != True else 'PASS'}" for k, v in self.checks.items())}
Deploy only if all security checks pass.
"""
The Five-Question Evaluation
For each community MCP server you consider deploying:
- Can I read the source code? If not, do not deploy it.
- What is the worst thing this server could do? If a compromised version of this server ran, what could it do? Is that acceptable given what it can access?
- How does it handle authentication? Are credentials passed as environment variables? Are they logged anywhere?
- Is it actively maintained? When was the last commit? Are security issues reported and fixed?
- Can I pin an exact version? Can I ensure that what I deploy today is exactly what I test and review?
IDE Integrations
The most impactful MCP deployment for individual developers is IDE integration - connecting AI coding assistants directly to MCP servers for tool access within the development workflow.
Cursor
Cursor is an AI-first code editor with native MCP support. MCP servers configured in Cursor give the AI assistant access to tools while you work.
Configuration: ~/.cursor/mcp.json
{
"mcpServers": {
"filesystem": {
"command": "npx",
},
"github": {
"command": "npx",
"env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."}
},
"postgres": {
"command": "npx",
}
}
}
With this configuration, you can ask Cursor's AI assistant: "What is the schema of the users table? How does the auth service handle token refresh? Are there any open GitHub issues related to the auth timeout error I am seeing?" - and get answers grounded in your actual codebase and database.
Zed
Zed is a high-performance code editor with MCP support built into its AI extension. Configuration is similar to Cursor.
Configuration: ~/.config/zed/settings.json
{
"context_servers": {
"filesystem": {
"command": {
"path": "npx",
}
}
}
}
VS Code
VS Code's GitHub Copilot extension added MCP support in early 2025. The configuration is workspace-level (.vscode/mcp.json), making it easy to include in project repositories:
{
"servers": {
"filesystem": {
"type": "stdio",
"command": "npx",
},
"github": {
"type": "stdio",
"command": "npx",
"env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"}
}
}
}
Committing .vscode/mcp.json to the repository means all team members get the same MCP configuration automatically when they open the project.
Claude Desktop Configuration
Claude Desktop is the reference MCP client. It loads MCP servers at startup based on its configuration file.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
A Complete Developer Setup
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"/Users/yourname/projects",
"/tmp/ai-workspace"
]
},
"github": {
"command": "npx",
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token"
}
},
"postgres": {
"command": "npx",
"args": [
"-y",
"postgresql://readonly:password@localhost:5432/mydb"
]
},
"slack": {
"command": "npx",
"env": {
"SLACK_BOT_TOKEN": "xoxb-your-token",
"SLACK_TEAM_ID": "T1234567"
}
},
"internal-runbooks": {
"command": "python",
"args": ["/opt/internal-mcp/runbook_server.py"],
"env": {
"MCP_ALLOWED_DIRS": "/Users/yourname/runbooks"
}
}
}
}
Multi-Server Composition
When multiple MCP servers are connected simultaneously, Claude sees all their tools aggregated into a single tool list. This enables cross-server workflows:
User: "Find all GitHub PRs related to the auth service slowdown we
discussed in Slack last week. Then check if any of them
affected the users table schema."
Claude's internal reasoning:
1. Search Slack (slack MCP server): "auth service slowdown" → finds discussion thread
2. Extract PR numbers from Slack discussion
3. Get PR details from GitHub (github MCP server): fetches each PR
4. Inspect database schema (postgres MCP server): checks users table
5. Synthesizes findings across all three sources
No single MCP server handles this - the combination of three servers enables a workflow that was previously impossible without manual context switching.
Building for the Ecosystem vs. Building for Your Team
A key decision when building an MCP server: should you build it for public ecosystem use (anyone can install it) or for internal team use only?
When to Build for Internal Use Only
- The server accesses proprietary internal APIs with no public documentation
- Authentication uses internal SSO that external users cannot access
- The tool descriptions encode company-specific domain knowledge
- Security requirements make public disclosure inappropriate
- The integration is highly specific to your team's workflow
Approach: Build quickly, do not invest in general configurability, deploy in your internal package registry, prioritize functionality over polish.
When to Build for the Ecosystem
- The underlying tool (Jira, Linear, Notion) is widely used by others
- No existing MCP server covers this tool adequately
- The integration is generic enough to be useful without customization
- You can maintain it publicly over time
Approach: Follow the official server patterns, use environment variable configuration for all credentials, write comprehensive README documentation, publish to npm or PyPI with proper versioning, list in community registries.
CI/CD Integration Patterns
MCP servers can be integrated into CI/CD pipelines for automated workflows:
"""
CI integration: use MCP to connect a CI agent to
code review tools, deployment systems, and monitoring.
"""
import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
async def ci_code_review_agent(pr_number: int, repo: str) -> str:
"""
Agent that uses MCP to perform automated code review.
Runs in CI, posts review comments to GitHub.
"""
server_params = StdioServerParameters(
command="npx",
env={"GITHUB_PERSONAL_ACCESS_TOKEN": os.environ["GITHUB_TOKEN"]}
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
# Get PR details
pr_result = await session.call_tool(
"get_pull_request",
{"owner": repo.split("/")[0], "repo": repo.split("/")[1], "pullNumber": pr_number}
)
# Get the diff
diff_result = await session.call_tool(
"get_pull_request_files",
{"owner": repo.split("/")[0], "repo": repo.split("/")[1], "pullNumber": pr_number}
)
# Use the data for AI review (integrate with Anthropic SDK)
import anthropic
client = anthropic.Anthropic()
review = client.messages.create(
model="claude-opus-4-6",
max_tokens=2000,
messages=[{
"role": "user",
"content": f"""Review this PR and identify issues:\n\nPR: {pr_result.content[0].text}\n\nFiles: {diff_result.content[0].text}"""
}]
)
# Post review comment
await session.call_tool(
"create_review",
{
"owner": repo.split("/")[0],
"repo": repo.split("/")[1],
"pullNumber": pr_number,
"body": review.content[0].text,
"event": "COMMENT"
}
)
return review.content[0].text
import os
asyncio.run(ci_code_review_agent(123, "myorg/myrepo"))
Production Engineering Notes
Startup Time Optimization
When multiple MCP servers are configured, Claude Desktop must start all of them on launch. Servers with slow startup (heavy Python imports, database connection establishment) delay the application becoming usable.
Optimize startup time:
- Use lazy imports where possible
- Establish database connections lazily (on first tool call, not at startup)
- For npm-based servers, use
--yesflag and consider pre-installing to avoid npm download on each launch
Server Health Monitoring
In production deployments with many MCP servers, monitor their health:
async def health_check_all_servers(server_configs: dict) -> dict[str, bool]:
"""Check if all configured MCP servers respond to ping."""
results = {}
for server_name, config in server_configs.items():
try:
server_params = StdioServerParameters(
command=config["command"],
args=config.get("args", []),
env=config.get("env", {})
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await asyncio.wait_for(session.initialize(), timeout=10.0)
results[server_name] = True
except Exception as e:
results[server_name] = False
return results
:::warning Version Pinning Is Mandatory for Production
Never use latest or unpinned versions for MCP servers in production. An automatic update from a community server could change tool behavior, introduce breaking changes, or - in the worst case - introduce malicious code. Pin exact versions in all production configurations and review changes before upgrading.
:::
:::tip Start with Official Servers For any tool that has an official Anthropic-maintained MCP server, start there. They are the most thoroughly reviewed, most actively maintained, and most reliably implemented. Use community servers when no official server exists for your tool. :::
Interview Q&A
Q1: How would you evaluate a community MCP server before using it in production?
Five questions in order. First: can I read the source code? If not, it cannot be used in production. Second: what is the worst thing this server could do if compromised? If it has write access to production systems, the answer is severe, and the risk must be explicitly accepted. Third: how does it handle credentials? Credentials should only come from environment variables, never hardcoded, never logged. Fourth: is it actively maintained? Check the last commit date, open issue response time, and whether security issues have been addressed. Fifth: can I pin an exact version? Any server used in production must be pinnable to a specific version so that updates are explicit and deliberate, not automatic. All five questions must have satisfactory answers before deploying.
Q2: Explain the N+M benefit of the MCP ecosystem in practice.
Before MCP, connecting 5 AI applications to 10 tools required 50 custom integrations - each application had to implement its own GitHub wrapper, its own Postgres wrapper, its own Slack wrapper. With MCP, each tool provider implements one server, and each AI application implements one client. Five applications and ten tools require 15 implementations, not 50. More importantly, maintenance, security fixes, and improvements to the GitHub MCP server benefit all five applications simultaneously - not just the one that happened to get updated. In practice, the ecosystem effect means that a team can deploy a comprehensive AI assistant with access to 10 tools in an afternoon, where previously it might have taken weeks of custom integration work.
Q3: What is the difference between building an MCP server for ecosystem use vs. internal use?
An ecosystem server must be highly configurable, use environment variables for all credentials, have comprehensive documentation, follow semantic versioning, work across different operating systems, and be maintained over time as the underlying tool's API changes. It needs to work for any user, not just your team. An internal server can be opinionated and specific: it can hardcode company-specific conventions, use internal authentication patterns, encode domain knowledge that is specific to your organization, and be deployed in your private infrastructure without public documentation. Internal servers are faster to build (less generalization needed) but do not contribute to the broader ecosystem. The right choice depends on whether the integration is genuinely general (ecosystem) or inherently team-specific (internal).
Q4: How do multi-server MCP configurations enable workflows that would not otherwise be possible?
Each MCP server gives the AI assistant access to one domain of tools. When multiple servers are connected simultaneously, the assistant can synthesize information across domains in a single conversation. For example: search Slack for context about a production incident (Slack server), look up related GitHub PRs (GitHub server), check the affected database schema (Postgres server), read the relevant runbook (filesystem server), and post a summary to the incident channel (Slack server again). Each of these actions requires a different server. Without MCP, each step would require the user to manually switch contexts, copy data between windows, and re-explain the situation to different tools. With multi-server MCP, the AI assistant handles the cross-context synthesis directly, making complex information retrieval workflows practical.
Q5: What are the key differences between using an IDE-integrated MCP setup vs. Claude Desktop?
Claude Desktop is a standalone application with a complete UI for conversations. MCP tools are available in the conversation interface, and the AI can use them during any conversation. It is ideal for general-purpose AI assistance and is the reference client for testing new MCP servers. IDE integrations (Cursor, Zed, VS Code) embed MCP tools within the development workflow - the AI assistant has access to MCP tools while you are writing code, and the workspace filesystem is automatically in scope. IDE integrations are better for coding tasks because they have workspace context (which files are open, what the user is working on), can see the code editor state, and are optimized for code generation and review workflows. For most development teams, both are valuable: IDE integration for coding tasks, Claude Desktop for general analysis and planning conversations.