Publish an MCP server people can find

What a directory can read is what people can find

An MCP server gets found when the facts a reader needs are written where a directory can read them: a one-line description of what it does, a configuration block that names every credential it needs by its real variable name, the services it connects to named plainly, a licence, and a repository that shows recent work. Directories that read from the repository, as this one does, can only publish what the repository says.

The MCP server directory lists many servers that do similar things (servers on record: 8,106). The rows that are easiest to choose are the ones that answer the reader's first question, which is what installing this hands over.

Write the configuration block for the reader

The credential column for every server is read from the configuration block in its README: environment variable names that end in TOKEN, KEY, SECRET, PASSWORD and similar words. Use the real names your code reads, such as a variable named after your service ending in API_KEY. A block that only shows YOUR_TOKEN or a bare API_KEY gives the directory nothing, because those placeholders are removed as names nobody can act on.

Say beside each variable what permission it needs. A maintainer who writes that a read-only token for one project is enough has answered the question a cautious reader would otherwise spend twenty minutes on, and made their server the easier install.

Keep that block in step with the code. When a release adds a variable, add it to the README in the same commit.

A server that signs in through a browser instead of a variable should say so in words. The directory cannot see that kind of credential, and a reader who sees an empty column deserves to know why.

Name what it reaches, and nothing extra

The reach column is matched against a fixed list of common services, read from the repository name, the repository description and the prefix of each credential name. Example configuration is not read for reach. So name the service your server connects to in the repository description, in plain words, and name each credential after its service. Leave out services it merely mentions, because a reader treats that column as what installing it exposes.

Keep the tool list in the README too, with a sentence for each tool saying whether it reads, writes, deletes or sends. Readers who check before installing will look for this, and the post on evaluating a server tells them to.

Description, licence and signs of life

The description and stars on a row come from the repository. The main table orders by stars, which the page says plainly is a popularity signal and not quality, so a new server will start low there. Use-case pages list every published server in a group in full, and placement in a use case is decided by rules reading what the repository says, so a clear description of the job matters more than a clever name.

Add a licence. The directory has a tile for servers that carry one, described as the set where the author said what people may use the code for. Push when you fix things. Another tile lists servers pushed to recently and another lists those nobody has touched in a long time, and both are visible to every reader.

If you started from a template, change it. Unchanged copies of one starter template are counted on their own tile, apart from distinct servers.

Official marks and corrections

A server is marked official only when the site's records link it to a vendor's product as that vendor's own server. A vendor whose mark is missing, or anyone who finds a wrong fact on a row, can say so on the corrections page. For your company's product listing elsewhere on the site, claiming the listing is free, proves the page is yours through control of its domain, and lets you correct facts with a source.

No payment changes where a server or product appears in a ranked list. The query that orders a public list does not join the billing table, and paid placement, where it exists, is labelled.

Search pages and thin copies

Each server in the directory has its own page, and not every one is offered to search engines. The rule is written down and kept in one small module so it can be inspected. A page needs a written description of its own rather than the repository's words repeated, and a server that is archived or gone is never offered.

Beyond that, a server linked to a vendor as its official server qualifies on that link alone. Others need something distinctive, such as a stated reach or credential or a meaningful number of stars, and a floor of stars below which a page is held back whatever else it carries. The reasoning on record is that search engines declined pages that were near-copies of a README, and a held-back page is still listed in the directory.

For a maintainer the practical point is that the same things that help a reader help here. A clear description, named services and real credential names are what make a page more than a copy of the repository.

None of this changes where a server appears in the directory's own tables, which follow the ordering described above. It only decides whether a server's own page is put forward to search engines, and the module that makes the decision is short enough for a maintainer to read.