SchemaStore: the shared JSON schema catalog, and what the MCP endpoint changes

What SchemaStore actually is, and what it is not

SchemaStore is a catalog. The README describes it as "a universal JSON schema store, where schemas for popular JSON documents can be found", and the package description is simply "A collection of JSON Schemas". That distinction matters because most people arrive expecting a validator. There is no service that takes your file and tells you it is wrong. What exists is a set of schema documents, each describing the shape of some well-known configuration file, plus the tooling in this repository that checks those schemas are well formed.

The audience is narrower than the tagline suggests. It is for people whose editors or AI assistants already know how to look up a schema by filename or by a $schema URL. If you write a tsconfig.json, a package.json, a Kubernetes manifest or a GitHub Actions workflow, the schema probably exists here and your editor probably already fetches it. If you are building a service that validates customer payloads at runtime, this is the wrong layer entirely: you want a validator library and schemas you control.

The repository is public, licensed Apache-2.0, and the package.json marks it private with version 1.0.0, which tells you it is not published to npm as a consumable library. You clone it or you fetch individual schemas over HTTP. There is no release artifact.

How the catalog is structured and how clients resolve a schema

The repository layout is small and readable. Top-level entries include cli.js, a config/ directory, scripts/, src/, and a SchemaStore.sln solution file. The presence of both a JavaScript entry point and a .NET solution file reflects that the catalog is consumed by more than one ecosystem's tooling. Schema files themselves live in the catalog and are validated by the project's own scripts rather than by a running server.

The devDependencies list is the clearest statement of how validation is done. It includes ajv, ajv-draft-04, ajv-formats, ajv-keywords, ajv-formats-draft2019 published under the @hyperupcall scope, and @exodus/schemasafe. Having both draft-04 and draft-2019 format packages means the catalog spans multiple JSON Schema drafts, and the tooling has to handle each. jsonc-parser and @prantlf/jsonlint appear alongside smol-toml and yaml, so the project lints more than plain JSON: JSON with comments and TOML and YAML inputs are all in scope for the configuration files it tracks.

Resolution, from the consumer side, is by URL. A schema in the catalog is reachable at a schemastore.org address, and editors either hardcode a mapping from filename to schema or follow a $schema key inside the file. Nothing in the README documents a versioning or pinning scheme for those URLs, which is worth knowing: if a schema changes upstream, a client following the URL gets the new one on the next fetch.

Installing SchemaStore: clone the repo or use the hosted MCP server

There are two distinct things you might install. The catalog repository is a Node project with engines set to node >=18, so clone it and run the scripts with npm. The scripts in package.json are prettier, prettier:fix, typecheck, eslint and eslint:fix, which is the full extent of what this repository runs. There is no build step and no test runner listed.

git clone https://github.com/schemastore/SchemaStore
cd SchemaStore
npm install
npm run typecheck

The typecheck script runs tsc against jsconfig.json. If it exits cleanly, the repository's own JavaScript is consistent with its declared types. If you were expecting a command that validates every schema in the catalog, package.json does not list one.

The second thing you can install is nothing at all. The MCP server is hosted, and the README states it plainly: "The server is publicly hosted at https://mcp.schemastore.org, no local setup required." For VS Code, create .vscode/mcp.json in your workspace with the server entry the README gives:

{
  "servers": {
    "SchemaStore": {
      "url": "https://mcp.schemastore.org/",
      "type": "http"
    }
  }
}

After saving, the SchemaStore server should appear in your MCP server list and your assistant can search and retrieve schemas from the catalog. For Visual Studio, the README uses a .mcp.json file at the solution root instead, with the same url and type plus empty inputs and headers objects. Any other MCP client just needs the URL and HTTP transport.

The MCP endpoint is the newest surface, and the least documented

The MCP server is a separate repository, SchemaStore/SchemaStoreMcpServer, linked from the README. The README of the main catalog says the server lets "AI assistants and editors to search, browse, and retrieve JSON schemas from the catalog". That is a retrieval interface, not a validation interface. An assistant asking the server for a schema gets schema text back; whether the assistant then uses it to check a file is up to the assistant.

This is where I would push back on the framing. Pointing an AI client at a public schema endpoint means the client is now making outbound HTTP requests to a third-party host as part of ordinary editing. The README does not discuss rate limits, caching headers, authentication, or what data the server logs. For a local editor plugin that fetches a schema, that is unremarkable. For an assistant that may query the endpoint repeatedly while reasoning about a file, the operational profile is different and undocumented.

The configuration surface is also thin. The VS Code snippet uses a servers object with url and type; the Visual Studio variant adds inputs and headers as empty containers. headers being present but empty in the documented example suggests the endpoint can accept headers, but the README does not say which ones or what they do. Treat that as an open question rather than a feature.

Where SchemaStore is the wrong tool

The failure mode is expecting validation from a catalog. If you add a $schema reference to a file and your editor does not support schema lookup, nothing happens. No error, no warning, just a URL sitting in your JSON. The catalog has no way to tell you that your client ignored it.

A second case: schemas in a shared catalog describe the common shape of a file, not your project's conventions. A schema for a CI workflow will accept configurations your team has decided against. Catalog schemas enforce structure, not policy. If you need to forbid a field rather than type-check it, you need your own schema, and at that point you are maintaining a schema anyway, so the catalog's value is reduced to whatever subset you did not override.

The third case is drift. Schema URLs are fetched, not pinned, and the README documents no versioning scheme for them. If a schema for a tool you depend on is updated to match a new release of that tool, a client fetching the URL gets the new constraints. Files that passed yesterday can produce warnings today. That is usually correct behavior and occasionally disruptive, and nothing in the repository gives you a way to freeze a schema revision.

Alternatives: vendored schemas and self-hosted registries

The direct alternative is vendoring. Copy the schema you need into your repository, reference it with a relative path, and update it on your own schedule. The difference is control versus coverage: you get a frozen revision and you lose automatic updates when the upstream tool changes its format. Vendoring also means you own the draft version, which matters because the catalog's dependencies show it spans draft-04 through draft-2019 and a client may not support the draft you copied.

The second alternative is running your own schema registry. A registry serves schemas you publish, under your own URLs, with your own availability guarantees and access rules. That is the right shape if you have internal configuration formats, or if you need to know that the endpoint will be up when your CI runs. SchemaStore is volunteer-driven and, as the README notes, funded partly by sponsorship; it makes no availability commitments. If a schema fetch is on your critical path, a registry you operate removes that dependency. The cost is that you now run a service, and you still have to source the schemas for third-party file formats from somewhere.

A third option, for validation specifically, is to skip the catalog entirely and write schemas with a validator library of your choice. That gives you full control over draft, strictness and error messages, at the cost of writing and maintaining every schema yourself.

Licence, maintenance and what upgrading costs you

The repository is Apache-2.0, and there is a NOTICE file at the top level, which is the standard Apache-2.0 pairing. Schemas you copy out of the catalog carry that licence with them, so attribution obligations follow the files. The README does not discuss per-schema licensing, and individual schemas may originate from the projects they describe, so if you vendor a schema into a distributed product, check the provenance of that specific file rather than assuming the repository licence settles it. That is a question for your own legal review, not something this article can answer.

The maintenance picture is mixed. The repository is not archived. No last push date was retrieved, so I cannot state when it was last updated, and the README's sponsorship section says the project is "still volunteer-driven" while infrastructure and maintenance costs "have grown alongside its popularity". That is an honest description of a project with real running costs and no commercial backing.

Upgrade cost is asymmetric. Consumers who fetch schemas by URL pay nothing per upgrade and absorb changes silently. Contributors pay more: package.json pins prettier-plugin-toml at 2.0.3 while most other dependencies use caret ranges, and the pre-commit configuration plus .prettierrc.cjs, eslint.config.js and .codespellrc mean a contribution has to satisfy formatting, linting, spelling and type checks before it lands. If you plan to submit schemas rather than consume them, budget for that toolchain.

Editorial conclusion

Adopt SchemaStore if you want editor or AI-client validation for config files your team already writes, and start by pointing a client at the hosted MCP endpoint rather than vendoring schemas. Do not adopt it if you need a runtime validator inside your own service, or if you cannot accept a schema catalog that is maintained by volunteers and has no published release cadence. Before relying on it, verify three things: whether the schema for your specific file exists in the catalog, which draft it targets, and whether your editor already bundles it so you are not configuring a duplicate. The repository is not archived, but no last push date was retrieved, so check the commit history yourself before assuming recent activity.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository