arcane-cli-mcp

arcane_project_compose

Destructive

Read or safely replace a project's Docker Compose file with a diff-first confirmation flow and secret redaction; review changes before applying and redeploy separately.

Instructions

Read or replace a project's compose file (docker-compose YAML).

Read: pass only project. Returns the current compose file (values that look like secrets are hidden as [REDACTED]). The project's .env is never returned: it holds secrets and is edited in the Arcane UI only. Reference its values from compose as ${VAR}. env_unfilled lists the .env variables that still hold the CHANGE_ME placeholder (names only); the project must not be deployed until it is empty.
Write: pass project and compose (the COMPLETE new file, not a fragment). Without confirm=true nothing changes: the result has needs_confirmation=true and a unified diff. Show the user the diff, and only after they approve it, call again with the same compose and confirm=true.
Writing does not redeploy. Afterwards, with the user's OK, run arcane_run ['projects', 'redeploy', ].
Content containing [REDACTED] is refused, so a hidden value is never written back over the real one.

Examples:

{"project": "immich"} (read)
{"project": "immich", "compose": "services: ...", "env_id": "0"} (returns a diff to approve)
{"project": "immich", "compose": "services: ...", "confirm": true} (after the user approved)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "arcane_project_compose"
  }
}

Input Schema

Name	Required	Description	Default
`env_id`	No
`compose`	No
`confirm`	No
`project`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true, and the description adds substantial context beyond that: secret values are returned as [REDACTED], the .env is never returned, content containing [REDACTED] is refused on write so hidden values can't overwrite real ones, and a write does not redeploy. The confirmation/diff gate is a non-obvious two-call protocol that the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Bulleted, front-loaded structure with the read path before the write path and safety notes inline. The Examples block partly restates the bullets, but it adds concrete invocations; minor redundancy rather than waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description still names the salient return signals (needs_confirmation, unified diff, env_unfilled) that an agent must act on. For a read/write-mixed, destructive tool with four parameters, nothing critical for correct invocation is missing except env_id semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load. It explains `compose` (must be the COMPLETE file, not a fragment) and `confirm` (gates the mutation and returns a diff without it), but `env_id` appears only inside an example with no explanation of its meaning or when to set it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb pair and resource: "Read or replace a project's compose file (docker-compose YAML)." It then immediately splits the two modes into labeled Read/Write sections, so an agent knows exactly what the tool does and how the modes differ without consulting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules: pass only `project` to read, pass `project` and `compose` to write, and the write path will return a diff unless `confirm=true`. It also states the follow-up action (call arcane_run ['projects','redeploy',<project>] after approval) and the precondition that deployment must wait until `env_unfilled` is empty.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server