DEV Community: Miles Wong

MCP Server Security: What Most Directories Don't Tell You

Miles Wong — Tue, 17 Mar 2026 10:44:12 +0000

When you install an MCP server, you're not just adding a feature to your AI assistant. You're handing a piece of software near-unrestricted access to your machine — your files, your credentials, your network connections, sometimes the ability to execute arbitrary code. Most people do this by copying a config snippet from a README without a second thought. That's a problem.

The MCP ecosystem is moving fast, and the infrastructure for evaluating security hasn't kept up. This article is for developers who want to actually understand what they're installing before they install it.

What MCP Servers Can Actually Do

The Model Context Protocol is powerful precisely because of how much access it grants. An MCP server can:

Read and write files anywhere your user has filesystem permissions
Make arbitrary network requests
Execute shell commands
Access environment variables (which is where API keys, database credentials, and tokens live)
Persist data locally and transmit it elsewhere

None of this is a bug. It's the feature. MCP servers need this access to be useful — a filesystem MCP server needs to read your files, a database MCP server needs your connection credentials. But "needs this access" and "can be trusted with this access" are two different questions, and most users conflate them.

The threat model isn't primarily "the developer is malicious" (though that does happen). It's more mundane: abandoned repositories with unpatched dependencies, credentials inadvertently logged, overly broad permission scopes that expose more than intended, and supply chain attacks through transitive dependencies.

What Can Go Wrong

Data exfiltration is the obvious one. An MCP server that has file system access and makes outbound HTTP calls can, technically, read your private files and send them somewhere. This doesn't require the original developer to be adversarial — a supply chain compromise in a dependency can introduce this after the fact, and if the repository isn't actively maintained, nobody's reviewing the packages.

Credential theft is more targeted. If an MCP server reads your environment variables (legitimately, to find an API key it needs), a compromised version of that server can harvest every other key in your environment at the same time. AWS keys, OpenAI API keys, GitHub tokens — all of it is there.

Abandoned servers are the risk most people ignore entirely. The MCP ecosystem has hundreds of community-built servers, many of which were written quickly, published, and then not touched again. An unmaintained server running on your machine means unpatched CVEs in its dependencies, no response if you report a vulnerability, and no guarantee that future versions of its dependencies don't introduce breaking security issues.

Supply chain attacks are the hardest to defend against. Your MCP server might be written by a developer you trust. But that server has dependencies, and those dependencies have dependencies. One compromised package three levels deep can give an attacker whatever access your server has.

What Most Directories Currently Offer

Not much. Smithery, Glama, and most other MCP directories aggregate community submissions. They're useful for discovering servers, but they list with no security auditing. There's no indication of whether a server has been reviewed for overly broad permissions, whether its dependencies have known CVEs, or when it was last updated. Some directories surface star counts and GitHub metadata, which is marginally useful, but a server with 1,200 stars can still be running a dependency with a published CVE from eight months ago.

This isn't a criticism of directory maintainers specifically — auditing every server in a fast-moving ecosystem is a significant undertaking. It's just the current reality, and developers should know it going in.

What a Proper Security Audit Looks Like

If you're evaluating an MCP server seriously, here's what that should actually cover:

Dependency scanning. Run the dependency tree through a tool like npm audit, pip-audit, or osv-scanner and look for known vulnerabilities. Pay attention to severity — a critical CVE in a package that handles network requests is more concerning than a low-severity issue in a dev dependency.

Authentication review. How does the server handle credentials? Does it require them to be passed as environment variables (acceptable), does it read from a config file (check what permissions that file has), or does it accept them inline in ways that might get logged (bad)?

Permission scope analysis. Does the server request access to everything, or does it scope its permissions to what it actually needs? A markdown-rendering MCP server probably doesn't need filesystem write access. If it asks for it anyway, that's a red flag.

Maintenance status check. When was the last commit? When were dependencies last updated? Are there open security issues that haven't been addressed? A repository with the last commit two years ago and ten open issues mentioning potential vulnerabilities is not the same as an actively maintained one.

Known CVE scanning. Check NVD and OSV for any CVEs that reference the package or its direct dependencies. This takes five minutes and can save you significant headaches.

The Three-Tier Rating Approach

One framework that makes sense is a three-tier classification: Verified, Caution, and Untested. Coda One's MCP security methodology uses an 8-point audit checklist to assign these ratings across the MCP servers it reviews.

The logic is straightforward: Verified means the server passed all checks — clean dependencies, appropriate permission scope, active maintenance, no known CVEs. Caution means it passed with caveats that don't necessarily disqualify it but warrant knowing about — maybe it's well-written but hasn't been updated in six months, or it requests slightly broader permissions than strictly necessary. Untested means it hasn't been reviewed yet.

"Untested" is the honest answer for most of the ecosystem. It's not a cop-out — it's accurate. The alternative is false confidence, and false confidence in this context is dangerous. If a directory tells you every server it lists is "safe" without explaining what that assessment is based on, that's a marketing claim, not a security guarantee.

What You Should Check Before Installing Anything

Star count tells you about popularity, not security. Here's what actually matters:

Look at open issues and PRs. Are there open security reports? Has the maintainer responded to them? An unacknowledged security issue report from three months ago is a meaningful signal.

Check the dependency list. For Node-based servers, look at package.json. For Python, look at requirements.txt or pyproject.toml. Run an audit against it. This takes two minutes and is the single highest-return action you can take.

Review what environment variables it reads. The README usually documents this. If it reads AWS_ACCESS_KEY_ID but you can't explain why a Notion integration needs AWS credentials, ask that question before installing.

Check the last commit date and release cadence. Not because old code is automatically bad, but because a server with dependencies it hasn't updated in 18 months almost certainly has known vulnerabilities by now.

Look at what permissions the server actually requests. The MCP spec gives servers the ability to declare their capabilities. If a server declares filesystem write access for functionality that doesn't obviously require it, that's worth understanding before proceeding.

The MCP ecosystem is one of the more interesting developments in how we use AI tooling. It's also, right now, a place where the security culture hasn't fully caught up to the adoption curve. That gap will close — but it probably won't close before you need to make decisions. Don't outsource those decisions to a star rating.

MCP Servers Explained: What They Are, Why They Matter, and Where to Find Them

Miles Wong — Tue, 17 Mar 2026 10:09:48 +0000

If you've been building with AI tools over the past year, you've probably run into the term "MCP" somewhere — a GitHub README, a Claude docs page, a developer forum thread. It's being talked about a lot, but the explanations tend to be either too abstract ("it's a protocol for AI-tool integration") or too deep in the weeds for anyone who just wants to understand what it actually does.

Here's a practical explanation, plus an honest look at the current state of the ecosystem.

What MCP Actually Is

MCP stands for Model Context Protocol. Anthropic open-sourced it in late 2024 as a standard way for AI models to connect to external tools, data sources, and services.

The simplest mental model: think of MCP as a USB standard for AI. Before USB, every device manufacturer used their own connector. After USB, a single standard meant any device could plug into any computer. MCP is trying to do the same thing for AI — create a single standard so any AI model can connect to any tool without each integration being custom-built.

Concretely, an MCP server is a small program that wraps an external capability and exposes it to an AI model in a standardized way. Want your AI assistant to query a database? There's an MCP server for that. Read files from your filesystem? MCP server. Hit a specific API, control a browser, run code, search the web, pull from a Google Sheet? All of these exist as MCP servers.

Before MCP, getting an AI model to do any of this required custom integration work specific to each model and each tool. The same integration built for Claude wouldn't work for GPT-4 without rewriting it. MCP changes that by creating a shared interface both sides can speak.

Why This Matters for AI Agents

The reason MCP is getting so much attention right now isn't the protocol itself — it's what the protocol enables.

AI agents — systems where the model takes a sequence of actions toward a goal rather than just answering a single question — are only as useful as the things they can actually do. An agent that can reason beautifully but can't touch any external system is just an expensive chatbot.

MCP is what gives agents real-world reach. An agent with the right MCP servers can read your calendar, pull relevant emails, search the web for current information, write to a spreadsheet, run a code snippet, and post a result — all as part of executing a single instruction you gave it. Without MCP (or something like it), every one of those steps requires a separate custom integration.

The other thing MCP does well is make agent capabilities composable. You can mix and match servers. An agent that needs to search the web and write to a database doesn't need a custom "web-search-plus-database" integration. It just uses two separate MCP servers together. That's a fundamentally better architecture for building complex AI workflows.

The Current State of the Ecosystem

The real picture is less exciting than the hype version.

The MCP ecosystem has exploded in size. There are thousands of MCP servers available now — for every major SaaS product, database, API, and developer tool you can think of. The velocity has been impressive. The quality, less so.

Most MCP servers are built by individual developers and posted to GitHub. The code works until it doesn't. Maintenance is inconsistent. A server that worked perfectly six months ago might be broken today because the underlying API changed and the maintainer didn't update it. There's no central registry with any kind of quality control.

More seriously: security. An MCP server has access to whatever capabilities it wraps, and it runs locally on your machine or your server. A malicious or poorly written MCP server could theoretically expose sensitive data, make unauthorized requests, or act as a vector for supply chain attacks. Most servers aren't audited. Most people installing them aren't reading the source code.

This isn't a theoretical risk. It's the kind of thing that will cause real incidents as MCP adoption scales, and it's not being talked about enough relative to the enthusiasm for the protocol itself.

Where to Find MCP Servers (and What to Watch For)

There are three places worth knowing about.

Anthropic's official MCP repository is the starting point. It's on GitHub and contains both official servers maintained by Anthropic and a curated list of community servers. The curation is light — presence on the list doesn't imply a security review — but it's at minimum a filter for relevance. Start here if you want to understand what's possible before going broader.

Smithery (smithery.ai) is the most developer-focused MCP discovery platform right now. It has a clean interface, good search, and lets you see install counts and community feedback. If you're a developer looking for a specific integration, Smithery's search is probably the fastest way to find it. The quality filtering is community-driven rather than editorial, so do your own diligence before deploying anything in a production context.

Coda One's MCP directory takes a different approach — 2,807 servers cataloged with security context included. Rather than just listing what's available, it flags known security concerns and surfaces relevant context about each server's maintenance status and risk profile. If the security angle matters to you — and it should — that additional layer is worth the extra click. It's not a replacement for your own due diligence, but it's a better starting point than a raw GitHub list.

Practical Advice for Getting Started

If you're new to MCP and want to start using it, Claude Desktop is the lowest-friction entry point. Anthropic has built MCP support directly into the desktop app, which means you can install a server and have it available to Claude without writing any integration code. The setup docs are reasonably good, and the filesystem and web search servers are solid beginner options.

A few things worth keeping in mind before you install your first server:

Read the source code, or at minimum check who maintains it and when it was last updated. An unmaintained server from 2024 that claims to connect to an API that's changed twice since then is a liability, not a feature.

Be cautious with servers that request broad permissions — filesystem access, network access, credential handling — without a clear reason why they need it. Principle of least privilege applies here as much as anywhere.

Test in a sandboxed environment first. Don't give a new MCP server access to your production database on day one.

The protocol itself is solid. The ecosystem around it is maturing fast but hasn't matured yet. The developers who thrive with MCP in the next 12 months will be the ones who treat server selection like dependency management — deliberate, not opportunistic.

MCP is one of the more important infrastructure developments in the AI agent space. It's not glamorous in the way that a new model release is glamorous, but plumbing rarely is. Get familiar with it now. The teams building on top of it have a meaningful head start.