spec 1.0 · reference

MCP server

Leji's tooling comes in two ways. The CLI is for you and your CI; the Model Context Protocol (MCP) server is for your agent.

@leji-org/mcp is a local MCP server that wraps the reference SDK. Your agent reads the spec and schemas, validates a context layer on disk, and scores its conformance, with no site fetch and no CLI shell-out.

It runs locally over stdio and makes no network calls at run time, though the first `npx` install fetches the package, and exposes only read-only tools.

Add it to your client

Configure it once and the leji tools appear in every session its scope covers, with no further setup: a user-level registration reaches every project, a project-level one reaches that repository. The client launches leji-mcp on demand.

If you're adopting with the CLI and either Claude Code or Codex is on your PATH, leji init and leji adopt offer to register this server for that host, before handing off to your agent.

The offer is interactive, so a --yes run skips it. What follows is for anyone who skipped the prompt, uses another client, or wants a different scope.

Claude Code

claude mcp add leji --scope user -- npx -y @leji-org/mcp

--scope user installs it once for your user, so the leji tools are available in every project; drop it to limit the server to the current project. Full reference: Claude Code MCP docs.

Codex

codex mcp add leji -- npx -y @leji-org/mcp

Or add an [mcp_servers.leji] table to ~/.codex/config.toml directly. Full reference: Codex MCP docs.

Other clients

Claude Desktop, Cursor, Windsurf, and any other MCP client take the standard config:

{
  "mcpServers": {
    "leji": { "command": "npx", "args": ["-y", "@leji-org/mcp"] }
  }
}

Requires Node.js 22 or newer (npx ships with Node). The first run fetches the package; later runs use the cache. Point each tool at the repository root that holds your leji.json.

Tools

All read-only. Nothing the server exposes can write or change your context layer.

MCP tools the server exposes
Tool	What it returns
`search_spec`	Spec sections matching a query.
`fetch_spec_doc`	One spec document (or the whole spec).
`fetch_schema`	One JSON Schema.
`validate_manifest`	Validate a leji.json supplied inline.
`validate_layer`	Validate the context layer at a path.
`score_conformance`	Claimed vs verified conformance level.
`explain_conformance`	What is verified, and what the next level needs.

Resources

MCP resources the server exposes
URI	What it serves
`leji://spec/full`	The complete specification, one document.
`leji://spec/{id}`	One spec document, e.g. leji://spec/conformance.
`leji://schema/{name}`	One JSON Schema, e.g. leji://schema/context-manifest.
`leji://cli/help`	The leji CLI command and option reference.

Why a server, and not just the CLI?

The CLI already validates and scores a context layer, and the server offers both. It also does what the CLI does not, searching and serving the specification and schemas, and it is a different surface, the one an agent reaches for on its own:

It's self-advertised. Configured once, it shows up in your agent's tool list every session, with descriptions of exactly what it does. Nobody has to tell the agent that Leji exists or where to find the CLI.
It works where a shell doesn't. Many agent environments can't or won't run arbitrary commands. A read-only server that makes no network calls at run time is reachable where leji validate is not.
It serves the spec and schemas directly. Your agent reads them as resources, without a web fetch, and cites them as it works.

Consuming a context layer doesn't need the server: a conformant repository's boot profile already onboards your agent. The server is for the other half, learning Leji and checking a context layer against it.