Official and Community MCP Server Registries in 2025
The MCP ecosystem grew rapidly from a handful of reference implementations in late 2024 to a sprawling collection of hundreds of community servers by mid-2025. Navigating this ecosystem efficiently — knowing where to find servers, which registries are authoritative, and how to separate production-grade implementations from experimental prototypes — is a practical skill for any developer building MCP-powered workflows.
Official Anthropic reference implementations: Anthropic maintains a curated set of first-party MCP servers at github.com/modelcontextprotocol/servers. These serve as the specification reference for how a well-built MCP server should behave. As of 2026, the official repository includes servers for: filesystem access, Git, GitHub, GitLab, Slack, Google Drive, PostgreSQL, SQLite, Puppeteer, Fetch (HTTP client), Memory (persistent key-value), and several others. These implementations are the most reliable baseline for understanding expected behavior and are the best starting point for building custom servers (fork and adapt rather than starting from scratch).
The MCP Registry at mcp.run: Launched in early 2025, mcp.run is the primary community registry for discovering MCP servers. It indexes servers with metadata including transport type, authentication method, capability set, language/runtime, license, and usage statistics. The registry supports search by integration type (e.g., "jira", "kubernetes", "prometheus") and by capability (e.g., servers that implement Resources with subscribe support). As of mid-2026, it indexes over 800 community servers.
npm install -g @mcp/cli
mcp registry search jira
mcp registry info jira-mcp
GitHub Topics as a discovery mechanism: Many MCP server authors tag their repositories with the mcp-server GitHub topic. Searching topic:mcp-server on GitHub surfaces servers that are not in the mcp.run registry. This is particularly useful for niche integrations (internal tooling categories, enterprise-specific APIs) that the registry has not indexed. Sort by recently updated to find actively maintained options.
Host-bundled server directories: Claude Code ships with a curated list of verified MCP servers accessible via claude mcp search <query>. This list is a subset of the broader ecosystem — servers that Anthropic has reviewed for basic safety and specification compliance. Cursor maintains a similar list in its MCP marketplace. These curated lists are the right starting point for non-technical teams or when you need confidence in basic quality before investing evaluation time.
Vendor-maintained registries: As MCP adoption grew, major developer tool vendors began maintaining their own MCP server distribution. Atlassian distributes official Jira and Confluence MCP servers. JetBrains maintains an MCP server for their IDE toolbox. DataDog, Sentry, and PagerDuty have official or semi-official MCP servers. For enterprise tools, always check the vendor's documentation before using a community alternative — vendor-maintained servers typically have better support, more complete feature coverage, and alignment with official API versions.
Tips
- Create a team-level curated list of approved MCP servers in your internal docs. This prevents each developer from independently discovering and configuring different implementations of the same integration, which leads to inconsistent behavior across the team.
- When checking the mcp.run registry, filter by "last updated within 6 months." MCP servers that have not been updated recently may be broken against current API versions of the services they wrap, or may implement outdated MCP spec features.
- Before adopting any community MCP server, check the GitHub Issues list for open bugs related to authentication, error handling, or data accuracy. High-severity open issues with no maintainer response are a strong signal to look for alternatives.
- Subscribe to Anthropic's MCP changelog and themodelcontextprotocol/serversrepository releases. When the official reference implementations update, community servers often lag — knowing what changed lets you assess whether a community server is affected.
How to Evaluate an MCP Server: Quality, Security, and Maintenance
Installing and running an MCP server in your development workflow grants it significant access: to your credentials (passed as environment variables), to your local filesystem (if it implements filesystem tools), and to any external APIs it wraps. Evaluation must be systematic, not cursory.
Specification compliance check: Before trusting any behavioral claims, verify that the server correctly implements the MCP initialization sequence and returns well-formed tool schemas. You can do this manually with a simple test script:
import subprocess
import json
import sys
def test_mcp_server(command: list[str], env: dict = None):
proc = subprocess.Popen(
command,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
env=env
)
# Send initialize
init_msg = json.dumps({
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-03-26",
"capabilities": {},
"clientInfo": {"name": "eval-tool", "version": "0.1.0"}
}
}) + "\n"
proc.stdin.write(init_msg.encode())
proc.stdin.flush()
response_line = proc.stdout.readline()
response = json.loads(response_line)
assert "result" in response, f"Initialize failed: {response}"
assert "protocolVersion" in response["result"], "Missing protocolVersion"
assert "capabilities" in response["result"], "Missing capabilities"
print(f"Protocol version: {response['result']['protocolVersion']}")
print(f"Server: {response['result'].get('serverInfo', {})}")
print(f"Capabilities: {list(response['result']['capabilities'].keys())}")
# Send initialized notification
proc.stdin.write((json.dumps({"jsonrpc": "2.0", "method": "notifications/initialized"}) + "\n").encode())
proc.stdin.flush()
# Request tools list
proc.stdin.write((json.dumps({"jsonrpc": "2.0", "id": 2, "method": "tools/list"}) + "\n").encode())
proc.stdin.flush()
tools_line = proc.stdout.readline()
tools = json.loads(tools_line)
assert "result" in tools, f"tools/list failed: {tools}"
tool_list = tools["result"].get("tools", [])
print(f"\nTools exposed ({len(tool_list)}):")
for tool in tool_list:
schema_ok = "inputSchema" in tool and tool["inputSchema"].get("type") == "object"
print(f" - {tool['name']}: {'OK' if schema_ok else 'MISSING inputSchema'}")
proc.terminate()
test_mcp_server(["node", "./github-mcp-server/index.js"])
Security evaluation checklist:
MCP Server Security Checklist
Source code review:
[ ] Credentials are read from environment variables, not hardcoded
[ ] No credential values appear in log output (redact secrets from logs)
[ ] Input validation is present before passing arguments to external APIs
[ ] No filesystem access beyond the explicitly stated scope
[ ] No outbound HTTP calls to endpoints other than the documented target API
[ ] Dependencies are pinned to specific versions (no "^" or "~" in production)
[ ] Dependencies have been audited (npm audit / pip-audit / cargo audit passes)
Operational behavior:
[ ] Server handles malformed input gracefully (no unhandled exceptions on bad JSON)
[ ] Server returns isError:true for execution failures, not protocol errors
[ ] Server does not leak internal error details (stack traces, API responses) to the client
[ ] Tool descriptions are accurate — they describe what the tool does, not what you want it to do
[ ] Tool input schemas enforce required fields and reject unexpected properties
Maintenance health signals: An MCP server that was active in 2024 and has not been updated since is likely to have breaking issues by 2026. Evaluate:
- Last commit date: less than 6 months preferred, less than 3 months ideal for actively used integrations
- Open issues with "bug" label: review the 10 most recent; check if they are acknowledged and have timelines
- CI status badge: if present, is it passing? Failing CI means the server is in a broken state the maintainer has not addressed
- Release cadence: regular releases indicate active maintenance; a single "v1.0.0" with no subsequent releases suggests the project was shipped and forgotten
- Dependency freshness: check if the server's
@modelcontextprotocol/sdkdependency is on the current major version
Functional accuracy testing: For MCP servers that wrap external APIs, run targeted functional tests before putting them in production workflows. Do not assume that a server returning a 200 from its tools/call endpoint means it is returning correct data.
Prompt example for functional validation:
"Using the jira MCP server, get the details for ticket PLAT-100.
Compare the returned summary, status, and assignee against what you see
in the Jira UI. Report any discrepancies."
Tips
- Runnpm auditor the equivalent for the MCP server's language before installing it. Community MCP servers frequently have outdated dependencies with known vulnerabilities — especially older servers that predate regular maintenance.
- For MCP servers that require broad API permissions (e.g., full GitHub repo read/write), create a dedicated service account with scoped credentials for MCP use rather than using your personal token. This contains the blast radius if the server or its credentials are compromised.
- Isolate unfamiliar community MCP servers in a separate sandbox environment for initial evaluation. Run them against a non-production copy of the target service until you are confident in their correctness.
- Check the server's data handling for any resources that return PII or sensitive business data. Some community MCP servers log full API responses to files or remote services for debugging purposes — this is a data handling risk in enterprise environments.
Most Popular MCP Servers for Developer Workflows
The following MCP servers represent the highest-utility, most mature integrations for professional software development workflows as of mid-2026. These are not ranked by star count but by practical impact for the workflows described in this course.
GitHub MCP Server (github.com/modelcontextprotocol/servers/github): The reference implementation for source control integration. Supports issue creation and management, PR creation and review comments, file content retrieval, commit history, repository search, and code search. Essential for any workflow that bridges AI reasoning with version control.
GitLab MCP Server (github.com/zereight/gitlab-mcp): Community-maintained but actively developed. Covers merge requests, issues, CI/CD pipeline status, and project management. The Atlassian and GitLab official teams have signaled intent to release first-party servers — check for updates.
Jira MCP Server (github.com/modelcontextprotocol/servers/atlassian or vendor): Exposes issue CRUD, sprint management, JQL search, and board operations. The vendor-maintained version (available via Atlassian developer portal) is preferred for enterprise deployments due to better handling of custom fields and Jira Data Center compatibility.
Sentry MCP Server (github.com/getsentry/sentry-mcp): Official Sentry MCP server. Supports issue listing with filters, event detail and stack trace retrieval, trace lookup, and release information. The official server handles Sentry's pagination model correctly, which community alternatives often do not.
Filesystem MCP Server (github.com/modelcontextprotocol/servers/filesystem): The reference filesystem server. Provides read/write access to files and directories within a configured root path. Critically, it enforces path traversal restrictions — the server rejects requests that attempt to access files outside the allowed root. Review these restrictions carefully before configuring the allowed root to be too broad.
Playwright MCP Server (github.com/microsoft/playwright-mcp): Microsoft's official Playwright MCP implementation. Enables browser navigation, element interaction, screenshot capture, and DOM inspection. This is the correct choice for UI testing automation — prefer it over Puppeteer MCP for new projects due to better multi-browser support and official maintenance.
PostgreSQL MCP Server (github.com/modelcontextprotocol/servers/postgres): Read-only database access. Exposes schema inspection, table listing, and SQL query execution. The read-only constraint is intentional and correct — do not use or build write-capable database MCP servers for production use without extremely careful scope controls.
Fetch MCP Server (github.com/modelcontextprotocol/servers/fetch): An HTTP client tool that allows the agent to fetch arbitrary URLs and return their content. Useful for reading API documentation, checking service health endpoints, or retrieving data from services without a dedicated MCP server. Security note: this server can make outbound HTTP requests to any URL — configure allowed URL patterns in production deployments.
claude mcp add github -- env GITHUB_TOKEN=$GITHUB_TOKEN npx -y @modelcontextprotocol/server-github
claude mcp add sentry -- env SENTRY_TOKEN=$SENTRY_TOKEN npx -y @sentry/mcp-server
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /home/user/projects
claude mcp add playwright -- npx -y @playwright/mcp
claude mcp add postgres -- env DATABASE_URL=$DATABASE_URL npx -y @modelcontextprotocol/server-postgres
claude mcp list
claude mcp test github
Tips
- Pin MCP server versions in your team's configuration files rather than usingnpx -ywith latest.@modelcontextprotocol/[email protected]is reproducible.@modelcontextprotocol/server-github@latestis not — a breaking change in a server update can silently break agent workflows.
- Maintain a shared team MCP configuration file in your team's dotfiles or developer setup repo. New team members should be able to run one setup script to get all team-standard MCP servers configured correctly.
- For the Filesystem MCP server, configure the allowed root to the specific project directory, not/home/useror/. Principle of least privilege applies — the agent only needs access to the project it is working on.
- Regularly audit which MCP servers are configured in your environment. Remove servers you are not actively using. Each connected MCP server expands the tool surface available to the agent, which increases the risk of accidental or adversarially-induced misuse.
How to Contribute Your Own MCP Server to the Community
Building and publishing an MCP server for a tool that lacks coverage is one of the highest-leverage contributions to the ecosystem. The barrier to entry is low for developers familiar with REST APIs — the MCP SDK handles protocol complexity, and most of the work is mapping an existing API's capabilities to MCP tool definitions.
Development setup: The official SDKs are the fastest path to a compliant server. The TypeScript SDK (@modelcontextprotocol/sdk) is the most mature and most commonly used, but Python, Go, Rust, Java, and C# SDKs are available.
// Minimal TypeScript MCP server skeleton
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "my-integration-mcp",
version: "1.0.0"
});
// Define a tool with full input validation
server.tool(
"get_item",
"Retrieve an item from the integration by ID",
{
item_id: z.string().describe("The unique identifier of the item to retrieve"),
include_metadata: z.boolean().optional().default(false).describe("Include extended metadata in the response")
},
async ({ item_id, include_metadata }) => {
try {
const result = await myApiClient.getItem(item_id, { includeMetadata: include_metadata });
return {
content: [{
type: "text",
text: JSON.stringify(result, null, 2)
}]
};
} catch (err) {
return {
content: [{
type: "text",
text: `Error retrieving item ${item_id}: ${err.message}`
}],
isError: true
};
}
}
);
// Start with stdio transport
const transport = new StdioServerTransport();
await server.connect(transport);
Quality standards for community contributions: Before publishing, your server should meet these standards to be useful to others and to get accepted into curated registries:
- All tools have accurate
descriptionfields that specify when to use the tool, not just what it does - All tool input parameters have
descriptionfields with format expectations and examples - Input validation rejects malformed arguments before calling the external API
- All errors return
isError: truewith actionable messages, never unhandled exceptions - The server passes a manual compliance test (initialize → tools/list → call a real tool)
- A
README.mdincludes: prerequisites, installation instructions, authentication setup, and example tool calls - Environment variables are documented with example values (never real credentials)
Publishing and registration:
1. Initialize the npm package
npm init --scope=@your-org
# Set name: @your-org/my-integration-mcp or my-integration-mcp
2. Add the MCP badge and topics to your GitHub repository
# In GitHub Settings → Topics, add: mcp-server, mcp, model-context-protocol
3. Publish to npm
npm publish --access public
4. Register with mcp.run
# Create an account at mcp.run
# Submit: npm package name, GitHub URL, description, capability flags
# The registry will crawl your server and extract tool definitions
5. Submit a PR to modelcontextprotocol/servers (optional)
# For high-quality integrations, Anthropic occasionally adds community servers
# to the official repository. This requires a more rigorous review process.
6. Announce in the MCP Discord (#server-releases channel)
# The active MCP developer community is the fastest way to get early
# feedback and surface bugs in edge cases you did not consider
Versioning and maintenance commitments: Before publishing a community MCP server, commit to a maintenance posture. Community servers that are abandoned create frustration when they break against updated APIs. If you cannot commit to regular maintenance, document this clearly in the README and consider publishing under a "community/experimental" designation.
Semantic versioning is strongly recommended, with special attention to how version numbers signal protocol changes. A server that changes a tool's name or removes a tool should increment its major version number, because existing user configurations will break. Adding new tools or new optional parameters is a minor version change. Bug fixes are patches.
// package.json versioning with protocol compatibility note
{
"name": "my-integration-mcp",
"version": "2.1.0",
"description": "MCP server for My Integration API",
"keywords": ["mcp", "mcp-server", "model-context-protocol"],
"engines": {
"node": ">=18.0.0"
},
"mcpMetadata": {
"specVersion": "2025-03-26",
"transport": ["stdio", "http"],
"capabilities": ["tools", "resources"]
}
}
Writing useful tool descriptions for AI discoverability: This is the most commonly neglected aspect of community MCP servers, and the most impactful for practical usability. A model's ability to choose the right tool in the right situation depends almost entirely on the quality of tool descriptions.
"description": "Gets data from the API"
"description": "Retrieve a paginated list of deployment events for a specific service
and environment. Use this when the user asks about recent deployments, deployment
history, or whether a specific version has been deployed to a given environment.
Returns up to 50 events per page with timestamps, deployer identity, and rollback status."
Tips
- Write your tool descriptions by asking: "What would a developer search for in documentation that would lead them to use this tool?" Use those search terms and phrases in the description. Models search tool descriptions similarly to how humans search documentation.
- Add a CHANGELOG.md to your MCP server repository and keep it updated with each release. Users who depend on your server need to know what changed when they upgrade — especially any tool renames or schema changes that require configuration updates.
- Implement a--versionCLI flag in your MCP server. When developers are debugging integration issues, knowing the exact server version running is the first troubleshooting step. Make it easy.
- Consider adding adiagnoseorpingtool to your MCP server that verifies connectivity to the underlying service and returns the current authentication status. This provides instant feedback when a user's credentials expire or the target service is unreachable, without requiring a real tool call to discover the problem.