Skip to main content
Glama
canopy-labs

Featureflip

Official
by canopy-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Archive feature flag

archive_flag
Destructive

Stop serving a feature flag by archiving it, with restore available later. Dependent flags and live evaluations block it first; use force only for unupdatable clients.

Instructions

Archive a flag (soft-hide, evaluation stops serving it). Reversible with restore_flag. Archive dependents first: refused with FLAG_HAS_DEPENDENTS while another live flag lists this one as a prerequisite, so archive those flags (blockedBy in find_stale_flags / list_removal_candidates) first. Refused with FLAG_RECENTLY_EVALUATED while live traffic is still evaluating the flag, because archiving makes every caller fall back to its own hardcoded default — normally that means the code removal has merged but not deployed yet, and the refusal clears itself once it has.

Input Schema

NameRequiredDescriptionDefault
flagYesFlag key or id
forceNoArchive even though traffic is still evaluating the flag. Only for clients that can never be updated (old mobile app versions), where traffic will never drain on its own.
projectYesProject key

Output Schema

NameRequiredDescriptionDefault
flagYes
archivedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / properties / flag / description
      Added value: +"Flag key or id"
    • addedInput schema / properties / project / description
      Added value: +"Project key"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "archived": {
+      "type": "boolean"
+    },
+    "flag": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "flag",
+    "archived"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changedv0.1.7
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Archive even though traffic is still evaluating the flag. Only for clients that can never be updated (old mobile app versions), where traffic will never drain on its own.",
+  "type": "boolean"
+}
  3. First observedv0.1.6

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only carry destructiveHint=true, and the description adds substantial non-obvious behavior: the operation is reversible, it is refused under two named conditions, and archiving causes every caller to fall back to its own hardcoded default. The explanation of why FLAG_RECENTLY_EVALUATED fires and when it self-clears is exactly the kind of context annotations cannot provide.

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?

Front-loaded with the core action and free of filler; every sentence carries error-handling or workflow information. It is delivered as one dense run-on paragraph, so error codes and the dependents workflow are harder to scan than they could be.

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?

Output schema exists so return values need no explanation, and the description still covers the mutation's semantics, reversal, both refusal conditions and their resolution, and the prerequisite-tool workflow. Nothing an agent needs to invoke this correctly in the right order is missing.

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%, so both 'project' and 'flag' plus the 'force' override are already documented in the schema. The description corroborates the 'force' rationale (traffic that will never drain) but adds no syntax or format detail beyond it, so the baseline 3 applies.

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?

States a specific verb (archive) and resource (flag) and immediately defines the semantics with 'soft-hide, evaluation stops serving it', which distinguishes it from delete_flag and restore_flag. An agent can tell exactly what state change this performs.

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?

Gives concrete when-not conditions (FLAG_HAS_DEPENDENTS, FLAG_RECENTLY_EVALUATED) and points to the exact sibling tools to run first (find_stale_flags / list_removal_candidates via blockedBy) and the reversal path (restore_flag). It does not explicitly contrast archive vs delete_flag, which is the one obvious alternative left to inference.

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

Deploy Server

Other Tools