The MCP registry at registry.modelcontextprotocol.io is the official metadata repository for publicly accessible Model Context Protocol servers, backed by Anthropic, GitHub, PulseMCP and Microsoft (the registry's about page). It launched in preview on September 8, 2025 (launch post), and its documentation still calls it a preview on 12 October 2026. For a legal AI MCP buyer it answers one question: did the people who claim to publish this server actually publish it?
Reviewed and corrected on 12 October 2026. This is general information, not legal advice.
TL;DR
- The registry hosts metadata only. A listing points to an npm, PyPI or Docker package, or to a remote server URL. The docs warn that breaking changes or data resets may occur before general availability.
- Server names are reverse-DNS names whose namespace is proven when you publish. A GitHub login proves
io.github.<owner>/.... A DNS record or a file under/.well-known/proves a domain such ascom.example.*/.... - Before installing, read five fields: the namespace, the repository, the
remotesorpackagesblock (where your data goes), theversionandpublishedAtdates, and the status (active,deprecatedordeleted). - The registry checks who published a name. It does not scan the code and moderates very lightly, so vendor diligence stays with you.
- On 12 October 2026 a name search for
legalwithversion=latestreturned 65 servers from dozens of namespaces. The registry indexes what exists. Nobody has vetted the list.
A vendor tells you its legal research MCP server is "in the official registry." What have you learned?
Part of our MCP and developer guide series.
For related MCP and developer coverage, see legal research from inside Cursor and Claude Code.
What the registry is, and where marketplaces fit
The registry's own documentation describes a metadata layer. A listing is a server.json file that gives the server's unique name, where to find it (an npm package name or a remote server URL), how to run it, and some discovery data such as a description. The docs say the registry supports open-source and closed-source servers as long as the install method or the server itself is publicly reachable. It does not support private servers.
Two other points from the docs shape how to use it:
- It is meant to be consumed mainly by downstream aggregators, such as MCP marketplaces, which can add curation, ratings or extra checks. The about page says host applications are not meant to read the registry directly and should use those downstream registries instead.
- It delegates security scanning. The about page names the underlying package registries and the downstream aggregators as the places where scanning happens.
The GitHub MCP Registry, announced September 16, 2025, is one such downstream registry. GitHub said then that servers self-published to the community registry would appear in its own registry automatically, sorted by stars and activity, with one-click install in VS Code. A buyer can check the same server in the registry API whichever marketplace surfaced it.
So the title of this post is a metaphor with one correction. The registry is the catalog that app stores can be built on, and the stores sit downstream of it.
Why it matters for legal AI
Legal is a trust-first market. Before features, a practitioner asks who wrote a tool that touches client data and where the data goes.
Before a registry, the first question had no standard answer. Anyone could publish a package with a name like westlaw-search-mcp or write a README that claimed an affiliation. A verified namespace gives you one checkable claim: the publisher controlled that GitHub account or domain when the version went up.
It does not tell you whether a server is SOC 2 compliant, where it runs, or whether the maintainer carries insurance. Those remain vendor diligence.
How a listing gets verified
The registry's authentication guide and GitHub Actions guide describe four ways to authenticate, and the method decides the namespace.
| Method | Namespace you may publish under | How it proves control |
|---|---|---|
GitHub, interactive (mcp-publisher login github) | io.github.<user or org>/* | An OAuth device flow, completed in a browser |
GitHub OIDC (mcp-publisher login github-oidc) | io.github.<user or org>/* | A GitHub Actions workflow with id-token: write, no stored secret |
DNS (mcp-publisher login dns) | Reverse-DNS form of your domain, com.example.*/* | A TXT record on the domain, for example v=MCPv1; k=ed25519; p=<public key>, plus a signature from the matching private key |
HTTP (mcp-publisher login http) | The same domain-based names | A file at /.well-known/mcp-registry-auth on the domain |
The docs recommend OIDC for GitHub Actions. For an npm package, the registry also checks that package.json carries an mcpName property equal to the server name, so the package and the listing point at each other.
There is no anonymous submission path. The moderation policy adds that the registry is permissive: it removes illegal content, malware, spam and non-functioning servers, and it tells consumers to assume minimal-to-no moderation. The launch post describes community-driven flagging, after which maintainers can denylist entries.
The anatomy of a listing
This is the live entry for the latest version of one real server, io.github.Vaquill-AI/vaquill-mcp, read from the registry API on 12 October 2026 and trimmed to one remote:
{
"server": {
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"name": "io.github.Vaquill-AI/vaquill-mcp",
"description": "Search US and Indian statutes, regulations, constitutions, and court rules.",
"title": "Vaquill",
"repository": {
"url": "https://github.com/Vaquill-AI/vaquill-mcp",
"source": "github"
},
"version": "0.4.1",
"remotes": [
{
"type": "streamable-http",
"url": "https://mcp.vaquill.ai/mcp",
"headers": [
{
"description": "Optional. Leave unset to sign in with your Vaquill account over OAuth 2.1 (recommended; the server advertises discovery metadata). To use an API key instead, send 'Bearer vq_key_...'; get a key at https://www.vaquill.ai/legal-api.",
"format": "string",
"isSecret": true,
"name": "Authorization"
}
]
}
]
},
"_meta": {
"io.modelcontextprotocol.registry/official": {
"status": "active",
"statusChangedAt": "2026-10-02T13:36:19.821799Z",
"publishedAt": "2026-10-02T13:36:19.821799Z",
"updatedAt": "2026-10-02T13:36:19.821799Z",
"isLatest": true
}
}
}
What each field gives you:
nameis the verified identifier. Theio.github.<owner>/prefix shows that GitHub owner authenticated when this version was published.titleis an optional display name. The schema says clients may use it for display, so do not treat it as a trust signal.descriptionhas a 100-character maximum in the published schema.repository.urlis the code. Check the license, recent commits and open issues, and whether the README matches the listing. The registry does not check that the repository holds what the listing claims beyond its package checks.versionmust be unique per publication, and once published a version's metadata cannot be changed. The registry recommends semantic versions. Compare the listed version with the repository's tags.remotesis the block that matters for a hosted server.urlis where your client connects.headerslists what the client must send, andisSecret: trueflags a sensitive value. This is the data flow, so read it first.packages(not shown) is the block for servers you run yourself. It lists npm, PyPI, Docker or other package coordinates._meta.io.modelcontextprotocol.registry/officialcarriesstatus(active,deprecatedordeletedin the OpenAPI document), the status and publish timestamps, andisLatest.
Every version is its own entry. The vaquill-mcp name returns six entries, 0.1.1 through 0.4.1, and only 0.4.1 has isLatest: true. Add version=latest to a query unless you want the history.
Trust signals to check before installing a legal MCP server
- Verified namespace.
io.github.<owner>/or a reverse-DNS domain name. Then confirm the owner is the organization the vendor's own site names. - Public repository with recent activity. A listing that points at a dead repository is a warning. A listing with no
repositoryblock is harder to check at all. - License. Read it. A proprietary license is fine for a commercial hosted server, but then the source you read may not be what runs.
- Credentials. In
remotes.headers, look at what the client sends and whether it is markedisSecret. Servers differ: some take your own API key, some offer OAuth sign-in, and some require a vendor token. Ask what the server stores. - Data residency. The listing shows the connection URL. It does not say where the server runs or what it logs. US engagement letters often limit where covered data may be processed, so ask the maintainer in writing.
- Recency. Compare
publishedAtwith the repository's activity and with the MCP spec revision your client expects. - Status. Skip
deprecatedanddeletedentries. The API hides deleted servers unless a request setsinclude_deleted.
None of these checks is done for you. They are checks you do with the registry as the starting point.
What the registry holds for legal today
On 12 October 2026 the call below, which asks for latest versions only, returned 65 servers whose names contain legal, with no further page:
curl -m 300 "https://registry.modelcontextprotocol.io/v0.1/servers?search=legal&version=latest&limit=100"
They come from dozens of namespaces. Some are US primary-law tools, some cover other countries, and many are document tools such as analyzers and policy generators. The registry does not rank them or sort them by jurisdiction, so reading a handful of listings is the only way to tell them apart.
The search parameter is a substring match on the server name only, so servers that never put a word like legal in their name will not appear for that query. Our own entries, for example, did not appear in the legal search and came up under search=vaquill. The same search returned three servers under the io.github.Vaquill-AI/ prefix: vaquill-mcp, which wraps the Vaquill AI statutes and regulations API, and two others that wrap other publishers' public APIs and take that publisher's own token. For wiring vaquill-mcp into an editor, see legal research from inside Cursor and Claude Code.
A server that is not in the registry is unverified by this method, which says nothing about its code. Plenty of useful MCP servers are distributed only through npm or GitHub.
The publishing flow
For anyone publishing a legal MCP server, the docs' GitHub Actions flow is short. Here is the registry-specific part of the OIDC workflow from the GitHub Actions guide, which runs on a version tag:
permissions:
id-token: write # required for OIDC authentication
contents: read
steps:
- name: Authenticate to MCP Registry
run: ./mcp-publisher login github-oidc
- name: Publish server to MCP Registry
run: ./mcp-publisher publish
Before that step the workflow installs the mcp-publisher binary. Per the quickstart, you also run mcp-publisher init to create server.json. Two rules cause most first-time failures. The description must be 100 characters or fewer, and the version must be new for every publish. Write the registry description first and the README description second.
To confirm a publish, search for the exact name:
curl -m 300 "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.<owner>/<repo>&version=latest"
Treat the namespace as the trust anchor and the repository as the source of truth. Treat the registry as a vetted list of good servers, and something legitimate-looking that points at unmaintained code will catch you out.
A scanner you can run today
For batch vetting, this jq snippet pulls the trust fields from a registry response. The filter ran as written against live responses on 12 October 2026:
curl -s -m 300 "https://registry.modelcontextprotocol.io/v0.1/servers?search=vaquill&version=latest" \
| jq -r '.servers[] | [
.server.name,
.server.version,
.server.repository.url,
._meta["io.modelcontextprotocol.registry/official"].status,
._meta["io.modelcontextprotocol.registry/official"].publishedAt,
([.server.remotes[]?.headers[]? | select(.isSecret == true) | .name] | join(","))
] | @tsv'
Per server you get the verified name, version, repository URL (empty when a listing has none), status, publish timestamp and a comma-separated list of secret headers. For vaquill-mcp the line reads io.github.Vaquill-AI/vaquill-mcp, 0.4.1, its repository URL, active, 2026-10-02T13:36:19.821799Z, and Authorization,Authorization (one secret header per remote). The endpoint was slow in our tests: first calls took from 20 seconds to nearly three minutes, and some timed out at 40 to 120 seconds. Set a long timeout and cache the result. Results come in pages of 30 by default, and metadata.nextCursor is the value to pass as cursor for the next page.
Attack surfaces worth naming
Trust rests on namespace ownership, so the risks cluster around spoofing a namespace or compromising the identity behind it. These are risks to plan for. We observed no incident.
- Look-alike namespaces. Anyone can create a GitHub organization with a name close to a known vendor's. Copy namespaces from the vendor's own site, and pin the version in your client configuration.
- A compromised publisher. If a publisher's CI or account is taken over, an attacker could publish a malicious new version under a legitimate name. Publishers should protect publish workflows, and users should pin versions and watch
versionandpublishedAt. - Aging domain verification. A domain-based name was proven at publish time. Not verified in our October 2026 review: whether the registry re-checks domain ownership later. Treat an old
publishedAton a domain-based name with care.
What this means for client intake
Add an MCP namespace check to your vendor security intake. Any AI tool that uses MCP should give you its exact registry name, and that name should resolve in the official registry with the repository you expect.
Ask each vendor what credentials the client sends, where the server runs and what it logs. Write the credential lifecycle into your engagement letter, since the registry will not tell you where a server runs.
What to do with this
Practitioners: ask for the registry name, run the search, and read the remotes and repository fields before you install anything.
Developers: publish your servers there, even at 0.1.0, with a clear description and a remotes block that says plainly what the client sends. Verified names are the thing the ecosystem can check.
The registry has no code scanner and almost no moderation, and the docs call it a preview. Within those limits it gives you one fact you could not get before: who controlled the namespace when a version was published.
For the US statutes, regulations and court rules a legal MCP server would query, see the US primary law API or the Vaquill AI MCP page.
FAQ
What is the MCP registry?
It is the official metadata repository for publicly accessible Model Context Protocol servers at registry.modelcontextprotocol.io. It stores listings, not code, and points to the packages or remote URLs where servers live. Anthropic, GitHub, PulseMCP and Microsoft back it, and it launched in preview on September 8, 2025.
Is the MCP registry the same as the GitHub MCP Registry?
No. The community registry at registry.modelcontextprotocol.io is where servers are published once. The GitHub MCP Registry is a downstream registry that, per GitHub's September 2025 announcement, adds a browse-and-install interface in VS Code and surfaces servers from the community registry.
How do I find a legal AI MCP server in the registry?
Query the API with a search term: curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=legal&version=latest". The search matches server names only, so also search for a vendor's exact name. Check the namespace, repository, remotes and status of each result, and expect a slow first response (see the timing note below).
How do I publish my MCP server to the registry?
Install the mcp-publisher CLI, create a server.json, authenticate, and run mcp-publisher publish. For an npm package, add an mcpName property to package.json that matches the server name. Authentication is mcp-publisher login github for a GitHub namespace, github-oidc inside GitHub Actions, or a DNS or HTTP challenge for a domain. See the official quickstart.
Is the MCP server registry free?
The documentation lists no fee for publishing, and the listing endpoint answered without a key on 12 October 2026. The registry only hosts metadata, so you still publish your package to npm, PyPI or Docker Hub, or host a remote server yourself.
What legal AI MCP servers are in the registry today?
A name search for legal with version=latest returned 65 servers on 12 October 2026, from many namespaces and covering many jurisdictions and use cases. Under the io.github.Vaquill-AI/ prefix the registry lists three servers, including vaquill-mcp for US statutes, regulations, constitutions and court rules.
How does the registry verify a legal MCP server is legitimate?
It verifies the namespace and nothing else. io.github.<owner>/ shows that the GitHub owner authenticated when the version was published, and a reverse-DNS name shows control of that domain through a DNS record or a hosted file. The registry does not scan code, audit data handling or check compliance, and its moderation policy tells consumers to assume minimal-to-no moderation.
For a verified legal MCP server to start from, see Vaquill AI's MCP page, or email contact@vaquill.ai.
New legal AI guides, weekly.
Further Reading
- Legal Research from Inside Cursor and Claude Code: The MCP Way
- Adding Legal Research to Your AI Agent with MCP
- Claude Legal Research MCP: How to Use Claude for US Legal Research
- Legal API in 2026: What It Is, What It Returns, and How to Pick One
- USC API: How to Pull US Code Sections Programmatically
- Top Legal Data APIs for Developers in 2026

Co-Founder & CTO
Priyansh leads engineering and AI at Vaquill AI: the pipelines that pull statutes, regulations and court rules from every US jurisdiction's official publisher, and the REST API, MCP server and open dataset that serve them.
