How DReview Verifies MCP Listings

Anyone can publish an MCP server to GitHub or npm today, and nothing about that process checks whether it does what it claims, whether the license is real, or whether the person publishing it is who they say they are. That's not a flaw in GitHub or npm — it's just not what they're for. It's the gap a directory like DReview exists to close, and it's worth being specific about what that actually means in practice, rather than leaving "verified" as a vague badge nobody can inspect.

Why a submission form isn't enough

A submission form can require a field to be filled in. It can't tell you whether the GitHub URL in that field points to a real, maintained project or an abandoned fork with a README that was never updated. It can't tell you whether the license field says "MIT" because the repo actually has an MIT license, or because the submitter typed the first thing that came to mind. Validating the *shape* of a submission (a name, a category, a link) is a data-entry problem. Validating whether the submission is *true* is a different problem entirely, and it's the one that actually matters to someone deciding whether to connect a tool to their AI agent.

That's why every tool submitted to DReview goes through a real review by a person before it's visible to anyone else, rather than going live the moment the form is submitted.

What happens after you hit submit

Submitting a tool doesn't publish it. It creates the listing in a pending state and puts it in front of an admin — nothing about it is public yet. A submitter can also save a listing as a draft first, without submitting it for review at all, which is useful for filling in details over more than one sitting before it's ready to be looked at.

Once a listing is submitted, it sits in the review queue exactly as filled in: name, one-line description, longer description, category, transport type (local or remote), language, license, GitHub URL, optional npm package, optional demo video, use cases, FAQs, and the actual per-client install configs. Nothing in that list is edited or reformatted before an admin sees it — the review happens against exactly what was submitted, not a cleaned-up version of it.

What we actually check before approving

Four things, specifically, not a vague "does this look okay":

Does the repo actually exist, and is it maintained? Not "does the URL resolve" — whether there's a real codebase behind it, with commits that look like ongoing work rather than a single initial push two years ago. A dead repo with a polished DReview listing would be worse than no listing at all.

Is there a real, stated license? Not just a field with text in it — the license the submitter claims has to actually match what's in the repo. This matters more than it sounds like it should: a server with no clear license is legally ambiguous to depend on, license or no license field filled in.

Do the install configs actually work? This is the single most common source of a bad first impression with any MCP server. A config that was copied from an early version of a README and never updated might reference a package name the maintainer renamed months ago, leave out an environment variable the server now requires to start, or list a command field for a server that's since moved to a remote, URL-based setup entirely — three different failure modes that all look identical to a new user: the client just refuses to connect, with no obvious reason why. The configs on an approved DReview listing are checked against what the repo actually expects right now, not copy-pasted from whatever the submitter happened to paste in.

Does the description match what the code does? A one-line pitch that oversells — claiming broader capability than the tool actually has, or glossing over a major limitation — gets sent back for a rewrite before approval, not approved and quietly ignored.

The most common reason a listing gets rejected

It's rarely something adversarial. The most common outcome isn't "this is malicious," it's "this doesn't work yet" — a repo with no commits since the initial scaffold, an install config that references a package that was never actually published, or a description for a feature that's still on a roadmap rather than in the code. Those get rejected (or sent back for the submitter to fix and resubmit) for the same reason a broken product wouldn't get shelf space in a physical store: it's not that the idea is bad, it's that what's actually there right now isn't ready for someone else to depend on.

What "approved" means — and what it doesn't

Approval means a listing cleared the four checks above at the time it was reviewed. It does not mean a line-by-line security audit of the server's source code — that's a different, much larger undertaking than reviewing a directory submission, and no directory (this one included) should imply otherwise. It also isn't a permanent, one-time judgment: an already-approved listing can still be revisited later. If a creator later needs to update their listing, the change goes back through the same review before it replaces what's live — it doesn't just overwrite the approved version directly.

What happens if something changes after approval

Review doesn't stop the moment a listing goes live. If a specific tool turns out to have a real problem, it can be pulled from public view on its own, without touching anything else the same creator has published — the listing disappears from Browse, search, and the sitemap, but the record isn't deleted, so it can come back once whatever the issue was gets resolved. If the concern is with the creator rather than one specific tool, their whole account can be suspended instead, which pulls every listing they've published at once. Either way, someone who already has the URL to an affected listing doesn't just hit a dead page — they see a plain notice that it's temporarily unavailable, and the page is marked so it won't show up in search while that's true. Nothing about either action is presented as a permanent verdict; both are built to reverse cleanly the moment the underlying issue is actually fixed.

Why this matters more for MCP than a typical app directory

An MCP server isn't a passive listing you read about — it's something you connect directly to an AI agent that can act on your behalf, sometimes with real permissions attached: reading files, sending messages, moving money. The MCP ecosystem is young enough that there isn't yet the kind of standardized vetting infrastructure mobile app stores built up over more than a decade, and that gap has already been exploited in the wild: security researchers have documented attackers impersonating legitimate integrations with convincing GitHub accounts and cloned repos, distributing servers that quietly harvest browser credentials or SSH keys once installed. At least one real, published CVE involved a popular MCP proxy tool improperly validating redirect URLs in a way that let a malicious server execute arbitrary shell commands on the connecting machine. None of that means every unlisted MCP server is dangerous — most aren't, and plenty of the best ones are solo projects with no directory listing at all. It does mean "someone already checked the basics before you got here" is worth more in this ecosystem than it would be for, say, a directory of recipe blogs, precisely because the failure mode isn't a broken link — it's an agent doing something you didn't intend with access you didn't realize you'd granted.

How to still check for yourself

A directory review is a starting bar, not a replacement for your own judgment, especially for anything touching sensitive data or real accounts. The where to find MCP servers on GitHub guide covers the same checklist in more depth for servers you find outside a directory entirely — commit recency, what permissions the tool's own README actually documents, and why a license file matters even when a project looks otherwise solid. It's the same standard applied here, just written out so you can run it yourself on anything you're evaluating, listed on DReview or not.

If you're browsing listings and want to see what a fully filled-out, approved one actually looks like — description, use cases, FAQs, and real install configs together — Filesystem MCP Server and Stripe MCP are both good examples from opposite ends of the local/remote split. And if you maintain an MCP server yourself, submitting it puts it through exactly this process.