CodeRecoder MCP

Overview Schema Source Related Servers Discussions Admin

Activate Code Backup

activate_project

Enable one project for CodeRecoder MCP, create a verified baseline, and optionally start automatic checkpoints; use storageRoot to keep backups outside the protected project.

Instructions

Activate one project for this MCP process, create a verified baseline, and optionally start automatic checkpoints. Use storageRoot to keep all backup data outside a protected project.

Input Schema

TableJSON Schema

Name	Required	Description
`debounceMs`	No
`maxBackups`	No
`projectName`	No
`projectPath`	Yes	Project directory to protect
`storageRoot`	No	Optional external directory for backup storage
`excludeNames`	No
`autoCheckpoint`	No	Defaults to true
`reconciliationIntervalMs`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`error`	No
`message`	Yes
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv3.1.0Sep 11, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

addedInput schema / properties / autoCheckpoint

Added value: +{
+  "description": "Defaults to true",
+  "type": "boolean"
+}

addedInput schema / properties / debounceMs

Added value: +{
+  "maximum": 60000,
+  "minimum": 100,
+  "type": "integer"
+}

addedInput schema / properties / excludeNames

Added value: +{
+  "items": {
+    "maxLength": 255,
+    "minLength": 1,
+    "pattern": "^[^/\\\\]+$",
+    "type": "string"
+  },
+  "maxItems": 100,
+  "type": "array"
+}

removedInput schema / properties / language

Removed value: -{
-  "description": "Optional programming language (auto-detected if not provided)",
-  "optional": true,
-  "type": "string"
-}

addedInput schema / properties / maxBackups

Added value: +{
+  "maximum": 10000,
+  "minimum": 2,
+  "type": "integer"
+}

removedInput schema / properties / projectName / description
```
Removed value: -"Optional custom name for the project"
```
addedInput schema / properties / projectName / maxLength
```
Added value: +120
```
addedInput schema / properties / projectName / minLength
```
Added value: +1
```
removedInput schema / properties / projectName / optional
```
Removed value: -true
```

changedInput schema / properties / projectPath / description

Previous value: -"Absolute path to the project directory"New value: +"Project directory to protect"

addedInput schema / properties / projectPath / minLength
```
Added value: +1
```

addedInput schema / properties / reconciliationIntervalMs

Added value: +{
+  "maximum": 86400000,
+  "minimum": 1000,
+  "type": "integer"
+}

addedInput schema / properties / storageRoot

Added value: +{
+  "description": "Optional external directory for backup storage",
+  "minLength": 1,
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "error": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "message"
+  ],
+  "type": "object"
+}

First observedv1.1.0Aug 10, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare the safety profile (not read-only, non-destructive, non-idempotent), and the description adds genuinely useful behavior beyond them: activation is scoped to one project per MCP process, a verified baseline is created as a side effect, and auto-checkpoints may begin. It stops short of saying what happens if a different project is already active or how an existing baseline is treated.

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 tight sentences, front-loaded with the core action and its effects, followed by a single conditional tip. No filler, nothing repeated from the schema or annotations.

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

Completeness3/5

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

An output schema exists so return values need not be described, and annotations cover safety, but with half the parameters undocumented and no statement of lifecycle preconditions or interaction with sibling snapshot tools, the definition is only minimally sufficient for an 8-parameter mutation tool.

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

Parameters2/5

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

Schema description coverage is only 38% (3 of 8 parameters), so the description must compensate and largely does not. It clarifies the intent of storageRoot and alludes to autoCheckpoint ('optionally start automatic checkpoints'), but debounceMs, maxBackups, excludeNames, reconciliationIntervalMs, and projectName are never explained in either the schema or the description.

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

Purpose4/5

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

The description gives a specific verb+resource ('Activate one project for this MCP process') and enumerates the concrete side effects: creating a verified baseline and optionally starting automatic checkpoints. It implicitly contrasts with deactivate_project by naming the opposite lifecycle action, though it never explicitly names that sibling.

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

Usage Guidelines3/5

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

It offers one actionable hint ('Use storageRoot to keep all backup data outside a protected project') but does not state when to call this versus create_project_snapshot or deactivate_project, nor what prerequisites (an active project, a protected project) must hold. Usage is implied by the lifecycle framing rather than stated.

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

Deploy Server