Skip to content

v3.5.1

Choose a tag to compare

@github-actions github-actions released this 16 Sep 16:29
· 32 commits to main since this release
a32b0a1

What's Changed

Added

  • Outcome-scored task evals (evals/src/tasks, npm run evals:tasks). The tool-selection score counts a hit when an expected tool name appears anywhere in the transcript, so a model that calls many tools scores well: a 3B model reached 15/15 while restarting services on a read request (evals/FINDINGS.md #7). The new suite runs 16 multi-step requests and passes one only when the exact request landed or the exact arguments were sent, the answer carries the fact that was asked for, and nothing else was written, including after a declined confirmation. An ambiguous request ("restart my app") must be answered with a question, and reaching for a bulk restart fails it even when the declined confirmation stops the call. It also counts schema-invalid arguments and invented ids, repeats cases with EVALS_TRIALS, and is not part of npm run evals, so CI cost is unchanged.

Fixed

  • HTTP mode outside the container no longer dies on the first client registration (#417, reported by @artgas1). The OAuth state file defaults to /data/oauth-state.json, a directory that only exists in the image. Run coolify-mcp-http on a workstation without MCP_OAUTH_STATE_FILE and the server started, answered /healthz, accepted the first POST /register with a 201, then exited 1 about 250ms later when the debounced state write threw from a timer. A plain SIGTERM did the same through the shutdown flush. The server now checks at startup that the state file's directory exists or can be created and is writable, and lists the failure with the other reasons it cannot start, naming the path and how to set one; the probe is a real write of the temp file the provider uses, so a stale .tmp left by another user is caught too. A write that fails later, say a volume that goes read-only under a running server, logs one line on the way in and one on the way out, reports "persistence": "degraded" on /healthz in between, and the server keeps serving from memory instead of ending.
  • The eval fixture reported no deployments for any app. The client pages /deployments/applications/{uuid} and reads a { count, deployments } envelope; the fixture matched only the bare path and returned an array, so deployment list_for_app came back empty in every eval.

Upgrading from 3.5

  • Container deployments are unaffected. The image's /data volume passes the new check.
  • One exception: a bind mount the daemon created. ./data:/data on a
    host where Docker made the directory root-owned never worked either, but it
    used to start, go green and die at the first registration. It now refuses to
    start and names the directory. Fix the ownership (the image runs as node,
    uid 1000) rather than the config.
  • A write that fails after boot is visible in two places: one stderr line
    on the transition, and /healthz gains "persistence": "degraded" until a
    write succeeds again. Anything that restarts on health can now see it before
    the restart drops every registration and token.
  • Running coolify-mcp-http outside a container? Set MCP_OAUTH_STATE_FILE
    to a path your user can write, e.g. ./oauth-state.json. Until now that
    omission crashed the server after its first registration; it is now a
    startup error that says so.

📦 View on npm

🖱️ One-click Claude Desktop install: download coolify-mcp.mcpb below and drag it into Settings → Extensions.