proofcut

Overview Schema Source Related Servers Discussions Admin

pack_activate

DestructiveIdempotent

Switch the active pack variant to an already snapshotted variant without re-reading files. Unknown variant names are refused, and the available variants are listed instead.

Instructions

Switch the active pack variant to one already snapshotted by pack_apply.

No file re-read — refuses an unknown variant by name, naming the ones that are actually available, rather than trying to load it here.

Input Schema

TableJSON Schema

Name	Required	Description
`path`	No	The project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
`plan`	No	Resolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it.
`variant`	Yes	Which already-snapshotted variant to switch to. No file is re-read, and an unknown name is refused by listing the ones that are available.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.25.0Sep 16, 2026

removedInput schema / properties / path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / path / description

Added value: +"The project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing."

removedInput schema / properties / path / title
```
Removed value: -"Path"
```

addedInput schema / properties / path / type

Added value: +[
+  "string",
+  "null"
+]

addedInput schema / properties / plan / description

Added value: +"Resolve the whole call and report what it would do, writing nothing. Prefer it over doing the thing and undoing it."

removedInput schema / properties / plan / title
```
Removed value: -"Plan"
```

addedInput schema / properties / variant / description

Added value: +"Which already-snapshotted variant to switch to. No file is re-read, and an unknown name is refused by listing the ones that are available."

removedInput schema / properties / variant / title
```
Removed value: -"Variant"
```

removedInput schema / title

Removed value: -"pack_activateArguments"

First observedv0.24.0Sep 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already signal destructiveness and idempotency; the description adds concrete behavior beyond that: it refuses unknown variant names by listing available ones, and it never re-reads files. This meaningfully supplements the structured hints without contradicting them.

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

Conciseness5/5

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

Two short sentences with the primary action front-loaded and the refusal/no-re-read behavior placed second. No filler or redundant restatement of the schema.

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

Completeness4/5

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

For a mutation tool with strong annotations, an output schema, and fully described parameters, the description covers the essential precondition, the no-re-read guarantee, and the error behavior. It leaves the relationship to pack_status/pack_show implicit, but nothing critical is missing for correct invocation.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already documents path, plan, and variant in detail. The tool description mainly restates variant's 'already snapshotted' constraint, so it adds little over the parameter schema.

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?

The description states a specific action and resource: 'Switch the active pack variant to one already snapshotted by pack_apply.' It also names the relevant sibling, making it easy to distinguish from pack_apply, pack_show, and pack_status.

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

Usage Guidelines4/5

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

The description clarifies the key precondition: the variant must already be snapshotted by pack_apply, and no file re-read is involved. It gives clear context for when the tool applies, though it does not explicitly exclude alternative tools or state when not to use it.

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

Deploy Server