What is MCP - Model Context Protocol

The modelcontextprotocol.io describes MCP in its fundamental form as “The USB-C for AI Applications”. The Model Context Protocol allows applications to interact with the outer world with a simple plug-and-play architecture, solving the limited context problem that previous models of AI applications faced. The registry is at https://registry.modelcontextprotocol.io/

The architecture consists of 2 components: the MCP Client and the MCP Server. Examples of MCP Clients include Claude Code, VSCode, Cursor, etc., and examples of MCP Servers include Exa AI Search, SafeDep VET MCP, etc.

The Client part was sorted, but the server side was not. Discovering them was tedious, finding the current way of installing was painful, managing the state was difficult, and it was all manual. While most people were already publishing their MCPs in NPM and Docker registries, uniformity was needed. Every Client used to have their own “syntactic sugar” for “Installing MCP,” much like Cursor has here: https://cursor.com/docs/context/mcp/directory.

This is a sample .vscode/mcp.json file as instructed in their docs: https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp/extend-copilot-chat-with-mcp

1
{
2
  "inputs": [
3
    // The "inputs" section defines the inputs required for the MCP server configuration.
4
    {
5
      "type": "promptString"
6
    }
7
  ],
8
  "servers": {
9
    // The "servers" section defines the MCP servers you want to use.
10
    "fetch": {
11
      "command": "uvx",
12
      "args": ["mcp-server-fetch"]
13
    }
14
  }
15
}

A Cursor Install link would look like:

1
cursor://anysphere.cursor-deeplink/mcp/install?name=Vercel&config=eyJ1cmwiOiJodHRwczovL21jcC52ZXJjZWwuY29tIn0

MCP Registry to the rescue

Anthropic released an official MCP registry a few months back, meant to become the holy grail of everything involving discovering MCP servers. They say it’s a “Single source of truth for MCP servers”. Blog post link: https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/

This is actually a kind of meta-registry—a registry that stores metadata and installation instructions while the actual artifacts remain in package registries like NPM, PyPI, Container Registry, etc. It stores basic metadata with the actual installation command for the MCP server so that it becomes easy for Clients to simply run them.

It is an easy way to publish your MCP server for discovery and makes it even easier for Client Maintainers to install and use these servers.

However, it is not polished—seriously and fundamentally—since their primary goal is “to standardize how servers are distributed and discovered, providing a primary source of truth that sub-registries can build upon.”

Consuming MCP Registry Packages

For an MCP Client to use an MCP server from the official registry, it just needs to make an HTTP GET request:

List all versions of a server:

1
curl --request GET \
2
  --url https://registry.modelcontextprotocol.io/v0.1/servers/{server_name}/versions \
3
  --header 'Accept: application/json, application/problem+json'

Getting a specific version of a server:

1
curl --request GET \
2
  --url https://registry.modelcontextprotocol.io/v0.1/servers/{server_name}/versions/{server_version} \
3
  --header 'Accept: application/json, application/problem+json'

Let’s see the response for our own vet MCP server. The server_name will be io.github.safedep/vet-mcp and the version will be 1.12.16.

1
curl -fsSL --request GET   --url https://registry.modelcontextprotocol.io/v0.1/servers/io.github.safedep%2Fvet-mcp/versions/1.12.16   --header 'Accept: application/json, application/problem+json' | jq

Response:

1
{
2
  "server": {
3
    "$schema": "https://static.modelcontextprotocol.io/schemas/2025-10-17/server.schema.json",
4
    "name": "io.github.safedep/vet-mcp",
5
    "description": "Protect your AI agents and IDEs from malicious open-source packages.",
6
    "title": "SafeDep Vet MCP",
7
    "repository": {
8
      "url": "https://github.com/safedep/vet",
9
      "source": "github"
10
    },
11
    "version": "1.12.16",
12
    "websiteUrl": "https://safedep.io",
13
    "icons": [
14
      {
15
        "src": "https://raw.githubusercontent.com/safedep/.github/9275c7d1b59f718d73e47cecd93df92e7bfbea25/assets/logo/safedep-logo-darkshade.svg",
16
        "mimeType": "image/svg+xml",
17
        "sizes": ["48x48", "96x96"],
18
        "theme": "light"
19
      },
20
      {
21
        "src": "https://raw.githubusercontent.com/safedep/.github/9275c7d1b59f718d73e47cecd93df92e7bfbea25/assets/logo/safedep-logo.svg",
22
        "mimeType": "image/svg+xml",
23
        "sizes": ["48x48", "96x96"],
24
        "theme": "dark"
25
      }
26
    ],
27
    "packages": [
28
      {
29
        "registryType": "oci",
30
        "identifier": "ghcr.io/safedep/vet:v1.12.16",
31
        "runtimeHint": "docker",
32
        "transport": {
33
          "type": "stdio"
34
        },
35
        "runtimeArguments": [
36
          {
37
            "type": "named",
38
            "name": "--rm"
39
          },
40
          {
41
            "type": "named",
42
            "name": "-i"
43
          }
44
        ],
45
        "packageArguments": [
46
          {
47
            "value": "-s",
48
            "type": "positional"
49
          },
50
          {
51
            "value": "/tmp/vet-mcp.log",
52
            "type": "named",
53
            "name": "-l"
54
          },
55
          {
56
            "value": "server",
57
            "type": "positional"
58
          },
59
          {
60
            "value": "mcp",
61
            "type": "positional"
62
          }
63
        ]
64
      }
65
    ]
66
  },
67
  "_meta": {
68
    "io.modelcontextprotocol.registry/official": {
69
      "status": "active",
70
      "publishedAt": "2025-12-10T10:58:13.018394Z",
71
      "updatedAt": "2025-12-10T10:58:13.018394Z",
72
      "isLatest": true
73
    }
74
  }
75
}

We see lots of information about the server; the most important bit is packages. The packages section contains the actual artifact available to install and run the server in the client. We can also have multiple packages, and the client has the freedom to choose any.

If we parse the package info, we will end up with:

1
docker run --rm -i ghcr.io/safedep/vet:v1.12.16 -- -s -l /tmp/vet-mcp.log server mcp

The entire API documentation is at: https://registry.modelcontextprotocol.io/docs

Sub Registries

You remember we mentioned that the official MCP registry is not polished? One of the reasons is the amount of unchecked data it has. Since publishing the same MCP server with the same version is allowed, what is happening is people are publishing their MCPs in CIs, causing duplicate entries for the same servers.

We tried to analyze the data in the registry, and to our surprise, for only 1691 unique underlying npm, pypi, etc. packages, there are about 64.7 Million server entries having a one-to-many relationship with 48.5 Million packages.

The number clearly shows how massive and duplicated the meta-registry is.

The servers are published with few authentication mechanisms, like GitHub OIDC or DNS verification for domains, but the issue of typosquatting still exists.

Need for a Vetted Sub registry

The official MCP registry has successfully solved the problem of discovery. The next challenge for the community is to solve the problem of trust. As MCP moves from experimental hobby projects to enterprise AI agents, the existence of a curated, security-first sub-registry will be the deciding factor in its adoption.