Home · Guides

A capital letter is worth about 20 places in registry search

The official MCP registry orders search results by the server name string in byte order. ASCII puts digits (0x30 to 0x39) before uppercase letters (0x41 to 0x5A) before lowercase (0x61 to 0x7A). Since io.github.<login> is derived from your GitHub username, the capitalisation of that username decides where you land among everyone else who logged in the same way.

Measured on the token pdf, 2026-09-09, one call, version=latest. These are consecutive rows:

28  io.github.263311487-ux/imprint-pdf
29  io.github.AmerSarhan/pdffr-mcp
30  io.github.AryanBV/pdf-toolkit-mcp
...
39  io.github.GuruPDF/gurupdf-mcp
40  io.github.JoyTruepath/truepath-pdf-mcp
41  io.github.LifeAbundantly/akd-vaultpdf
   (lowercase logins begin below this point)

Every digit-leading login precedes every capitalised one, and every capitalised one precedes every lowercase one. The same shape on invoice: io.github.CSOAI-ORG at 46, io.github.Wxt-ai at 49 to 51, and the first lowercase login, io.github.amehiny, at 52.

The proof that it is byte order and not alphabetical order

Pull a result set that contains both cases and compare the returned order to two different sorts. Run against search=_, which returns names containing a literal underscore, on 2026-09-09:

names == sorted(names)                  -> True     # byte order, case sensitive
names == sorted(names, key=str.lower)   -> False    # alphabetical, case insensitive

31 of those 100 names contained a capital. Inside one namespace the ordering reads ai.smithery/STUzhy-py_execute_mcp then ai.smithery/arjunkmrm-scrapermcp_el, which no case-insensitive sort would produce.

The registry's source says the same thing. From internal/database/postgres.go in modelcontextprotocol/registry, read 2026-09-09, the search filter and the ordering are two separate lines:

conditions = append(conditions, fmt.Sprintf("server_name ILIKE $%d ESCAPE '\\'", argIndex))
...
ORDER BY server_name, version

Matching is case-insensitive, ordering is not

ILIKE is Postgres's case-insensitive match, so the query text's case is irrelevant. Measured 2026-09-09: search=slack, search=Slack and search=SLACK each return the same 20 servers. The ORDER BY has no such folding. So you cannot search your way around it, and you cannot spell your way into a better rank either, because the only lever is the bytes of the name itself.

The wildcards are escaped, so there is no shortcut

The same source escapes backslash, percent and underscore before wrapping the term in %...%. Verified live on 2026-09-09: search=% returns 0 servers, and search=_ returns names that literally contain an underscore rather than everything. A comment in the code names the exact attack this closes, a single-character search expanding into a wildcard.

What this is worth, and what it is not

On invoice, 73 servers match. io.github.CSOAI-ORG sits at 46 and io.github.theluckystrike at 63. Nothing separates them except letter case, and 17 places on a 73-row list is the difference between the visible part and the scroll. On pdf the first io.github row is 28th and ours is 90th.

Two honest limits. First, the effect is inside your namespace prefix: every ai. and com. namespace still sorts ahead of every io. one, whatever your username looks like, and on 19 of 29 tokens measured this day the rank-one row was an ai. namespace. Second, you cannot retrofit it. Version metadata is immutable, there is no unpublish, and a differently cased login is a different namespace, so it means new rows competing with your old ones in the same sorted list.

The place this is actionable is before your first publish. If you are choosing between a personal GitHub account and an organisation, or you have not published yet, the case of that handle is a free variable that nobody tells you is load-bearing.

Reproduce it

curl -s 'https://registry.modelcontextprotocol.io/v0/servers?search=pdf&limit=100&version=latest' \
  | python3 -c 'import json,sys; [print(i,r["server"]["name"]) for i,r in enumerate(json.load(sys.stdin)["servers"],1)]'

Sources: the live registry API, 29 tokens measured 2026-09-09, every result set confirmed to equal its own byte-order sort; internal/database/postgres.go on the registry's main branch for the ILIKE filter, the escaping and the ORDER BY. Ranks quoted are the positions in a single version=latest page of 100.

Questions

Can I change the case of my GitHub username?

GitHub lets you rename an account, and case is part of a rename. That gives you a new registry namespace, not an edited one: existing rows keep the old name because published metadata is immutable and nothing can be unpublished. You would be adding rows that compete with your own.

Does this apply to the local name after the slash?

Yes, by the same rule, but it only matters once the namespaces are equal. The comparison walks left to right, so every character of the namespace is decided before the first character of your server name is looked at.

Would a name starting with a digit sort first?

Within a namespace, yes, and the pdf result set shows one doing it. The name pattern allows digits, so io.github.263311487-ux sorts ahead of every letter. Nobody appears to be doing this deliberately.

Is byte order guaranteed, or is it a database collation that might change?

The SQL says ORDER BY server_name and the collation is the database's. What is measurable from outside is that every result set tested on 2026-09-09 matched a byte-order sort exactly and none matched a case-insensitive one. Treat it as measured behaviour rather than a promise.

Does search look at the description?

No. The filter is on server_name only. A server whose description answers a query perfectly does not appear unless the token is in its name.

Related

All MCP servers and prices · All guides · Buy the bundle $39