Content API

The Registry Content API (/v1/content/) extracts fields from .lore archives on first access and caches them as sidecar files. This is the online read path used by the MCP Server and web UI.

Endpoints

`GET /v1/content/:namespace/:name/:version/manifest`

Returns the parsed manifest.yaml for the package.

Response:


{
  "apiVersion": "lore.io/v1",
  "kind": "Skill",
  "metadata": {
    "namespace": "m1cloud",
    "name": "azure-architect",
    "version": "1.0.0"
  },
  "spec": {
    "title": "Azure Architect",
    "description": "Azure architecture specialist"
  }
}

`GET /v1/content/:namespace/:name/:version/content/:lang`

Returns the rendered content for the specified language.

Query Parameters:

Parameter	Description
`lang`	Language tag (e.g., `en-US`, `pt-BR`). Defaults to `en-US`.

Response: text/markdown — the raw content file.

The Registry always returns neutral markdown. Rendering for specific AI runtimes is done by the MCP Server or CLI, never by the Registry (see ADR-0008).

`GET /v1/content/:namespace/:name/:version/readme`

Returns the README.md for the package.

The Content API never extracts or serves files declared in a package’s spec.include (real files bundled by Scaffold and similar packages) — only manifest.yaml and content/*.md are extracted. Getting spec.include files requires the full archive from GET /v1/packages/:namespace/:name/:version/raw, which requires auth for private packages — the CLI wraps this as lore extract, which is what the instruction file lore pull writes for those packages tells the AI to run.

Caching

The Content API extracts fields from .lore archives on first access. Results are cached as sidecar files alongside the archive in the storage backend. Subsequent requests are served from the sidecar cache without re-extracting.