Community MCP servers: which ones are worth it

Tested with MCP Inspector 2.7.0 · server-filesystem 2026.8.31 · mcp-server-git 2026.8.18 · DBHub 1.2.5 · PostgreSQL 18.6 · verified 2026-09-16

Updated: 2026-09-16

I wrote this guide in June 2025 and reviewed it on 16 September 2026, when the official Model Context Protocol (MCP) registry returned 32,514 servers. The problem is no longer finding an MCP server for a specific task, it’s deciding which of the ones on the first page of results deserves trust. This post gathers the servers I use daily in my Claude Desktop and Claude Code workflow, the ones I installed and then removed, and the criteria I apply to separate wheat from chaff. For this review I started the five I recommend again, with pinned versions.

Key takeaways

• Four of the five servers I use daily are still reference servers of the MCP project: filesystem, git, fetch, and memory.

• The reference Postgres server is archived and its read-only mode could be bypassed with a COMMIT. I replaced it with DBHub and a read-only role.

• The official MCP registry verifies who publishes, not what gets published.

• Slack, email, and broadly-scoped SaaS API servers present attack surfaces too large for the real benefit they bring.

• The tool-chain risk (a malicious server using a legitimate one to leak data) remains unresolved in the MCP clients I use.

• Five criteria before installing any new server: provenance, scope, traceability, revocability, and update model. And don’t mix trusted servers with community servers you don’t know well in the same session.

What has changed since November 2024

When Anthropic announced MCP on 25 November 2024^[1], it shipped pre-built servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Of those six, only Git is still in the reference repository^[2], which keeps seven servers maintained by the MCP steering group and has archived thirteen. Its README warns that they are implementations for learning the protocol, not production-ready solutions.

Adoption is no longer in question. On 9 December 2025, Anthropic donated MCP to the Agentic AI Foundation^[3], a directed fund under the Linux Foundation. At that point the project reported over 97 million monthly downloads of its software development kits (SDKs) and 10,000 active servers.

The part that hasn’t aged well is catalog governance. Servers still live in individual repositories, are installed with commands that pull third-party packages from npm, PyPI, or Docker Hub, and the main guarantee is still the maintainer’s reputation. That model works for mature projects and doesn’t work for three-day-old novelties.

What does the official MCP registry guarantee?

The official registry guarantees where a server name comes from, not the server’s quality or security. It launched in preview on 8 September 2025^[4] at registry.modelcontextprotocol.io, and its documentation still describes it that way. It stores metadata that points to packages on npm, PyPI, or Docker Hub. Publishing as io.github.username/server requires logging in with that GitHub account, and a reverse-domain name requires proving control of the domain.

What it lacks is content review. Its moderation policy^[5] tells consumers to assume minimal-to-no moderation and explicitly won’t remove servers with security vulnerabilities. On 16 September 2026 its API returned 32,514 servers, three GitHub accounts accounted for 14% of them, and I found none of the seven reference servers. Being in the registry vouches for nothing; use it as a starting point for the criteria below.

The five I use every day

Four of the five are still reference servers and the fifth now comes from a different project. The table lists the version I tested, when it was published, and whether it accepted the 2026-07-28 protocol revision in my tests:

• Filesystem MCP server: lets you give the agent bounded access to specific local directories. I use it so Claude reads and writes files in a specific project without roaming the rest of the system. Two flaws published in July 2025 allowed escaping those directories (CVE-2025-53109 and CVE-2025-53110): use 2025.7.1 or later. Pass the directories as arguments: the README still recommends Roots, but the MCP 2026-07-28 specification deprecates that feature.

• Git MCP server: lets the agent read repository state, see diffs, and consult history when it needs them, instead of you pasting terminal output into the conversation. It received four security advisories between December 2025 and February 2026, and 2025.9.25 removed the git_init tool. Always start it with --repository, which since 2025.12.18 rejects paths outside that repository, and use 2026.1.14 or later.

• DBHub instead of the Postgres MCP server: connects Claude with a development database for schema exploration. I run it in read-only mode and wouldn’t connect it to a production database.

• Fetch MCP server: downloads web pages and returns them as Markdown, truncated to 5,000 characters by default. Its README^[6] says it obeys robots.txt when the model makes the request and warns that it can reach internal IP addresses, so I don’t leave it enabled next to unauthenticated internal services.

• Memory MCP server: stores a knowledge graph in a local JSON Lines file that the agent reads and updates across chats^[7]. It’s the only server where I’m careful with privacy: what gets saved persists from one chat to the next and can leak through unexpected sources when mixed with other servers. This server is also the persistence layer that feeds knowledge graphs for LLMs.

The Postgres swap has a concrete cause. Datadog Security Labs showed on 21 August 2025^[8] that the reference server’s read-only mode could be bypassed by sending COMMIT; before the write statement. The package has been deprecated since 10 July 2025 and still recorded 78,432 downloads^[9] between 5 and 11 September 2026. I reproduced it with 0.6.2 against a test database and the table was gone.

DBHub^[10], from Bytebase, is the server in the PostgreSQL example of the Claude Code documentation^[11]. With readonly = true it filters statements by keyword and runs them inside a read-only transaction, but its documentation^[12] still asks for a database user without write permissions.

How do I check an MCP server before connecting it?

Before handing a server to an agent, I list its tools with the command-line interface (CLI) of the MCP Inspector^[13] and read the descriptions the model will treat as instructions. I did it on 16 September 2026 with Inspector 2.7.0 in a linux/arm64 container with Node.js 24.21.0 and uv 0.12.15. In version 2, whatever comes before -- is the server and whatever comes after is the Inspector’s own options.

I="npx -y @modelcontextprotocol/inspector@2.7.0 --cli"
FS="npx -y @modelcontextprotocol/server-filesystem@2026.8.31 /work/demo"
T='.result.content[0].text'
$I $FS -- --method tools/list --format json \
  | jq -r '.result.tools[] | "\(.name) ro=\(.annotations.readOnlyHint)"'
$I $FS -- --method tools/call --tool-name read_text_file \
  --tool-arg path=/etc/passwd --format json | jq -r "$T"

The output marks with ro=true the tools the server annotates as read-only, and the read outside the allowed directory fails:

read_file ro=true
read_text_file ro=true
read_media_file ro=true
read_multiple_files ro=true
write_file ro=false
edit_file ro=false
create_directory ro=false
list_directory ro=true
list_directory_with_sizes ro=true
directory_tree ro=true
move_file ro=false
search_files ro=true
get_file_info ro=true
list_allowed_directories ro=true
Access denied - path outside allowed directories: /etc/passwd not in /work/demo

Annotations only inform the client; they don’t block any write. With the folder mounted read-only, write_file failed with EROFS: read-only file system. The git server, started with --repository /work/demo, rejected both escape attempts I made. Asking for the status of /work/other returned is outside the allowed repository '/work/demo', and a target starting with a dash was rejected without creating any file.

For DBHub I set up a two-row customers table on PostgreSQL 18.6 and an empty_customers() function, created by the table owner, that deletes the table’s rows from inside a SELECT. The role DBHub uses can only read:

CREATE ROLE reader LOGIN PASSWORD 'reader_password';
GRANT CONNECT ON DATABASE shop TO reader;
GRANT USAGE ON SCHEMA public TO reader;
GRANT SELECT ON customers TO reader;
-- as the table owner:
CREATE FUNCTION empty_customers() RETURNS bigint LANGUAGE sql AS
$$ WITH d AS (DELETE FROM customers RETURNING 1) SELECT count(*) FROM d $$;

The configuration turns on read-only mode and takes the password from the environment:

[[sources]]
id = "shop"
dsn = "postgres://reader:${DB_PASSWORD}@db:5432/shop?sslmode=disable"

[[tools]]
name = "execute_sql"
source = "shop"
readonly = true
max_rows = 100

[[tools]]
name = "search_objects"
source = "shop"

With DB_PASSWORD exported and the variables from the previous block, these calls test the Datadog injection, the trap function, and the final state:

DB="npx -y @bytebase/dbhub@1.2.5 --config /work/dbhub.toml"
sql() {
  $I $DB -- -e DB_PASSWORD="$DB_PASSWORD" --method tools/call \
    --tool-name execute_sql --tool-args-json "{\"sql\": \"$1\"}" \
    --format json | jq -r "$T" | jq -c '.code // .data.statements[0].rows'
}
sql "COMMIT; DROP TABLE customers"
sql "SELECT empty_customers()"
sql "SELECT count(*) AS n FROM customers"

"READONLY_VIOLATION"
"EXECUTION_ERROR"
[{"n":"2"}]

The first rejection comes from the keyword filter (Read-only mode is enabled) and the second from PostgreSQL (cannot execute SELECT in a read-only transaction). The table keeps its two rows. That transaction doesn’t stop functions such as pg_read_file for privileged roles, so the role matters as much as the option.

With automatic negotiation, all five servers agreed on the 2025-11-25 protocol revision. When I pinned 2026-07-28 with --protocol-era modern, the four reference servers failed with did not offer pinned protocol version and only DBHub accepted it. The git and fetch READMEs explain that they still require version 1 of the Python SDK and that the port to version 2 is in progress.

I didn’t test Slack’s official server, which needs a workspace and a registered app, and for fetch and memory I only listed the tools. Everything came from the Inspector, not from Claude Desktop or Claude Code. The shared machine had a load average of 22 on 18 cores, so I don’t publish timings.

What I tried and ended up removing

I tried the community Slack MCP server and removed it within days. The functionality was correct but the permission model was poorly designed: once connected, the agent could read any channel the user had access to, including private ones with sensitive information. The indirect prompt injection exfiltration risk was too high for the real benefit.

That reference server is archived, and the Zencoder fork its README points to hasn’t received a commit since 16 July 2025. Slack now runs its own remote MCP server^[14], over Streamable HTTP only, and requires every client to be a registered app that workspace admins can approve. That control targets the permission problem that made me remove it.

Every email server I tried ended up retired. The pattern is similar: the attack surface of a server that reads and acts on email is enormous, and community servers didn’t have security reviews justifying the risk.

The other group I removed is servers for broadly-scoped SaaS APIs. A server that gives the agent full access to the Stripe or AWS API sounds useful until you review the code. Credentials are passed as environment variables without rotation, without fine-grained permission control, and without audit logging.

The alternative that has gained ground is the vendor’s own server. The reference README points Brave Search users to Brave’s server, and GitHub maintains github-mcp-server^[15], with 1.12.2 released on 16 September 2026. Those servers settle provenance; the scope you grant them is still your decision.

Criteria for deciding what to install

Over time I’ve ended up applying five criteria before installing any new MCP server:

• Provenance. Reference servers from the MCP project, servers published by the service’s own vendor, or repositories with an identifiable maintainer and sustained activity. A verified name in the official registry confirms the account or domain that publishes, and nothing else. Anonymous repositories with little activity are rejected outright.

• Scope. What the server does and over what. A server that reads a specific local directory is different from one with arbitrary network permission. Applying least privilege here saves future headaches.

• Traceability. What the server logs when it acts. A well-built MCP server logs each tool invoked with arguments, which lets you audit behaviour later if something goes wrong.

• Revocability. How it’s removed if you decide you don’t want it. Verifying that uninstallation is clean is part of the evaluation.

• Update model. How you learn about a security update. Follow repositories with regular releases and published security advisories^[16], like the six filesystem and git have accumulated, and distrust those that don’t publish them. Pin the version in the client configuration instead of running npx without one.

The risk no one is looking at

There’s a cross-cutting risk I haven’t seen discussed enough in the community. When an MCP client has more than one server active in the same conversation, servers implicitly share context through the agent. A malicious server can insert instructions in its responses that direct the agent to invoke another legitimate server with arguments that leak information.

The OWASP MCP Top 10 classifies this variant as “tool poisoning”^[17], so the risk is identified. Its entry lists indicators you can review before installing: model-directed instructions, credential paths, or invisible characters in tool descriptions. The Inspector listing from the previous section is the tool for that.

This tool-chain attack is hard to detect because each individual server behaves correctly. What fails is the composition. Mitigating it requires isolating contexts across untrusted servers, something the MCP clients I use don’t do by default.

My recommendation while this isn’t resolved: don’t mix trusted servers with community servers you don’t know well in the same session.

My read

MCP has won the adoption bet. It has achieved something similar to what OAuth achieved: establishing itself as the default mechanism for integrating agents with external services. Since December 2025 it also belongs to a foundation rather than to a single company.

The unresolved problem is the community catalog’s trust model. Npm learned the hard way that an unreviewed registry is a supply-chain attack vector, and MCP is walking the same accelerated path. The formal registry now exists and checks who publishes, but by its own policy it leaves security review out.

My practical recommendation to any team adopting MCP: start with the reference servers and with servers published by the service’s own vendor, with pinned versions. Add community servers one at a time, with manual code review, and remove them if in a month they don’t provide measurable value. The catalog is broad and tempting, but the attack surface grows with each install.

Frequently asked questions

Is it safe to connect the Postgres MCP server to my production database?

Not advisable. The reference Postgres server has been archived since July 2025, and its read-only mode could be bypassed by sending a COMMIT before the write statement. If an agent needs to query Postgres, use DBHub with readonly = true and a role that only has SELECT permission, and point it at development, not production. The same least-privilege logic applies to the filesystem server: give the agent bounded access to specific project directories rather than letting it roam the rest of the system.

Can I mix official and community MCP servers in the same session?

Better not, unless you know the community server well. When more than one server is active in the same conversation they implicitly share context through the agent. A malicious server can insert instructions in its responses that direct the agent to invoke another legitimate server with arguments that leak information. Each individual server behaves correctly; what fails is the composition, and the MCP clients I use do not isolate contexts by default.

What should I check before installing a community MCP server?

Five criteria, starting with provenance: a reference server, the vendor’s own server, a recognised organisation or an identifiable maintainer with sustained activity; anonymous repositories are rejected outright. Scope: reading one local directory is not the same as arbitrary network permission. Traceability (it logs each tool invoked with its arguments), revocability (uninstallation is clean) and update model (regular releases and published security advisories). Before connecting it, list its tools with the MCP Inspector and read their descriptions; then add servers one at a time and remove any that provide no measurable value within a month.

Does being in the official MCP registry mean a server is safe?

No: the official registry checks that the publisher controls the GitHub account or domain in the server name, and nothing else. Its moderation policy tells consumers to assume minimal-to-no moderation and won’t remove servers for having vulnerabilities. It only stores metadata that points to npm, PyPI, or Docker Hub, and on 16 September 2026 it listed 32,514 servers with none of the seven reference servers among them. Apply the same provenance, scope, and update criteria to everything you find there.

Sources

1. Anthropic announced MCP on 25 November 2024
2. reference repository
3. Anthropic donated MCP to the Agentic AI Foundation
4. It launched in preview on 8 September 2025
5. moderation policy
6. Its README
7. across chats
8. Datadog Security Labs showed on 21 August 2025
9. 78,432 downloads
10. DBHub
11. Claude Code documentation
12. its documentation
13. MCP Inspector
14. Slack now runs its own remote MCP server
15. github-mcp-server
16. published security advisories
17. OWASP MCP Top 10 classifies this variant as “tool poisoning”