Building a Directory of MCP Servers: A Niche Playbook
A worked playbook for cataloguing MCP servers: the typed attributes that make listings comparable, why a flat repository list loses to a filterable directory, and how to handle freshness and trust without certifying anything.
Your AI chat can build this directory.
Describe the niche, watch the agent design the fields and fill the catalogue. Free plan, no card.
MCP servers are a good test case for directory design because they are almost impossible to compare from a list. Two servers can both say "connects to your database" and differ in every way that decides whether you can actually use one: how they run, what they need from you to authenticate, and what they are permitted to do once connected. That gap between what a name promises and what a reader needs to know is exactly the gap a directory fills. Here is how I would build one, treated as a worked example rather than a survey of what exists.
Start from the decision, not the description
Before choosing a single field, write down the question a visitor arrives with. For this niche it is usually some version of: "I need a server that talks to system X, that I can run the way my organisation allows, without handing it credentials I am not comfortable handing it."
Every attribute in the schema should help answer that. Anything that does not is prose, and prose belongs in the description field where it cannot pretend to be data.
The attributes that actually characterise a server
A reasonable schema here is six typed attributes, with two more if the niche rewards them. Typed means a constrained set of values you can filter on, not free text.
Transport. Whether the server runs as a local process the client launches, or as a remote HTTP endpoint you point a client at. This single field splits the entire catalogue into two audiences with different constraints, and it is the first thing a reader filters on.
Authentication mode. None, an API key or environment variable, or a full authorisation flow. This determines whether a server is usable inside an organisation with credential policies, and it is the field most often buried in a README's third code block.
Hosting model. Self-hosted versus a vendor-operated endpoint. Related to transport but not the same question: a remote endpoint someone else runs has a data-handling story that a container you run yourself does not.
Tool surface. What the server actually exposes, and critically whether those tools only read or can also write and delete. A read-only server and a server that can drop tables are not comparable products, and treating "number of tools" as the metric hides that.
Maintenance status. Derived from the last release or last commit date, not from what the project claims about itself. Store the date; render the judgement.
Licence. A constrained enum. In a niche where half the value is self-hosting, licence is a filter, not trivia.
The two optional ones: runtime (Node, Python, Go, a container), which matters to anyone who has to deploy it, and primary system integrated (a database, a SaaS product, a filesystem), which is really a category rather than an attribute in most designs.
Six to eight is the range that stays fillable. Twelve attributes look thorough on a schema diagram and produce a catalogue of half-empty listings, which is worse than five fields filled every time.
Why a flat list in a repository loses
Most technical niches start life as a markdown table in a Git repository, and that format has a ceiling it hits quickly.
It cannot answer a compound question. "Remote servers with a proper authorisation flow, read-only, MIT licensed" is three filters. A table sorted alphabetically requires the reader to do that join by eye, across hundreds of rows, on a phone.
It has one URL. Four hundred entries, one page, one title tag. Search engines have nothing to rank against a specific query, and neither do the AI assistants people now ask these questions to. A directory gives each server its own page and its own answer.
It has no memory of what people wanted. A directory can record the searches that returned nothing, which is the single most useful content input a directory owner gets, because it is proprietary and it arrives already prioritised.
It rots invisibly. A dead entry in a list of four hundred looks identical to a live one. A listing with a visible last-verified date does not.
None of this makes the repository list worthless. It makes it the source you seed from, not the product you build.
Freshness is the hard part in this niche
In a directory of wedding venues, a listing is roughly correct for years. Here, a listing can be wrong within a quarter: projects change transport, add authentication, get archived, or move from self-hosted to a hosted endpoint.
Put a last-verified date on every listing and show it. Not a "verified" badge. A date. It tells the reader exactly how much to trust the row and it costs you nothing but honesty.
Prefer derived signals over claims. Last release date, whether the repository is archived, whether the licence file changed. Facts you can re-check mechanically age better than a paragraph the maintainer wrote once.
Re-verify on a schedule weighted by traffic. Your top fifty listings by views deserve a look every couple of months. The long tail can go two or three times longer. Analytics tells you which is which.
Make re-import safe. Bulk insertion with slug matching means a second import updates the existing entries rather than creating duplicates, so a refresh pass is a routine operation rather than a cleanup project. This is one of the places where the mechanics of the platform decide whether you actually keep the data current, because a refresh that is painful is a refresh that does not happen.
Collections catch the comparison traffic
Categories organise the catalogue: they are the main indexable surface and each deserves a real 150 to 300 word introduction explaining what belongs in it and what does not.
Collections do something different. A collection is a landing page grouping listings by a shared trait that cuts across categories, and in this niche the traits map almost one to one onto how people phrase queries: self-hosted servers, servers with a full authorisation flow, read-only servers, servers under a permissive licence, servers for a specific database engine.
Each of those is a page that answers a comparative question directly, which is the shape of query that both search engines and chat assistants can cite. Build them from the attributes you already typed. If a collection cannot be defined as a filter over your schema, the schema is missing a field.
Do not create a category under five to ten entries. An almost-empty facet page is a worse experience than no facet at all, and it dilutes the pages that do have depth.
Trust and safety, without becoming a certification authority
This is the part that requires discipline, because a directory in a security-adjacent niche is constantly tempted to imply more diligence than it performed.
Record observable facts, with a source link and a date. Whether the repository publishes a security policy. Whether the licence permits commercial use. What credentials the setup instructions ask for. All checkable, all falsifiable, none of them a judgement you have to defend.
State plainly what you did not check. A short, permanent note that listings are catalogued from public information and that nothing here constitutes a code audit is worth more than any badge. It is also the honest position.
Do not sell a trust signal. Selling placement is a legitimate business. Selling anything a reader could mistake for a safety assessment destroys the directory the first time one of those listings goes wrong.
Surface the two attributes that carry the risk. Authentication mode and write access. A reader deciding what to install is really asking what it can reach and what it can do, and a good schema answers that above the fold.
Where this goes wrong
Cataloguing everything indiscriminately. Forty complete, verified listings beat four hundred entries scraped once and never touched. Completeness is the differentiator against the list you seeded from.
Free text where an enum belongs. "Auth: see docs" appears in a filter as its own useless value. Constrain the field, or drop it.
Publishing on a free noindex subdomain and waiting for traffic. Shared subdomains are commonly noindex by design as anti-spam protection, DirectoryFast's included. Organic visibility needs your own domain, and no amount of content fixes that.
Letting the catalogue go stale for a quarter. In this ecosystem that is long enough for a meaningful share of your rows to become wrong, and wrong data is the only failure a technical audience does not forgive.
Ranking by star count. It measures attention, not fitness. A widely starred server with no release in a year is not the recommendation your filters imply it is.
Accepting open submissions without moderation. Self-submitted entries in a developer niche skew heavily towards launch announcements. Take submissions, review them, hold them to the same schema as everything else.
FAQ
How many listings before launching?
Enough that every category has five to ten complete entries. That is usually somewhere between forty and eighty, not four hundred.
Can I just import an existing public list?
As a seed, yes, respecting its licence. But an import without verification and without your own typed attributes reproduces the source's weaknesses and adds nothing a reader would return for.
Should listings include installation instructions?
Link to them rather than copying them. Instructions change often, and a stale copy on your site is worse than a link that stays correct.
How do I handle a server I think is unsafe?
Record the facts and let them speak, or decline to list it and say why in your inclusion policy. Publishing an accusation you cannot substantiate is a legal and reputational risk with no upside.
Does a niche this technical have enough search volume?
It has low volume and unusually high intent, which is the trade every good niche directory makes. Judge it on whether the visitor is worth something, not on impressions.
What if the ecosystem consolidates and the niche shrinks?
Then your typed catalogue and verification habit port to an adjacent niche far more easily than a pile of prose would. That is an argument for a real schema, not against the niche.
Sketch the schema for your niche in one conversation →