Installation

Nothing is published yet

arcane-mcp has no release yet: no GitHub release, image, package, formula or extension exists, and the commands on these pages fail until the first version is tagged. They are written for that release and work from it on. Until then, build the server from source as Getting started explains.

arcane-mcp is one static Go binary with no runtime dependencies. Every channel below delivers that binary, or a container that wraps it, and the same arcane-mcp command, so the choice is about what you already have on the machine and how you want upgrades to arrive, not about features. Whatever you pick, the server needs two values over stdio: ARCANE_URL and an Arcane API key in ARCANE_API_KEY (see Configuration).

Pick a channel

Channel	What you get	Needs	Upgrade	Platforms
Release binary	The binary from the GitHub release, raw or in an archive	Nothing	Download the newer release	Linux, macOS 13 or later, Windows; amd64 and arm64, plus one macOS binary for both
Homebrew	The release binary, installed by a formula from the jmrplens/tap tap	Homebrew	brew upgrade	macOS 13 or later and Linux; Apple Silicon, Intel, arm64 and x86-64
winget	The release executable as a portable package with an arcane-mcp command	winget	winget upgrade	Windows; x64 and arm64
Docker	A container image on GHCR, also on Docker Hub when it is published there	Docker or a compatible runtime	Pull a newer tag	linux/amd64 and linux/arm64 images
npm	A launcher package plus one platform package carrying the binary	Node.js 18 or later	npm update -g, or a newer version for npx	Linux (glibc and musl), macOS 13 or later, Windows; x64 and arm64
PyPI	A wheel that puts the binary on the environment’s scripts path	Python 3.9 or later (uv or pipx optional)	uv tool upgrade, pipx upgrade or pip install -U	Linux (glibc and musl), macOS 13 or later, Windows; x86-64 and arm64
NuGet	A .NET tool whose command is the binary, one package per runtime identifier	The .NET 10 SDK	dotnet tool update -g, or a newer version for dnx	Linux (glibc and musl), macOS 13 or later, Windows; x64 and arm64
Claude Desktop extension	A .mcpb bundle per operating system, with a settings form	Claude Desktop 0.10.0 or later	Install the newer bundle	macOS 13 or later (Apple Silicon and Intel), Windows (x64), Linux (x86-64 and arm64)
go install	A binary built on your machine from the module	Go 1.27.2	go install again	Wherever Go builds

The server never updates itself

It never checks for updates and never replaces its own binary, on any channel. Upgrades come from whatever installed it: a package manager, a newer image tag, a newer extension, or a fresh download. arcane-mcp --version prints the version, the commit and the build date, so you can always see what you have.

Which one?

• You want the smallest footprint and no runtime. The release binary. Homebrew and winget install the same binary and take care of upgrades.
• Your client already launches servers with npx, uvx or dnx. The npm, PyPI or NuGet package: nothing to install ahead of time.
• You would rather not put anything on the host, or you are deploying for a team. Docker, over stdio for one client or as an HTTP service (see HTTP deployment).
• You use Claude Desktop. The extension: one file, and a settings form that keeps the API key in a field marked sensitive.
• You build your own tools with Go. go install, or a clone and make build as in Getting started.

After installing

Every channel ends at the same place: your MCP client starts arcane-mcp (or the docker, npx, uvx or dnx command that wraps it) with ARCANE_URL and ARCANE_API_KEY in its environment. Each channel page closes with the stdio entry for its command; Client setup has the entry for every client, over stdio and over HTTP.

• Desktop applications do not inherit your shell’s PATH. Where a page says to use the absolute path of the command, it is because a client started from the desktop may not find it otherwise.
• The server also reads a .env file in its working directory, which keeps the key out of the client’s configuration where the client lets you choose that directory. A container does not see it.

Then ask your assistant something like “Which containers are running in Arcane?”. On the default dynamic surface it calls arcane_find_action, then arcane_execute_action with container.list.

How a release reaches every channel

The release binaries, Homebrew, winget, npm, PyPI, NuGet and the Claude Desktop extension carry the binaries GoReleaser built for the release, byte for byte; the container image has a build of its own from the same tag. The release workflow publishes them in this order:

1. The GitHub release is created as a draft with the binaries, the archives, the SBOMs, checksums.txt and its cosign signature, and the Claude Desktop bundles, packed in the same job from the same binaries. Every asset is attested before the draft becomes the release, so a release you can see is never a partial one.
2. The container image, npm, PyPI and NuGet are published afterwards, each by a job of its own. The package jobs take the release binaries, check them against the signed checksums.txt, and only then build and publish.
3. Homebrew gets the new formula for the newest release only (the tap serves one version); winget gets a pull request to microsoft/winget-pkgs for every stable release, merged by Microsoft’s reviewers on their own schedule.
4. The MCP Registry entry, io.github.jmrplens/arcane-mcp, is published once the image, npm, PyPI and NuGet are out. It lists the three per-system extensions by SHA-256, the image by digest, and the npm, PyPI and NuGet packages.

How to check what you downloaded, channel by channel, is under Verifying a release; how each channel is built is on Releasing.