Skip to content

Releases: EaseHee/rhino-mcp

v0.6.0

Choose a tag to compare

@github-actions github-actions released this 20 May 17:13

v0.5.1

Choose a tag to compare

@github-actions github-actions released this 10 May 05:19

v0.5.0

Choose a tag to compare

@github-actions github-actions released this 06 May 16:38

v0.4.1

Choose a tag to compare

@github-actions github-actions released this 04 May 17:24
feat: v0.4.1 — Installation by Rhino command `_McpInstall`

inside Rhino: install the YAK package once, type
`_McpInstall` on the command line, and the C# plugin bootstraps the
PyPI distribution and writes the Claude Desktop config without ever
opening a terminal.

Implementation
--------------

`rhino_plugin/csharp/Commands/McpInstallCommand.cs` adds a
`Rhino.Commands.Command` subclass with `EnglishName = "McpInstall"`.
Rhino's plugin loader picks it up automatically through assembly
scanning, so no extra registration in `Plugin.cs` is required.

The command:

* Resolves a launcher in priority order — `uvx` first (ephemeral
  install of `rhino3dm-mcp`, no permanent footprint), an installed
  `rhino-mcp` console script next, then a system `python` /
  `python3` fallback that runs `python -m rhino_mcp.server install`.
* On macOS extends the search beyond the inherited GUI-app `PATH`
  with `~/.local/bin`, `~/.cargo/bin`, `/opt/homebrew/bin`, and
  `/usr/local/bin`, since Rhino is launched from Finder/Dock and
  rarely sees the user's shell `PATH`.
* On Windows tries common `.exe` / `.cmd` / `.bat` extensions on top
  of bare names so `where`-style probing works.
* Runs non-interactively. The MCP server is always registered with
  `--mode auto`, so Claude Desktop attaches to the bridge when Rhino
  is running and falls back to standalone (rhino3dm) when Rhino is
  closed. Rhino-design users are never asked about
  "standalone" / "bridge" terminology — both terms are MCP-internal
  vocabulary that does not belong on a Rhino command line.
* Spawns the launcher through `Process.Start` with redirected stdout
  / stderr and streams every line into Rhino's command window via
  `RhinoApp.WriteLine`, prefixed with `[rhino-mcp]`.
* Falls back gracefully when no launcher is found: prints the canonical
  `pip install rhino3dm-mcp && rhino-mcp install` recipe plus the
  `uv` install URL, then returns `Result.Failure` so the user sees the
  red command-line outcome.

Internal helpers (`Launcher`, `LauncherKind`, `LauncherResolver`,
`ProcessRunner`, `McpInstallConstants`) are kept `internal` so they do
not leak into the plugin's public surface.

Version sync
------------

Every version-bearing file is moved from `0.4.0` to `0.4.1` in lock
step:

* `pyproject.toml`
* `src/rhino_mcp/__init__.py`
* `rhino_plugin/csharp/manifest.yml`
* `rhino_plugin/csharp/RhinoMCPPlugin.csproj` — note: this `<Version>`
  was lagging at `0.3.1` and is brought into the matrix here.
* `rhino_plugin/csharp/yak-stage/{win,mac}/manifest.yml`
* `uv.lock`

Docs
----

`README.md`, `README.ko.md`, and `CHANGELOG.md` gain a `[0.4.1]`
section describing the new Rhino command and the version sync, in
both English and Korean.

Verification
------------

* `dotnet build rhino_plugin/csharp -c Release` — 0 errors / 0
  warnings.
* `uv run pytest tests/ -q` — 237 passed (the new command is C#
  only; existing Python install-flow tests remain green).
* `uv build` — `dist/rhino3dm_mcp-0.4.1-py3-none-any.whl`.

Operational notes
-----------------

Tagging `v0.4.1` triggers the existing release workflow:

1. `build-python` publishes the wheel + sdist to PyPI through Trusted
   Publishing.
2. `build-rhp` produces the new `rhino-mcp.rhp` (now containing the
   `_McpInstall` command) and attaches it to the GitHub Release.
3. `build-yak` packages the per-platform `.yak` files when the
   Windows runner has the Yak CLI available.

v0.4.0

Choose a tag to compare

@github-actions github-actions released this 04 May 16:52
feat: v0.4.0 — packaging pipeline and rhino3dm-mcp PyPI debut

YAK packaging pipeline
----------------------

`scripts/publish-yak.sh` is added so that the C# bridge plugin ships as
a Yak package alongside the raw `.rhp`. The script stages the built
plugin under `rhino_plugin/csharp/yak-stage/{win,mac}/` together with a
platform-specific `manifest.yml` and the shared `rhino-mcp.png` icon,
then drives `yak.exe build` to produce the `.yak` file. The release
workflow gains a `build-yak` job that runs the script on a Windows
runner with the Rhino 8 Yak CLI when present and attaches the
`.yak` files to the GitHub Release.

Version sync and docs
---------------------

`pyproject.toml`, `src/rhino_mcp/__init__.py`,
`rhino_plugin/csharp/manifest.yml`, and the staged
`rhino_plugin/csharp/yak-stage/{win,mac}/manifest.yml` are all bumped
to `0.4.0` together so that the YAK package and the PyPI wheel ship as
a matched pair. `pip install` / `uvx` snippets in `README.md`,
`README.ko.md`, and `docs/{en,ko}/{installation,configuration}.md`
swap to the new distribution name; the `rhino-mcp` CLI command stays.
The legacy `assets/rhino-logo.png` is replaced with
`assets/rhino-mcp.png` so the README header and the YAK plugin icon
share one asset. `CHANGELOG.md` gains a `[0.4.0]` entry covering
the packaging pipeline and the PyPI rename in both English and
Korean.

One-shot Claude Desktop wiring
------------------------------

A new `rhino-mcp install` sub-command writes (or updates) the
`mcpServers.rhino-mcp` entry inside `claude_desktop_config.json` so
end users no longer have to edit the JSON by hand after `pip install`.
The command auto-detects the platform-specific config path on macOS,
Windows, and Linux, preserves any other registered MCP servers, writes
a timestamped `.bak.*` copy of the previous file, and is idempotent on
re-run. Flags: `--mode {auto,standalone,bridge}`,
`--transport {stdio,http}`, `--name`, `--launcher
{auto,uvx,rhino-mcp,python}`, `--config-path`, `--force`,
`--no-backup`, `--dry-run`. The implementation lives in
`src/rhino_mcp/install.py` and is wired into `server.py` as an argparse
sub-command so existing invocations like `uvx rhino3dm-mcp` (no
sub-command) still launch the server unchanged.

Operational notes (one-time)
----------------------------

* PyPI Pending Publisher needs to be re-created with project name
  `rhino3dm-mcp`, owner `EaseHee`, repository `rhino-mcp`, workflow
  `release.yml`, environment empty.
* Tagging `v0.4.0` triggers PyPI publish (Trusted Publishing) plus
  `.rhp` and `.yak` artefact upload to the GitHub Release.

Verification
------------

* `uv build` — `dist/rhino3dm_mcp-0.4.0-py3-none-any.whl` METADATA
  shows `Name: rhino3dm-mcp`, `Version: 0.4.0`, and entry_points.txt
  lists both `rhino-mcp` and `rhino3dm-mcp` console scripts.
* `uv run pytest tests/ -q` — 237 passed (213 prior + 24 new install
  tests covering OS path detection, idempotent merge, backup creation,
  dry-run, force overwrite, and CLI integration).