SchemaStore: The Community JSON Schema Collection for Editors and AI Tools

What SchemaStore Is and Why It Matters

Every configuration file format has its own rules: which keys are allowed, what types they accept, which values are mutually exclusive. Without machine-readable rules, editors can only offer syntax highlighting and basic formatting. With a JSON Schema definition for a format, editors can validate the file, highlight mistakes, and offer context-aware autocomplete suggestions while you type. SchemaStore provides these definitions for hundreds of formats. The README describes it as 'the largest collection of independent JSON schemas in the world' and 'a universal JSON schema store, where schemas for popular JSON documents can be found.' Examples of covered formats visible in the related search data include package.json, tsconfig.json, Kubernetes configuration, and many others. The catalog is served at schemastore.org and consumed automatically by editors that support JSON Schema. JSON Schema is a standard for describing the shape of JSON data using a declarative syntax; editors that implement the JSON Language Server Protocol can use these descriptions to validate documents and generate suggestions as a developer types. The benefit is concrete: a typo in a GitHub Actions workflow key, a wrong type in a tsconfig.json compilerOptions field, or a missing required key in a Kubernetes manifest can be caught before the file is committed or deployed.

How Editors Connect to SchemaStore

VS Code integrates with SchemaStore through its JSON and YAML language server extensions. The extensions fetch schema definitions from schemastore.org and apply them to files whose names or patterns match the schema's target. For a user, this means that opening a tsconfig.json or a GitHub Actions workflow YAML file automatically enables validation and autocomplete without any manual configuration. The RELATED SEARCHES data confirms that 'schemastore vscode' and 'vscode schema store' are common queries, which indicates that many developers discover SchemaStore through the VS Code integration. Neovim users are also a documented audience ('schemastore nvim', 'schemastore neovim' in the search data); nvim-lspconfig and related plugins allow configuring the schema catalog endpoint. The service is available at schemastore.org and serves requests from both humans and automated tooling.

The MCP Server: Using SchemaStore with AI Tools

The README documents an MCP (Model Context Protocol) server for SchemaStore, publicly hosted at https://mcp.schemastore.org. This server lets AI assistants and code editors that support MCP search, browse, and retrieve JSON schemas from the catalog programmatically, without scraping the website. Three configuration examples are provided. For VS Code, create .vscode/mcp.json in your workspace:

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

For Visual Studio, add a .mcp.json file to your solution root with the same URL. For any other MCP client, point it at https://mcp.schemastore.org/ using HTTP transport. The MCP server requires no local setup or authentication.

Contributing a Schema to SchemaStore

The README points to CONTRIBUTING.md for full contribution instructions. The project uses pre-commit CI (visible from the pre-commit.ci badge) to validate contributions automatically. The src/ directory contains the schema files. Schemas must pass validation against the ajv library (versions 4, 6, and 8 are supported, per the devDependencies in package.json), and the project uses eslint-plugin-unicorn and eslint-plugin-promise for JavaScript linting of the cli.js tooling. The package.json scripts include prettier for formatting and a typecheck step using jsconfig.json. Contributing organizations are encouraged in the README to sponsor SchemaStore, with the README noting that 'for-profit organizations are among the biggest beneficiaries' and asking them to consider covering infrastructure costs. The sponsorship link points to github.com/sponsors/SchemaStore. The README asks organizations that use schemas to validate configurations and save engineering time to consider sponsoring, as the project is volunteer-driven while its infrastructure and maintenance costs have grown. This is a relatively unusual call to action for an open-source project, but SchemaStore occupies infrastructure-level position in many development workflows, making it more like a public utility than a typical tool.

Repository Layout and Tooling

The top-level src/ directory holds the JSON schema files. The scripts/ directory contains tooling. The cli.js file at the root is the entry point for the validation CLI. The project is a JavaScript repository (primary language per the pack), with ajv and schemasafe as the primary validators. The devDependencies show support for multiple ajv versions (ajv, ajv-draft-04, ajv-formats, ajv-keywords, ajv-formats-draft2019) and jsonc-parser for handling JSON with comments. The smol-toml and yaml packages indicate schema support extends to TOML and YAML formats, not just JSON. The SchemaStore.sln file at the root is a Visual Studio solution file, confirming that Visual Studio integration is a first-class use case for the project. The .codespellrc file at the root configures spell-checking for schema content; the .editorconfig enforces consistent whitespace. The config/ directory likely holds per-schema configuration for the catalog metadata. The node.js engine requirement is set to 18 or later in the package.json engines field.

What SchemaStore Does Not Cover

SchemaStore covers publicly known configuration formats. It does not support private or organization-specific configuration files: schemas contributed to SchemaStore become public. A team that uses internal configuration formats, custom Kubernetes CRDs, or proprietary tooling cannot add those schemas to SchemaStore without exposing the schema details publicly. For private schemas, a self-hosted schema registry is the appropriate tool. SchemaStore also does not enforce schema adoption: the schemas are suggestions for editors, not validation gates in CI pipelines. If you want schema validation as part of a build or deploy process, you need to integrate a validator (such as ajv) into your own toolchain, using the SchemaStore schemas as input data.

SchemaStore vs a Private Schema Registry

Private schema registries (such as those offered by Confluent for Apache Kafka, or open-source tools like json-schema-registry) are designed for controlled environments where schemas must be versioned, access-controlled, and evolved with backward-compatibility checks. SchemaStore is a public catalog with no version control for individual schema entries and no access control: any contributor can submit a schema for any public format. For an organization that manages a microservices architecture with Avro or Protobuf schemas, a private registry is essential. For a developer who wants editor autocomplete for open-source config files, SchemaStore is the right tool and adding a private registry adds unnecessary complexity. The two tools solve different problems and are not direct alternatives to each other. Teams that use both typically point their IDE to SchemaStore for public formats and to their private registry for internal schemas, with the two sources configured side by side in the editor's schema mapping settings.

Editorial conclusion

SchemaStore is indispensable for anyone editing configuration files in a supported IDE. If your editor already connects to it (VS Code does by default via its JSON and YAML language server extensions), you benefit without any setup. Contributing a schema requires following the CONTRIBUTING.md guidelines and passing the pre-commit CI checks, which run ajv validation against all contributed schemas. Organizations that want to keep configuration validation private or need schemas that the community has not contributed should run their own schema registry instead, as SchemaStore is a public catalog with no private hosting path.

Frequently asked questions

Official sources

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