model2data-studio 0.1.0__tar.gz → 0.4.0__tar.gz

model2data_studio-0.4.0/PKG-INFO

@@ -0,0 +1,483 @@
+Metadata-Version: 2.5
+Name: model2data-studio
+Version: 0.4.0
+Summary: Generate a model2data studio project's data from the command line, so CI can rebuild fixtures instead of committing them.
+Project-URL: Homepage, https://www.jbanalytica.com/model2data/
+Project-URL: Studio, https://studio.jbanalytica.com
+Project-URL: Pricing, https://www.jbanalytica.com/model2data/pricing/
+Author: JB Analytica
+License-Expression: MIT
+License-File: LICENSE
+Keywords: dbml,dbt,fixtures,mcp,synthetic data,test data
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Database
+Classifier: Topic :: Software Development :: Testing
+Requires-Python: >=3.10
+Requires-Dist: httpx>=0.27.0
+Requires-Dist: typer>=0.12.0
+Provides-Extra: dev
+Requires-Dist: mcp>=2.0.0; extra == 'dev'
+Requires-Dist: pytest>=8.0.0; extra == 'dev'
+Requires-Dist: ruff>=0.6.0; extra == 'dev'
+Provides-Extra: mcp
+Requires-Dist: mcp>=2.0.0; extra == 'mcp'
+Description-Content-Type: text/markdown
+
+# model2data-studio CLI
+
+Pull a saved [model2data studio](https://studio.jbanalytica.com) project and
+write its data, so a build can regenerate its fixtures instead of carrying a CSV
+that was right once.
+
+The schema is designed in the studio, where a diagram and a preview make it
+worth designing. This is the part that runs afterwards, unattended, from the
+same saved project — so the seeds a test suite runs against are the ones the
+model says they should be, rather than whatever was committed the day someone
+last remembered to export.
+
+It is deliberately thin: no DBML parser, no generator, no schema knowledge. The
+studio's API does all of that; this only knows how to ask, and where to put the
+answer.
+
+## Install
+
+```bash
+pip install model2data-studio          # or run it without installing:
+uvx model2data-studio --help
+```
+
+It needs an API key from a **Pro** account on the studio: see
+[pricing](https://www.jbanalytica.com/model2data/pricing/). The client is MIT
+licensed; the studio it talks to is not open source.
+
+## Configuration
+
+Two environment variables, both overridable by a flag:
+
+| | flag | default |
+| --- | --- | --- |
+| `MODEL2DATA_STUDIO_KEY` | `--key` | required |
+| `MODEL2DATA_STUDIO_URL` | `--url` | `https://studio.jbanalytica.com` |
+
+Create a key in the studio's account menu. The CLI sends it as a bearer token
+and nothing else — it never prints it, and it is the only thing that identifies
+the account, so put it in your CI provider's secrets rather than in a file.
+
+Leave the key's access on **Generate and export**, which is the default and
+covers everything below: reading a project, generating, exporting. A key with
+**Read only** access is refused by `generate` with a 403 saying so. **Generate
+and save** adds writing the project back, which `push`, `project create`, `model push`,
+`metrics push` and `dashboard push` need (`project create` also needs a key that is not
+limited to one project) — for a
+pipeline that pushes a model up rather than pulling data down — and **Full access** adds
+deleting a project and managing its share links, which the CLI never does. A
+key that leaks out of a CI log can only do what it was given.
+
+## Commands
+
+```bash
+model2data-studio projects              # id, name, rows, last edited
+model2data-studio whoami                # the plan behind the key, and what it has used
+
+model2data-studio generate --project <id> --out seeds/
+model2data-studio generate --project <id> --out . --format dbt --adapter duckdb
+
+model2data-studio push --project <id> shop.model2data.yml   # save a model as the project's
+
+model2data-studio project create Shop --model shop.model2data.yml --metrics shop.metrics.yml
+model2data-studio model check shop.model2data.yml           # exits 1 on an error; no key needed
+model2data-studio model push <id> shop.model2data.yml       # replace the model, keep the rest
+model2data-studio model guide                               # how to write one: the model spec
+
+model2data-studio metrics list --project ID            # what each metric computes
+model2data-studio metrics check --project shop.metrics.yml  # exits 1 on an error, for CI
+model2data-studio metrics values --project ID --seed 42 --as-of 2026-10-01
+model2data-studio metrics suggest --project shop.model2data.yml -o shop.metrics.yml
+model2data-studio metrics check shop.metrics.yml --model shop.model2data.yml   # or --project <id>
+model2data-studio metrics push <id> shop.metrics.yml        # replace the metrics file, keep the rest
+model2data-studio metrics guide                             # how to write one: the metrics spec
+
+model2data-studio dashboard pull <id> --out dashboards/       # one <name>.dashboard.yml each
+model2data-studio dashboard push <id> dashboards/*.dashboard.yml
+model2data-studio dashboard check dashboards/*.dashboard.yml --project <id>   # for CI
+```
+
+`generate` takes every setting from the saved project — row counts, per-table
+overrides, seed, locale, name — and each flag overrides one of them:
+
+| | |
+| --- | --- |
+| `--format csv\|dbt` | seed CSVs, or a whole dbt project. dbt export is a Pro feature. |
+| `--rows N` | the default row count for every table |
+| `--rows-for TABLE=N` | one table's count, on top of the project's. Repeatable. |
+| `--seed N` | pin the data. Same seed, same rows, forever. |
+| `--as-of YYYY-MM-DD` | pin the day dates and timestamps are anchored on. Defaults to the project's, then today. |
+| `--locale CODE` | which country's people and addresses to generate |
+| `--business-hours` / `--no-business-hours` | weight timestamps toward weekdays and working hours. Pro. |
+| `--growth N` | relative change in activity across the window, e.g. `0.5` for the end being half again as busy as the start. Pro. |
+| `--seasonality N` | strength of an annual cycle peaking in Q4, `0.0`-`1.0`. Pro. |
+| `--skew N` | how unevenly child rows spread over their parents, `0.0`-`1.0`. Pro. |
+| `--name NAME` | the dbt project's name |
+| `--adapter duckdb\|postgres` | the warehouse the dbt project targets |
+| `--metrics FILE` / `--no-metrics` | the metrics file to send instead of the project's own, or none (the metrics are then the ones the model implies). A dbt export holds `<project>.metrics.yml`, `metric_values.json` and a test per metric under `data-tests/metrics/`. |
+| `--defects PRESET` | break the data on purpose: `clean`, `messy`, `training` or `none`; the archive then holds `defects_report.json` (and, for dbt, `EXPECTED_FAILURES.md`), and the log lists the tests `dbt build` should fail. Defaults to the project's. Pro, bar `training` on a bundled example. |
+| `--force` | replace files already in `--out` |
+| `--check` | compare against `--out` instead of writing to it |
+
+Every run also prints a row count for each table it generated, read back out
+of the CSVs — a quick way to see what actually landed without opening a seed.
+
+**Shaping flags name one field at a time.** `--growth` on its own overrides
+just the growth trend; business hours and seasonality still come from the
+project, the same way `--rows-for orders=9` overrides one table without
+resetting every other one to the base count. Shaping is a Pro feature — a free
+plan's key gets a 402 naming the plan boundary if the project or a flag asks
+for anything but the uniform defaults.
+
+**Pin a seed.** A project without one generates different rows every run, which
+means a diff on every build and no way back to yesterday's data. If the project
+has no seed and you pass no `--seed`, the CLI picks one and prints it, so a run
+that surprised you can at least be reproduced.
+
+**Pin the day too.** Dates and timestamps are generated relative to an anchor
+day, so a seed alone reproduces its rows only for as long as that day is the
+same. The studio pins one whenever a project's seed is on — **Dates as of**, in
+the generation settings — and the CLI reads it back, which is what makes a run
+here reproduce the rows the studio previewed rather than merely yesterday's CLI
+run. `--as-of` overrides it. A project with no day pinned anchors on today — at
+midnight, so every run on the same day agrees — and the CLI prints the day it
+used, the same way it prints a picked seed. A pipeline that `--check`s
+committed fixtures, or that needs a failing build to be reproducible on a
+laptop next week, wants the day pinned one way or the other; with `--seed`, the
+two together name one dataset for good.
+
+**A project written as a model is generated from the model.** A project whose
+text is a model2data model — a `.model2data.yml` document, spec 0.2.0, with a
+top-level `model2data:` version key — is sent to the studio as that text, and
+the studio reads it with the engine's own loader, exactly as `model2data --file`
+would. A model the studio refuses fails the run with every issue at its path in
+the document (`tables.orders.columns.status.generate.weights: ...`). The
+project's settings, and every flag above, still win over the model's own `run:`
+section.
+
+**A DBML project must have been opened in the studio at least once** since the
+studio started saving its parse. Nothing on the server reads DBML into what the
+editor showed — the browser does, and saves the result beside the project — so
+a DBML project with no stored parse has nothing to generate from, and the CLI
+says so rather than failing later.
+
+**`push` saves a model file as the project's text.** The studio checks the model
+first and nothing is saved if it has an error (warnings are printed and do not
+stop it). The project's name, settings and canvas positions are kept; the
+browser's saved parse of the old text is cleared, since the model is read
+as-is from then on. It needs a key with **Generate and save** access. It takes
+a model, not DBML: convert a DBML file with the engine's
+`model2data convert schema.dbml` first.
+
+**`push` saves the metrics file beside the model too.** `shop.metrics.yml` next
+to `shop.model2data.yml` is checked by the studio and saved as the project's
+metrics file, or the file `--metrics` names. Without either — or with
+`--no-metrics` — the project keeps the metrics file it already has. A metrics
+file with an error saves nothing.
+
+**`--check` never writes into `--out`.** It regenerates into a scratch
+directory and diffs it against what is already there, printing what changed,
+what is missing and what is left over, then exits 1 if they differ — so a CI
+job can fail a build whose committed fixtures nobody regenerated after a schema
+change, instead of shipping them stale. Exits 0 and prints `Up to date: N
+files` when they match.
+
+## Metrics
+
+A project's metrics file — `<stem>.metrics.yml` beside `<stem>.model2data.yml`,
+metrics spec 0.1.0 — says what its numbers mean: `revenue` is the sum of
+`orders.total_amount` where the order was paid, shipped or delivered. The studio
+saves one per project (the Metrics tab); in a repository it is the file next to
+the model. Without one, the metrics are the ones the model implies: a sum per
+`measure` column and a row count per fact.
+
+Every `metrics` command takes `--project`: a saved project's id **or** a local file (the id also still works as a plain argument, as it did before 0.2.1): the
+model (`shop.model2data.yml`, or `shop.dbml`), or its metrics file, in which case
+the model beside it is used. A local model's metrics are the `shop.metrics.yml`
+beside it, unless `--metrics FILE` or `--no-metrics` says otherwise. **A local
+file needs no API key**: checking metrics is free, and without a key `values`
+runs on the free plan.
+
+| | |
+| --- | --- |
+| `metrics list --project TARGET` | each metric's name, label, kind, what it computes, its filter and its date column; a metric the model implies rather than the file writes is marked `*` |
+| `metrics check --project TARGET` | every issue as `file:line:column: error: path: message`, the shape a CI log viewer links; exits 1 on an error, 0 on warnings alone |
+| `metrics check FILE.metrics.yml --model FILE` | the same, for a metrics file against a model file (YAML, JSON or DBML), wherever the two live; `--project ID` instead reads it against a saved project's model. Needs no key with `--model` |
+| `metrics push PROJECT_ID FILE.metrics.yml` | checks the file against the project's model, then saves it as the project's metrics file, keeping the model, dashboards and settings; says which metrics were added and removed. Nothing is saved on an error |
+| `metrics guide` | the guide to writing a metrics file, as markdown: the metrics spec, then what the studio adds (no key needed) |
+| `metrics values --project TARGET` | generates the data (the same run `generate` makes with the same arguments) and prints each metric's known value. `--seed`, `--rows` and `--as-of` as for `generate`; `--by-month` adds each month; `--json` prints the values shaped like the export's `metric_values.json` (its `run` and `metrics`; the spec version and rounding note are the export's own) |
+| `metrics suggest --project TARGET` | a metrics file of the metrics the model implies, to start one from: stdout, or `-o FILE` (`--force` to replace one) |
+
+```console
+$ model2data-studio metrics values examples/ecommerce.model2data.yml --seed 42 --as-of 2026-10-01
+ecommerce: seed 42, dates anchored on 2026-10-01, 100 rows a table
+metric               label                     value
+-------------------  ------------------------  -----------------------
+revenue              Revenue                   4,012.30
+orders               Orders                    100
+average_order_value  Average order value       40.12 (exact 40.123)
+cancelled_orders     Cancelled orders          4
+cancellation_rate    Cancellation rate         4.00%
+...
+```
+
+The values are **known answers**: what a correct query over the generated seeds
+returns. A rounded value is followed by its exact one, since that is what the
+query will return. Metric values are Pro, except on a bundled example; on a
+plan without them `values` says so and exits 1.
+
+## Dashboards
+
+A project's dashboards are files, `<name>.dashboard.yml`: the file name is the
+dashboard's name. They name the project's metrics and columns, never a value;
+the studio draws them from the project's generated data. The format is
+model2data's open [dashboard spec](https://github.com/JB-Analytica/model2data/blob/main/model2data/spec/dashboards/README.md) (0.1.0),
+with a JSON Schema at
+`https://www.jbanalytica.com/model2data/spec/dashboards/0.1.0/dashboard.schema.json`
+for editor completion: a file starts with
+
+```yaml
+# yaml-language-server: $schema=https://www.jbanalytica.com/model2data/spec/dashboards/0.1.0/dashboard.schema.json
+model2data-dashboard: 0.1.0
+model: coffee_webshop
+```
+
+This client does not read the files: it moves them to and from the studio, which
+checks them and says what is wrong, by line and column. `dashboard guide` and
+`dashboard check` without `--project` need no key. Since 0.3.0.
+
+| | |
+| --- | --- |
+| `dashboard list PROJECT_ID` | the project's dashboards |
+| `dashboard pull PROJECT_ID` | writes each one into `--out DIR` (the current folder by default); `--name NAME` for just that one. A file there that differs from the studio's is left alone, and nothing is written, unless `--force` |
+| `dashboard push PROJECT_ID FILE...` | creates or replaces each dashboard by file name. Every file is checked first and nothing is saved if one has an error. Needs a key with **Generate and save** access |
+| `dashboard check FILE... [--project ID]` | every error and warning as `file:line:column: error: message`; exits 1 on an error, 0 on warnings alone. With `--project`, names the project lacks are warnings |
+| `dashboard guide [--project ID]` | the guide to writing one, as markdown: the dashboard spec, then what the studio adds; with a project, it ends with the metrics and columns that project offers |
+
+A dashboard file that names something the project does not have is still saved:
+that is a warning, not an error, so a dashboard can be sketched before the
+metric it needs exists.
+
+## Building a project: model, metrics, dashboards
+
+A whole project can be built from files, by a pipeline or an agent, without
+opening the studio: a model (`<stem>.model2data.yml`, model2data's open
+[model spec](https://github.com/JB-Analytica/model2data/blob/main/model2data/spec/README.md),
+or DBML), a metrics file (the
+[metrics spec](https://github.com/JB-Analytica/model2data/blob/main/model2data/spec/metrics/README.md))
+and dashboard files. Each kind has a guide (the spec, served by the studio), a
+check that says where each error is by line and column, and a save that checks
+first and saves nothing on an error. Since 0.4.0.
+
+| | |
+| --- | --- |
+| `project create NAME --model FILE [--metrics FILE]` | checks both, then creates the project (100 rows a table, seed 42, dates anchored on today) and prints its id and studio URL. The plan's project limit applies |
+| `model check FILE` | every error and warning as `file:line:column: error: message`; exits 1 on an error. Needs no key |
+| `model push PROJECT_ID FILE` | checks the model, then saves it as the project's model, keeping its metrics file, dashboards, settings and canvas; says how the tables changed, and whether the project's metrics file still reads against it |
+| `model guide` | the guide to writing a model, as markdown (no key needed) |
+
+DBML is saved as the model document it converts to, so the project generates
+straight away. A save reads the project first and replaces only its own part;
+if the project is saved elsewhere in between, it reads it again once rather
+than writing over that save.
+
+The order of work:
+
+1. `model guide`, write `shop.model2data.yml`, `model check` it until it is clean.
+2. `project create Shop --model shop.model2data.yml`: note the id it prints.
+3. `metrics guide`, write `shop.metrics.yml`, `metrics check shop.metrics.yml --project <id>`.
+4. `metrics push <id> shop.metrics.yml`, then `metrics values --project <id>` to see
+   that the numbers come out as intended.
+5. `dashboard guide --project <id>`, write `sales.dashboard.yml`,
+   `dashboard check sales.dashboard.yml --project <id>`.
+6. `dashboard push <id> sales.dashboard.yml`, and open the URL it prints.
+
+## Regenerating dbt seeds in CI
+
+```yaml
+name: Seeds
+
+on: [push]
+
+jobs:
+  seeds:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v5
+
+      - name: Regenerate the seeds from the model
+        env:
+          MODEL2DATA_STUDIO_KEY: ${{ secrets.MODEL2DATA_STUDIO_KEY }}
+        run: |
+          uvx model2data-studio generate \
+            --project ${{ vars.MODEL2DATA_PROJECT_ID }} \
+            --out seeds/ --force --seed 1 --as-of 2026-01-01
+
+      - name: Build against them
+        run: uv run dbt build --target ci
+```
+
+`--force` because the checkout already holds the last run's files, and `--seed`
+with `--as-of` because a pipeline that regenerates its fixtures should still be
+able to explain a failure — with a pinned seed and a pinned day, a failing build
+is reproducible on a laptop, however long after it ran.
+
+Nothing is committed back: the seeds exist for the length of the job, and the
+model in the studio is the thing under version control. If you would rather
+commit them, add a step that opens a pull request when `git status` comes back
+dirty — that turns a schema change into a reviewable diff of the data it
+produces.
+
+## Failing CI when the committed fixtures are stale
+
+If seeds are committed rather than regenerated on every run, `--check` is the
+step that catches someone editing the schema in the studio and forgetting to
+pull the new fixtures into the repo:
+
+```yaml
+      - name: Check the committed seeds match the model
+        env:
+          MODEL2DATA_STUDIO_KEY: ${{ secrets.MODEL2DATA_STUDIO_KEY }}
+        run: |
+          uvx model2data-studio generate \
+            --project ${{ vars.MODEL2DATA_PROJECT_ID }} \
+            --out seeds/ --seed 1 --as-of 2026-01-01 --check
+```
+
+It never writes into `seeds/` — only into a scratch directory it diffs against
+what's there — so this is safe to run against the checkout as-is, no `--force`
+needed. `--as-of` is what lets the check pass on any day: the committed seeds
+were generated relative to one day, and without it a schema with a date column
+would compare against rows anchored on today and fail at the first midnight.
+
+## The MCP server: generating from an agent instead of a shell
+
+The same account, the same key, the same API — for the editor rather than the
+terminal. The studio is where a schema is *designed*, with a diagram and a
+preview to design it against; the agent in your editor is where the data is
+wanted, and asking it for "two hundred believable orders from my webshop model"
+should not mean pasting DBML into a chat.
+
+```bash
+uvx --from 'model2data-studio[mcp]' model2data-studio mcp   # the SDK is an extra, see below
+```
+
+`uvx` fetches it on first use, so there is nothing to install beforehand. With
+the package installed (`pip install 'model2data-studio[mcp]'`),
+`model2data-studio-mcp` starts the same server. For Claude Code:
+
+```bash
+claude mcp add model2data-studio \
+  --env MODEL2DATA_STUDIO_KEY=m2d_... \
+  -- uvx --from 'model2data-studio[mcp]' model2data-studio mcp
+```
+
+and for anything that reads a JSON config (Claude Desktop, Cursor, Zed):
+
+```json
+{
+  "mcpServers": {
+    "model2data-studio": {
+      "command": "uvx",
+      "args": ["--from", "model2data-studio[mcp]", "model2data-studio", "mcp"],
+      "env": { "MODEL2DATA_STUDIO_KEY": "m2d_..." }
+    }
+  }
+}
+```
+
+`MODEL2DATA_STUDIO_URL` works here too, for a self-hosted studio.
+
+Nineteen tools:
+
+| | |
+| --- | --- |
+| `account` | the plan and its caps, worth reading before asking for a lot of rows |
+| `list_projects` | the ids to pass to everything else |
+| `describe_project` | one project's tables, columns, refs and enums as text, generation hints included, and its metrics |
+| `preview_data` | generate and return the rows themselves, capped at fifty a table |
+| `write_data` | generate and write the files, as `generate --out` does |
+| `list_metrics` | the project's metrics, a line each: what it computes, its filter, its date column |
+| `metric_values` | each metric's known value over a generated run, overall and by month (`seed`, `rows`, `as_of` as for `preview_data`). Pro, bar a bundled example. |
+| `get_model_guide` | how to write a model: the open model spec, then what the studio adds (no key needed) |
+| `check_model` | a model's errors and warnings (YAML, JSON or DBML), each with its line and column, and what it holds (no key needed) |
+| `create_project` | checks a model and, optionally, a metrics file, then creates a project from them; answers with its id and studio URL. Needs a key not limited to one project |
+| `save_model` | checks a model, then makes it a project's model, keeping everything else; says how the tables changed |
+| `get_metrics_guide` | how to write a metrics file: the open metrics spec, then what the studio adds (no key needed) |
+| `check_metrics` | a metrics file's errors and warnings, against a project's model (`project_id`) or a model's text (`model_text`, no key needed), and the metrics it defines |
+| `save_metrics` | checks a metrics file, then makes it a project's, keeping everything else; says which metrics were added and removed |
+| `list_dashboards` | the project's dashboards, by name |
+| `get_dashboard` | one dashboard file's text, to edit and save back |
+| `get_dashboard_guide` | how to write a dashboard file: the open dashboard spec, then what the studio adds (no key needed); with `project_id`, ending with that project's metrics and columns |
+| `check_dashboard` | a dashboard file's errors and warnings, each with its line and column, without saving (no key needed without `project_id`) |
+| `save_dashboard` | checks a dashboard file, then creates or replaces it by name; a file with errors is not saved and the errors come back. Answers with the link to the project |
+
+The server's instructions give an agent the order of work for building a
+project from nothing: `get_model_guide` → write the model → `check_model` →
+`create_project` → `get_metrics_guide` → write the metrics → `check_metrics` →
+`save_metrics` → `metric_values` to sanity-check the numbers →
+`get_dashboard_guide` → write a dashboard → `check_dashboard` →
+`save_dashboard` → the studio URL (and share link) to open. Every check and save
+is the studio's; the tools move text.
+
+`preview_data` is the one worth having. An agent that can *read* generated rows
+can act on them — write an assertion against them, notice that `shipped_at`
+precedes `ordered_at`, spot a column coming out as placeholder sentences. It
+answers with the rows inline and says how many there really are; `write_data` is
+for when it has decided and wants the fixtures on disk.
+
+`metric_values` is its other half: the numbers a correct query over those rows
+returns, one quotable line per metric —
+`revenue (Revenue): 4,012.30 — sum of orders.total_amount where orders.status in
+paid, shipped, delivered; by month (orders.order_date): 2025-10 472.39, …` — so an
+agent writing SQL against the seeds can check its own answer.
+
+All of them go through the same `export.resolve` the CLI's `generate` does, so an agent
+and a pipeline asking for the same project with the same arguments get the same
+rows — including the part where an unpinned project has a seed picked for it and
+is told which one, so the answer can be reproduced afterwards.
+
+The MCP SDK is an optional extra rather than a dependency, on purpose: the
+reason this package is two dependencies is that it installs on CI runners next
+to a build that has nothing to do with the studio, and a runner regenerating
+fixtures does not need an MCP SDK.
+
+## Developing
+
+```bash
+cd cli
+uv sync --extra dev
+uv run pytest
+uv run ruff check .
+```
+
+The tests drive the real Typer app, and the MCP tools through the server's own
+`call_tool`, answering their HTTP with an `httpx.MockTransport` — so there is
+nothing to run and nothing to reach.
+
+## Releasing
+
+Bump `version` in `pyproject.toml`, `__version__` in
+`model2data_studio/__init__.py` and both versions in `server.json` (the release
+workflow refuses a tag that disagrees with any of them), merge, then tag the
+merge commit on `main` and push the tag:
+
+```bash
+git tag cli-v0.4.0 && git push origin cli-v0.4.0
+```
+
+`.github/workflows/release-cli.yml` runs the tests, builds, publishes to PyPI
+through trusted publishing (no token stored anywhere) and then lists the new
+version in the MCP registry.
+
+<!-- mcp-name: io.github.JB-Analytica/model2data-studio -->