archicad-mcp-server 0.5.4__tar.gz

archicad_mcp_server-0.5.4/.gitattributes

@@ -0,0 +1,15 @@
+# Scheme XML is compared byte for byte. tests/schemes/test_xml_io.py asserts
+# that a load/save cycle reproduces tests/fixtures/schemes/sample_scheme.xml
+# exactly, and round_trips_exactly() treats a newline difference as a rewrite
+# it must refuse. If a checkout converted these files to CRLF (Git for Windows
+# installs with core.autocrlf=true by default, and actions/checkout does not
+# override it), the fixture on disk would no longer be the bytes those tests
+# were written against. Pin it so every platform sees the same file.
+*.xml text eol=lf
+
+# Same reasoning for the YAML specs and rule files the suite reads, and for
+# Python sources, so nothing in the tree depends on the checkout's newline
+# policy.
+*.yaml text eol=lf
+*.yml text eol=lf
+*.py text eol=lf

archicad_mcp_server-0.5.4/.github/workflows/publish.yml

@@ -0,0 +1,233 @@
+name: release
+on:
+  push:
+    # Version tags only. A tag is the one signal that says "this exact commit
+    # is 0.1.0", and nothing else in the repository should be able to publish.
+    tags: ["v*"]
+
+# Two privileged things happen here, and this is the whole grant for both.
+# contents creates the release. id-token mints a short-lived OIDC token that
+# PyPI and the MCP registry each accept as proof this run is from this
+# repository, which is why publishing to either needs no stored credential:
+# there is nothing to rotate, nothing to leak, and a token that is worthless
+# minutes later. PyPI matches the token against this file's name, so renaming
+# publish.yml silently ends PyPI publishing until the trusted publisher on
+# pypi.org is re-registered to match. Every other step reads the checkout and
+# writes to the runner.
+permissions:
+  contents: write
+  id-token: write
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    env:
+      # One Python, not test.yml's matrix. The wheel is py3-none-any and the
+      # bundle ships pyproject.toml and uv.lock rather than vendored wheels,
+      # so nothing that gets uploaded depends on the interpreter that built
+      # it. 3.13 is the newer of the two the suite covers, so the release is
+      # still built on a version that is actually tested.
+      UV_PYTHON: "3.13"
+    steps:
+      # The same two pins as test.yml, for the reasons written out there:
+      # checkout follows its major, setup-uv is an exact version because
+      # astral-sh stopped publishing major tags after v7. Move the two
+      # workflows together, so a release is built by the toolchain that
+      # tested the commit rather than a later one nothing has run yet.
+      # persist-credentials defaults to true, which writes this run's
+      # GITHUB_TOKEN into .git/config as an auth header. This job holds
+      # contents: write and then runs code that is not ours (npx fetches the
+      # mcpb packer, uv sync resolves the whole PyPI tree), so that would leave
+      # a write-capable token on disk alongside it. Nothing here pushes over
+      # git: gh release create authenticates through GH_TOKEN instead.
+      - uses: actions/checkout@v7
+        with:
+          persist-credentials: false
+      - uses: astral-sh/setup-uv@v9.0.0
+        with:
+          # Same reason test.yml gives every matrix entry its own key. The
+          # default one is derived from the runner image's default Python, not
+          # from UV_PYTHON, so without a suffix this job would race a test run
+          # for the one key that image hands both of them.
+          cache-suffix: release
+
+      # The gate, before anything is synced, built, or packed. It is the one
+      # failure here whose cost is not a re-run: a tag has already been pushed
+      # by the time this workflow exists, so a mismatch means deleting the tag
+      # and pushing it again, and every second spent before saying so is spent
+      # on work that is going to be thrown away. --no-project because the
+      # check imports nothing outside the standard library.
+      #
+      # $GITHUB_REF_NAME rather than ${{ github.ref_name }}: a tag name is text
+      # somebody chose, and ${{ }} substitution pastes it into the script
+      # before the shell parses it. Through the environment it stays one
+      # argument no matter what it contains.
+      - run: uv run --no-project python scripts/check_release_version.py "$GITHUB_REF_NAME"
+
+      # The version lives in a fourth place that check cannot see: uv.lock
+      # records the project's own version, and the bundle SHIPS uv.lock. Bump
+      # pyproject.toml, manifest.json and the README without re-running
+      # uv lock, and the check above happily says "agree" while the extension
+      # goes out with a lock file that disagrees with its own pyproject, which
+      # makes uv re-resolve on the user's machine at first launch. uv lock
+      # --check is the purpose-built test for exactly that, and is a sub-second
+      # no-op when they agree. It has to run before uv sync, because sync
+      # quietly updates the lock and would erase the evidence.
+      - run: uv lock --check
+
+      # test.yml has already run the full matrix if this commit reached main
+      # the usual way, but a tag can be pushed at any commit, including one
+      # that never did. This is the tripwire for that case, and is deliberately
+      # a single run rather than a second copy of the matrix, which would only
+      # re-prove what main already proved.
+      - run: uv sync
+      - run: uv run pytest -v
+
+      # Wheel and sdist first, because uv build is also what creates dist/ for
+      # the bundle to be written into. dist/ is not in the repository.
+      - run: uv build
+
+      # One bundle per platform, all three cross-built on this one runner. The
+      # bundles are platform-specific because the dependency tree contains
+      # compiled wheels; the build is not, because uv resolves wheels for a
+      # named target platform and the standalone interpreters are plain
+      # downloads. That is what keeps this a single job rather than a runner
+      # matrix, at the cost of the one check a matrix would give for free:
+      # nothing here can execute a Windows bundle, so a release is not proven
+      # until one is installed on Windows. The script validates each generated
+      # manifest before packing it, and pins the mcpb packer for the reason
+      # pins exist here generally: the packer decides the bundle format, so it
+      # is the thing worth holding still between releases.
+      #
+      # Node is whatever the runner image ships, an LTS it keeps current. It
+      # runs the packer; it does not decide anything the packer produces.
+      - run: uv run python scripts/build_bundle.py --target all
+
+      # server.json tells the registry where each bundle is and what it must
+      # hash to, and clients check that hash before they install. Every other
+      # field in it is committed and gated by check_release_version.py, the
+      # same as manifest.json. These cannot be: they are hashes of bundles
+      # built from the very commit that would have to contain them. So they are
+      # stamped at the first moment they are knowable, and the placeholder that
+      # is committed is never what gets published.
+      #
+      # Matched on the filename rather than by position, so that reordering
+      # server.json's packages cannot quietly pair a bundle with another
+      # platform's hash. The check afterwards is what makes that safe to rely
+      # on: a package left holding the placeholder is refused by every client
+      # that checks the hash, and an unstamped entry is the only way that
+      # happens by accident.
+      - run: |
+          version="${GITHUB_REF_NAME#v}"
+          for target in win32 darwin-arm64; do
+            name="archicad-mcp-${version}-${target}.mcpb"
+            sha="$(sha256sum "dist/$name" | cut -d' ' -f1)"
+            jq --arg name "$name" --arg sha "$sha" \
+              '(.packages[] | select(.identifier | endswith($name))).fileSha256 = $sha' \
+              server.json > server.stamped
+            mv server.stamped server.json
+          done
+          if jq -e '[.packages[] | select(.fileSha256 | test("^0{64}$"))] | length > 0' \
+               server.json > /dev/null; then
+            echo "::error::a package in server.json kept its placeholder hash" >&2
+            exit 1
+          fi
+
+      # Anything that is not exactly major.minor.patch is a prerelease,
+      # whichever way it is spelled (v0.2.0rc1, v0.2.0-beta.1). Decided once,
+      # here, because the two steps below need the same answer and a second
+      # copy of this regex would be a second thing to keep in step.
+      - run: |
+          if [[ "${GITHUB_REF_NAME#v}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            echo "PRERELEASE=false" >> "$GITHUB_ENV"
+          else
+            echo "PRERELEASE=true" >> "$GITHUB_ENV"
+          fi
+
+      # gh is preinstalled on the runner and is the same command this would be
+      # by hand, so there is no third-party release action to pin and keep
+      # current. The wheel and sdist go up alongside the bundle as well as to
+      # PyPI, so that a pinned install can name a release asset by URL without
+      # depending on a second service. A prerelease is labelled as one rather
+      # than offered from the releases page as the current version to download.
+      #
+      # Create, or re-upload if the release already exists. The registry publish
+      # below is the last step and the one most likely to fail on its own terms,
+      # since it talks to a service still in preview. When it did, the run could
+      # not simply be re-run: this step had already created the release, and
+      # creating it again is an error, so the recovery the comment below
+      # promises was not actually available. Now it is.
+      - run: |
+          flags=(--generate-notes --title "$GITHUB_REF_NAME")
+          if [[ "$PRERELEASE" == "true" ]]; then
+            flags+=(--prerelease)
+          fi
+          if gh release view "$GITHUB_REF_NAME" > /dev/null 2>&1; then
+            echo "release exists, replacing its assets"
+            gh release upload "$GITHUB_REF_NAME" --clobber \
+              dist/*.mcpb dist/*.whl dist/*.tar.gz
+          else
+            gh release create "$GITHUB_REF_NAME" "${flags[@]}" \
+              dist/*.mcpb dist/*.whl dist/*.tar.gz
+          fi
+        env:
+          GH_TOKEN: ${{ github.token }}
+
+      # The wheel and sdist, and only those: dist/ also holds the bundles by
+      # now, and uv publish would try to upload whatever it is handed. Named
+      # archicad-mcp-server on PyPI because archicad-mcp was already taken
+      # there by an unrelated project; the import package, the extension and
+      # the registry entry all keep the shorter name, so the distribution name
+      # in pyproject.toml is the only place the two differ.
+      #
+      # uv publish does trusted publishing natively over the id-token grant
+      # above, which is what keeps this a plain command rather than a
+      # third-party action to pin, the same reason gh is used for the release.
+      # "always" rather than the default "automatic" so that a run that cannot
+      # get a token fails here with that reason, instead of falling through to
+      # a password prompt that has nothing to read from.
+      #
+      # --check-url is what makes a re-run survivable. PyPI refuses a file it
+      # already holds, and the registry step below is the one most likely to
+      # fail, so without it every registry failure would also be a PyPI
+      # failure on the retry. With it, files already on the index are skipped
+      # and the run proceeds to the step that actually needs re-running.
+      #
+      # Prereleases go up too. PyPI understands them, and pip and uv leave
+      # them alone unless asked, so publishing one hands nobody a release
+      # candidate by default, which is the reason the registry step skips them.
+      - name: Publish to PyPI
+        run: |
+          uv publish --trusted-publishing always \
+            --check-url https://pypi.org/simple/ \
+            dist/*.whl dist/*.tar.gz
+
+      # After the release exists, never before. The registry stores the
+      # bundle's download URL and hands it to clients verbatim, so publishing
+      # while the asset was still uploading would advertise a URL that 404s,
+      # and nothing would tell the registry to look again later.
+      #
+      # Skipped for prereleases. The registry offers one current version per
+      # server, so registering v0.2.0rc1 would hand a release candidate to
+      # everyone who installs from a client's server list.
+      #
+      # Unpinned, unlike the mcpb packer above, and for the opposite reason.
+      # The packer decides the format of a file this repository produces, so
+      # holding it still is what keeps bundles comparable between releases.
+      # mcp-publisher speaks a protocol the registry defines and is still
+      # changing while it is in preview, so the version that works is the one
+      # matching the registry as it is today, not as it was at the last release.
+      #
+      # Last, so that nothing else in the release depends on it. A failure here
+      # leaves the GitHub release intact and correct, which is what every
+      # install path other than the registry uses, and re-running the job
+      # recovers it. What re-running cannot do is correct a publish that
+      # succeeded: the registry refuses a version it already holds ("cannot
+      # publish duplicate version"), so a wrong entry is fixed by releasing the
+      # next patch version, never by pushing this tag again.
+      - name: Publish to the MCP registry
+        if: env.PRERELEASE == 'false'
+        run: |
+          curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher
+          ./mcp-publisher login github-oidc
+          ./mcp-publisher publish

archicad_mcp_server-0.5.4/.github/workflows/test.yml

@@ -0,0 +1,43 @@
+name: test
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  test:
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+        python-version: ["3.12", "3.13"]
+    runs-on: ${{ matrix.os }}
+    env:
+      UV_PYTHON: ${{ matrix.python-version }}
+    steps:
+      # Both pinned to versions that run on Node 24. checkout moved to Node 24
+      # in v5 and setup-uv in v7; the older v4/v5 pair here ran on Node 20,
+      # which the runners now force onto Node 24 anyway while emitting a
+      # deprecation warning on every job.
+      - uses: actions/checkout@v7
+      # Exact version, not a floating major like the line above, because
+      # astral-sh stopped publishing major tags after v7: there is no v8 or v9
+      # to track, so the alternatives are pinning a full version or sitting two
+      # majors behind on v7. Bump this by hand (or let Dependabot do it).
+      - uses: astral-sh/setup-uv@v9.0.0
+        with:
+          # The default cache key carries the runner image's own default Python
+          # (3.14.6 on the macOS image, for instance), not UV_PYTHON, so both
+          # matrix entries for a given OS land on one key and race to reserve
+          # it: one saves and the other warns that another job may be creating
+          # the cache. The suffix gives every entry its own key.
+          cache-suffix: ${{ matrix.python-version }}
+      # Before uv sync, which quietly updates the lock and would erase the
+      # evidence. uv.lock records the project's own version and ships inside
+      # the .mcpb bundle, so a bump that forgot to re-lock is caught here, on
+      # the commit that caused it, rather than at tag time when the fix is to
+      # delete a pushed tag.
+      - run: uv lock --check
+      - run: uv sync
+      - run: uv run pytest -v
+      - run: uv build

archicad_mcp_server-0.5.4/.gitignore

@@ -0,0 +1,23 @@
+.claude/settings.local.json
+__pycache__/
+.venv/
+*.egg-info/
+.pytest_cache/
+.DS_Store
+
+# Real project files used to exercise the server against a live model: survey
+# points, CAD exports, a .pln. They are someone's drawings rather than
+# fixtures, and this repository is public, so they stay on the machine that
+# needs them. Test data that belongs here goes in tests/fixtures/.
+teren/
+
+# Staging tree and cached standalone interpreters for scripts/build_bundle.py.
+# Both are rebuildable from pinned inputs, and the interpreter cache alone is
+# tens of megabytes per target.
+build/
+
+# Isolated worktrees for parallel work, and the subagent-driven-development
+# scratch area (ledgers, task briefs, review packages). Both are working state
+# rebuilt on demand; the git history is the durable record.
+.worktrees/
+.superpowers/

archicad_mcp_server-0.5.4/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Aleš Dolenec
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.