The MCP Registry Is the New App Store for Legal AI. Here's How to Read It.

The MCP registry is the official directory of Model Context Protocol servers at registry.modelcontextprotocol.io, run by Anthropic with GitHub, PulseMCP, and Microsoft. It launched in preview on September 8, 2025 (per modelcontextprotocol.io, still in preview as of June 2026), and it answers one question a legal AI MCP buyer cares about most: is this server actually published by who it claims to be? For legal AI, that single verifiable identity check is the difference between installing a tool from a Twitter thread and installing one whose namespace is provably owned by its author.

TL;DR

• The official MCP server registry at registry.modelcontextprotocol.io is the canonical place to find and trust legal-AI MCP servers. One URL to ask "is this server actually maintained by who it claims to be?" and get a yes.
• Names live in verified namespaces in reverse-DNS format. io.github.<org>/<repo> verifies via GitHub auth (OIDC in CI); com.<domain>/<name> verifies via a DNS TXT record and a signed challenge. No anonymous submission form.
• Before installing, read four fields: namespace (verified?), repository (recent commits?), remotes/packages block (where does your data go?), and _meta status (active or deprecated).
• As of mid-2026, the legal-AI servers in the registry sit under one namespace prefix. Everything else billing itself as a "legal MCP" is not registered, not verified, or both.

Part of our MCP and developer guide series.

For related MCP / API / developer coverage, see legal research from inside Cursor and Claude Code.

What the MCP Registry Is, in 90 Seconds

A few months ago I watched a paralegal at a small civil-rights firm paste an MCP URL from a Twitter thread into Claude Desktop and start asking it about pending matters. The URL pointed at a personal subdomain. No one knew who ran it.

Three attack surfaces were live: a firm-issued API key headed to an unknown destination, every prompt logged by whoever owned the host, and an unconstrained outbound channel from the firm's machine. Nothing bad happened, as far as we know. That is not a security posture, and it was the norm for the first eighteen months of MCP.

The Model Context Protocol shipped in late 2024 as Anthropic's open way for AI clients (Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, agent frameworks) to talk to external tools. For most of 2025 there was no central index. You found MCP servers the way you found jQuery plugins in 2011: GitHub README screenshots, "awesome-mcp" lists, and "trust me, paste this URL into your config."

That changed when the official registry launched in preview on September 8, 2025 (per modelcontextprotocol.io). It is a single HTTP endpoint, registry.modelcontextprotocol.io, that returns JSON for every server published to it. Anthropic runs the infrastructure with GitHub, PulseMCP, and Microsoft as backers; schema and tooling are open source. It is still labeled preview as of June 2026, so expect schema tweaks, but the namespace and trust model below is stable.

Three things make it useful:

1. Namespaces have owners. You cannot publish io.github.acme/legal-mcp unless you are a member of the acme GitHub org, or me.acme-law.com/some-server unless you control DNS for acme-law.com. The registry refuses anything else.
2. Servers self-publish. No human moderator. A CLI called mcp-publisher authenticates, validates a server.json, and hands it over. Verification is in the auth step, not a review queue.
3. Listings are machine-readable. Every entry conforms to a JSON schema (currently dated 2025-12-11). Remote URL, required headers, package coordinates, license: all defined.

That last point turns it into an app store rather than a directory. Cursor's MCP picker and Claude Desktop's connector marketplace both pull from it. Listings are now a distribution channel, not a vanity badge.

The discovery layer is deliberately split in two. You publish once to the community registry (registry.modelcontextprotocol.io), and downstream aggregators read it on a schedule. The GitHub MCP Registry (announced September 16, 2025) is one such aggregator: servers published to the community registry surface there automatically, sorted by stars and activity, with one-click install in VS Code. So a legal MCP author publishes in one place and shows up in several. A buyer can verify the same server in the registry API regardless of which marketplace surfaced it.

Why It Matters for Legal AI Specifically

Legal is a trust-first market. A practitioner installing a tool that touches client data needs to answer two questions before features: who wrote this thing, and where does my data go when I use it.

Before the registry, the first question was effectively unanswerable. Anyone could publish "westlaw-search-mcp" on npm. Anyone could write a README claiming an affiliation.

There was no chain of custody between the name on the box and the person typing the code. For a solo or small firm without a security team, the realistic posture was "don't install anything unless your bar association mentioned it." That left a lot of useful tools on the table.

The registry does not fix vendor diligence. It does not tell you whether a server is SOC 2 compliant or whether the maintainer carries malpractice insurance.

What it does is collapse the identity question to a single verifiable claim. The io.github.<org>/ prefix proves that exact GitHub org published the server. Same identity assurance as an iOS app marked "by Apple Inc." Whether you trust the org is a separate question; at least you know who you are trusting.

How a Listing Gets Verified

Two verification paths exist, and they are not equivalent.

GitHub OIDC (io.github.<org>/<repo>). Most legal-AI servers use this path because GitHub is where the code lives. A server.json declares the name, a GitHub Actions workflow runs mcp-publisher login github-oidc, GitHub mints a short-lived OIDC token proving the workflow is running inside <org>/<repo>, and mcp-publisher publish ships it.

No long-lived secrets anywhere. Fork the repo to a different org and publish fails because the OIDC sub claim no longer matches. Same trust pattern PyPI uses for trusted publishers.

DNS verification (com.<domain>/<name>). For a namespace tied to a website in reverse-DNS form. The publisher generates a keypair, publishes the public key as a TXT record, runs mcp-publisher login dns, and the CLI signs a challenge the registry verifies against the TXT record (see the authentication guide). More setup, more failure modes. Most publishers stick with GitHub auth.

There is no other path. A server that skips verification cannot publish to the official registry. It can still distribute via npm or Docker and ask users to add config by hand, which is the surface the registry was built to make obsolete.

The Anatomy of a Listing

Here is what the registry returns for an actual entry, the live Vaquill AI statutes MCP, lightly trimmed:

{
  "server": {
    "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
    "name": "io.github.<publisher>/vaquill-mcp",
    "title": "Vaquill AI Statutes",
    "description": "MCP for US statutes and legislation: the US Code, CFR, and all 52 state and territory codes.",
    "repository": {
      "url": "https://github.com/<publisher>/vaquill-mcp",
      "source": "github"
    },
    "version": "0.1.0",
    "remotes": [
      {
        "type": "streamable-http",
        "url": "https://mcp.vaquill.ai/mcp/",
        "headers": [
          {
            "name": "Authorization",
            "description": "Your Vaquill AI API key. The server never stores your key.",
            "isRequired": true,
            "isSecret": true
          }
        ]
      }
    ]
  },
  "_meta": {
    "io.modelcontextprotocol.registry/official": {
      "status": "active",
      "publishedAt": "2026-05-15T05:21:53Z",
      "isLatest": true
    }
  }
}

Every field is doing real work:

• name is the verified identifier. The io.github.<org>/ prefix proves that GitHub org authenticated via OIDC.
• title is the display name. Unverified. Useful for humans, not load-bearing for trust.
• description is capped at 100 characters by registry validation. Not much room to lie.
• repository.url is the code. Check license, recent commits, issue volume, and whether the README matches the entry. No automated check that the registry entry matches the repo's contents.
• version is what was last published. Compare against git tags. A registry entry on 0.1.0 while the repo is at v0.3.5 means the maintainer let it drift.
• remotes is the interesting block for hosted servers. url is where your client connects. headers lists credentials your client must send, with isSecret: true flagging anything sensitive. This is the data flow; read it carefully.
• packages (not shown) is the alternative for locally-run servers. Lists npm, PyPI, or Docker coordinates. A server with both lets you choose hosted vs. self-hosted.
• _meta.io.modelcontextprotocol.registry/official.status is active or deprecated. Always check. Deprecated servers can still appear in search results.

Create an API keyBook a demo

Trust Signals to Check Before Installing a Legal-AI MCP

After publishing three legal-AI servers and fielding a lot of "is this safe to install" questions, this is the checklist that catches problems.

1. Verified namespace. io.github.<org>/<repo> or com.<domain>/<name>. Anything else is not in the official registry; you are doing the trust work yourself.
2. Public repository, recent commits. A registry entry pointing at a dead repo is a yellow flag. Open issues from 2024 with no replies is a red flag.
3. License. MIT or Apache 2.0 is the norm for community MCPs. A proprietary license is fine for commercial servers but means the source you are reading is not necessarily what runs.
4. BYOK auth. Look for X-<Provider>-Token or Authorization headers marked isSecret: true in remotes.headers. The README should say "we never store your key" in plain text. Server-side key storage means your data flow now includes a third party you have not audited.
5. Data residency. Where does the hosted server run? Vercel? Cloudflare? A custom VPS? Check the README or privacy page. US firm engagement letters often constrain where covered data is processed; the registry does not surface this, the maintainer should.
6. Last publish date. Older than ~6 months on a fast-moving spec is suspicious. The MCP spec has cut multiple revisions in the last year, and a stale server is probably running an older transport.

None of these are checks the registry does for you. They are checks you do with the registry as your starting point.

The Legal-AI MCPs in the Registry Today

As of June 2026, searching the registry for legal-AI servers returns entries under the io.github.Vaquill-AI/ namespace prefix. The one worth knowing, by what it wraps:

• A commercial statutes and legislation server (vaquill-mcp). BYOK via an API key in the Authorization header. Wraps a public statutes-and-legislation API covering the U.S. Code, CFR, and all 52 state and territory codes.

A commercial server for a paid API. To be precise about scope: the vaquill-mcp server covers statutes and legislation only, not case law or AI answers. For wiring it into an editor, see legal research from inside Cursor and Claude Code.

Other "legal MCP" servers floating on Reddit or LinkedIn are not in the registry. Some are perfectly fine code that just has not been published. Treat that as a gap in the verification story, not a verdict on the code.

What Is Missing from the Registry Today

The gaps tell you where the legal-AI tooling layer is still immature.

• Treatise and secondary-source MCPs. Nothing wraps Westlaw treatises, Practical Law, or any major paid secondary source. Heavily licensed data, and the incumbents have no incentive to ship an MCP.
• PACER and docket-monitoring MCPs. No dedicated PACER monitor or docket-alert MCP is registered. Real product gap for litigation.
• Analytics MCPs. No equivalent of Lex Machina, Trellis, or Premonition. The data engineering is expensive, and the incumbents have web apps that print money.
• Editorial enhancement. Nothing adds headnotes, key numbers, or AI-extracted legal issues on top of raw opinions. This is the layer paid platforms historically charged for, and where the next generation of legal AI will probably compete.

If you are building in any of these spaces, the registry is the place to ship.

The Publishing Flow

For anyone considering publishing a legal-AI MCP, the workflow is boring in a good way:

# In your MCP repo, after editing server.json:
git tag v0.2.0 && git push --tags
# A GitHub Action triggered by the tag runs:
mcp-publisher login github-oidc
mcp-publisher publish
# Verify the registry picked it up:
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.<org>/<repo>"

Bumps take about 60 seconds end to end. The whole thing fits in a 40-line Action. No human review queue.

The validation is mostly schema enforcement: description must be 100 characters or fewer, the namespace must match the OIDC subject, the remotes URL must be HTTPS. Get those three right and you publish.

The 100-character cap is sneakier than it sounds. We tripped over it three separate times on the first server we published; a description that fits comfortably in a README is almost always too long for the registry. Write the registry description first and the README description second.

This is also why the registry feels different from a traditional app store: curation is in the namespace, not in a review process.

Treat the namespace as the trust anchor and the repo as the source of truth, and the model works. Treat the registry as a vetted list of "good" MCPs, and you will get burned by something legitimate-looking pointing at unmaintained code.

A Scanner You Can Run Today

For batch vetting, here is a jq snippet that pulls the trust fields out of any registry search response:

curl -s "https://registry.modelcontextprotocol.io/v0.1/servers?search=legal" \
  | 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: verified name, published version, repo URL, status, last publish timestamp, and a comma-separated list of any secret headers the server requires.

Pipe it through column -t for a one-line audit per entry. Missing fields or deprecated status mean a closer look before recommending.

Attack Surfaces Worth Naming

Trust rests on namespace ownership. Failure modes cluster around spoofing the namespace or compromising the identity behind it.

• Look-alike namespace squatting. Nothing stops someone from registering a GitHub org called Westlaw-Corp or Cour7Listener and shipping a mimic. Mitigation: copy-paste namespaces from the registry, never type from a screenshot, and pin the version in your client config.
• Compromised CI minting an OIDC token. If a publisher's GitHub Actions environment is breached, an attacker can mint a valid token and ship a malicious version under a legitimate namespace. PyPI has seen this pattern. Publishers: protect publish workflows with environment approvals. Users: pin versions and watch the version field.
• DNS TXT propagation gaps. The me.<domain> path verifies the TXT record at publish time. If the domain expires or DNS gets misconfigured later, the registry keeps serving the old listing. Check publishedAt recency before trusting any me.<domain> server.

The registry is now the primary distribution channel, which makes it the primary attack target.

What This Means for Client Intake

For solo or small firms, this changes a few vendor-checklist items. Add an "MCP namespace check" to your security intake: any AI tool using MCP should list its exact namespaces, and they should resolve in the official registry.

Require BYOK for any hosted MCP touching client matter data. Write the credential lifecycle into your engagement letter. If the letter constrains data residency, the registry will not tell you where a server runs; ask the maintainer in writing.

What to Do With This

Practitioners: bookmark registry.modelcontextprotocol.io, learn the verified-namespace pattern, and stop installing MCPs from anywhere else without an explicit reason.

Developers: publish your servers there, even at 0.1.0. Verified namespace is now a default expectation in client tools.

The registry is not perfect. No security scanner, no editorial review, trust rests entirely on namespace ownership. Compared to the "trust me, paste this URL" era it replaced, it is the single biggest improvement in MCP distribution hygiene of the last year.

FAQ

What is the MCP registry?

The MCP registry is the official directory of Model Context Protocol servers at registry.modelcontextprotocol.io. It hosts metadata (not code) so AI clients and marketplaces can discover servers and verify who published each one. Anthropic runs it with GitHub, PulseMCP, and Microsoft, 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 you publish once. The GitHub MCP Registry (announced September 16, 2025) is a downstream aggregator that reads from it and adds a browse-and-install interface. Publish to the community registry and you surface in both.

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". You get JSON for every matching server, including its verified name, repository, version, and status. Filter for verified namespaces (io.github. or com.) and skip anything with deprecated status.

How do I publish my MCP server to the registry?

Install the mcp-publisher CLI, add an mcpName field to your package, run mcp-publisher login github (or github-oidc inside GitHub Actions), then mcp-publisher publish. The whole flow is schema validation plus namespace auth, no human review queue. See the official quickstart.

Is the MCP server registry free?

Yes. Publishing to and reading from the official registry is free. The registry only hosts metadata; you still publish your actual package to npm, PyPI, or Docker Hub, or host a remote server yourself.

What legal AI MCP servers are in the registry today?

As of June 2026, the legal-AI servers sit under one namespace prefix, io.github.Vaquill-AI/: a commercial statutes-and-legislation server covering the US Code, CFR, and all 52 state and territory codes. Other "legal MCP" projects exist on GitHub or npm but are not published to the official registry yet.

How does the registry verify a legal MCP server is legitimate?

It verifies the namespace, not the code. io.github.<org>/ proves the named GitHub org authenticated and published the server; com.<domain>/ proves control of that domain via a DNS TXT record. It does not scan the code, audit data handling, or check compliance, so vendor diligence is still on you.

One soft CTA: if you want a verified legal-AI MCP server in the registry to start from, see Vaquill AI's MCP page, or email contact@vaquill.ai.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.