pyxel-config-core#
Validation and knowledge core for ESA Pyxel configurations — callable as a plain Python library or as an MCP server that any LLM assistant can use as a tool.
It reuses the same source-of-truth artifacts as Pyxel Config Lab: the Pyxel JSON schema, the model-parameter catalogue, and the tutorial library. The browser GUI and this core stay in lockstep because they read the same bundled contract.
What it exposes#
Capability |
Function |
MCP tool |
CLI |
|---|---|---|---|
Validate a config against the schema ( |
|
|
|
Explain: a one-sentence summary and a next step per finding |
|
|
|
Auto-repair a config (rename / re-stage) |
|
|
|
List valid models (optionally per stage) |
|
|
|
Fetch a tutorial |
|
|
|
Search tutorials (the library uses the vector index once one is built and keywords otherwise; the MCP tool uses keywords unless |
|
|
|
Semantic (vector) tutorial search, with a degraded-mode flag |
|
|
|
Model parameters + defaults |
|
|
|
Which Pyxel release the bundle tracks |
|
on every |
|
Three front doors onto one implementation. Whatever the CLI says about a config, the MCP tool says too.
Every input and output is a Pydantic model, so results are structured and
schema-checked on both sides of the boundary. Every verdict carries
pyxel_version, the Pyxel release the bundled schema was generated from, so a
result is never separated from the contract that produced it.
validate_config, explain_config, and autofix all accept either a config
dict or a raw YAML string, so an assistant can pass a user’s pasted
.yaml straight through without parsing it first.
Where to go next#
Installation and the quickstart take a first config from a typo to a valid config in a few minutes.
The command line, the library and the MCP server are the three ways in, onto one implementation.
How validation works says what is checked, and what is deliberately left to Pyxel.
The API reference documents every public function and result type.