If your client, launcher or script looks up servers in the official MCP Registry, a search term shorter than three characters now fails with HTTP 422. The change arrived in MCP Registry v1.8.6, published on 27 October 2026 at 14:42 UTC. This post explains how the registry’s server list is queried, what the release changed for callers, and what client code has to handle. The sources were read on 28 October 2026, and the only requests to the live registry were plain GETs, first made around 13:06 UTC.
How the registry’s server list is queried
The server-list endpoint’s parameters decide what a search can return. The generic registry API spec defines a standard REST API for MCP registries to list and fetch MCP servers, and says no authentication is required by default to read. The official registry API doc describes the instance hosted at registry.modelcontextprotocol.io, which adds endpoints and restrictions on top of that spec. Its list endpoint is GET /v0.1/servers.
The official doc lists four filters on top of paging. search is a case-insensitive substring match on server names. version takes latest or an exact version such as 1.2.3. updated_since takes an RFC3339 timestamp, and include_deleted defaults to false but becomes true automatically when updated_since is set. The doc calls the search “intentionally simple” and points to subregistries for anything more advanced.
Page size is set with limit. In the v1.8.6 handler source, it defaults to 30, with a minimum of 1 and a maximum of 100. The live OpenAPI file publishes the same three numbers.
Search terms now need three characters
This change can break callers such as a search box that queries the registry on every keystroke. The v1.8.6 release notes say nonempty search terms need “at least three Unicode characters”, and shorter searches return HTTP 422. Production runs it: on 28 October, /v0.1/version reported version 1.8.6, built from the same commit as the release.
The official registry API doc adds the details. The length is counted after trimming surrounding whitespace, and whitespace-only searches are also rejected with 422 before any database work. The trimming applies to the length check alone; the substring match still uses the term as sent. An omitted or empty search still lists normally, and a short search is never treated as an unfiltered list. The doc notes that one- and two-character searches used to be accepted.
The handler source counts the trimmed term with Go’s utf8.RuneCountInString, which counts Unicode code points, not bytes. The test for the minimum runs every case against both /v0 and /v0.1. It expects 422 for a, ai, a with two spaces on each side, and the two-character Chinese term 测试. It expects 200 for 测试名, mcp, abc with one space on each side, and a.b. It also asserts that a rejected search never reaches the service or database.
The rule came from pull request #1750, which applies it to both API versions and the registry’s web UI.
What a rejected search returns
The error body names the rule, so a client can show it to the user. These two requests were made on 28 October 2026, and both returned HTTP 422 with the same body:
curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=gh&limit=2"
curl -s "https://registry.modelcontextprotocol.io/v0.1/servers?search=gh&limit=2"{"title":"Unprocessable Entity","status":422,"detail":"search must contain at least 3 characters after trimming surrounding whitespace"}The same request with search=github returned HTTP 200. Its body held a servers array of records, each with a server object and a _meta object, plus a metadata object with nextCursor and count. With limit=2, count was 2, the number of items on that page. The live OpenAPI file describes the three-character rule on search, but lists errors as a generic default response of type application/problem+json, with no separate 422 entry.
Results list versions, sorted as text
A search returns server versions rather than servers, which matters for any client that shows a single version per match. The official registry API doc says listings hold one record per server version, so a search without version can return several versions of one server, including superseded ones. Results are sorted by name, then by version string compared as text, so 1.10.0 sorts before 1.2.0. To get the latest version of each match, pass version=latest, and keep the same filters when following metadata.nextCursor. When the full server name is known, the doc recommends GET /v0.1/servers/{url-encoded-server-name}/versions/latest instead of a substring search.
Paging with the cursor
Paging matters once a search matches more servers than limit allows on one page. The generic registry API spec says to omit cursor on the first request, then pass the nextCursor value from each response. Results end when nextCursor is null or empty. Cursors are opaque strings, and the spec says never to build or modify one by hand.
The rest of the release is about search performance
The other items in the release notes are about search performance under mixed search, pagination and publishing traffic. They list selecting page keys through covering indexes before fetching full records, and planning each search for its actual parameter values.
The release notes also mention “namespace suffix searches”. According to pull request #1750, that means an index on the reversed, lowercased namespace and an extra prefix predicate for searches containing /. The original case-insensitive substring match stays, so results do not change. The pull request says captured production plans for one namespace-spanning term examined about 133,000 candidates to return one row.
The staging write-up dated 27 October 2026 scheduled 200 uncached searches per second for 60 seconds, 12,000 in total. Both candidate runs completed 12,000 of 12,000, while two runs of the previous image completed 11,762 and 8,716. The write-up says short-search rejections were not counted as throughput. It limits the result to its fixed corpus and infrastructure, and notes that broad substring filtering still costs work in proportion to the names examined.
What a client should do
Trim the term and count its characters before sending, and skip the request when the count is one or two. Send no search at all when the trimmed term is empty, since the official registry API doc says that still returns the normal listing. If a 422 comes back anyway, show its detail text. Add version=latest when only current versions matter, and page with nextCursor exactly as returned.
Limits
No source read here explains why the minimum is three rather than another number. The docs say “Unicode characters” while the code counts code points, and whether an emoji or accent built from several code points counts as several characters is not documented or tested. No total-match count is documented, the behaviour of limit outside 1 to 100 is not stated, and rate limits for anonymous reads are not described in these sources. As of 28 October 2026, the repository’s copy of docs/reference/api/openapi.yaml still described search without the minimum, and its API CHANGELOG.md did not mention search.