Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Set or clear flag expiry

set_flag_expiry

Idempotent

Set or clear the removal date for a feature flag so stale flags are reported as expired once that date passes. Takes a date or ISO-8601 timestamp, or null to clear.

Instructions

Set the date a flag is expected to be removed by, or pass expiresAtUtc: null to clear it. Expiry is advisory: evaluation never changes. Once the date passes, find_stale_flags reports the flag as expired. expiresAtUtc takes a date (2026-12-31), which means the end of that day in UTC, the same as picking it in the dashboard, or a full ISO-8601 timestamp, which is stored exactly. Refused with EXPIRY_IN_PAST for a time that has already passed (today's date is allowed), with FEATURE_NOT_ENABLED while flag expiration is not enabled for the organization, and with PERMANENT_FLAG_HAS_EXPIRY on a permanent flag (make it temporary first with set_flag_permanent). Clearing is always allowed.

Input Schema

Name	Required	Description
`flag`	Yes	Flag key or id
`project`	Yes	Project key
`expiresAtUtc`	Yes	Date (YYYY-MM-DD, end of that UTC day) or ISO-8601 timestamp, or null to clear the expiry

Output Schema

Name	Required	Description	Default
`flag`	Yes
`project`	Yes
`expiresAtUtc`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.0Oct 18, 2026

addedInput schema / properties / project / description
```
Added value: +"Project key"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "expiresAtUtc": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "flag": {
+      "type": "string"
+    },
+    "project": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "project",
+    "flag",
+    "expiresAtUtc"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.1.9Oct 1, 2026

changedInput schema / properties / expiresAtUtc / description

Previous value: -"ISO-8601 UTC instant, or null to clear the expiry"New value: +"Date (YYYY-MM-DD, end of that UTC day) or ISO-8601 timestamp, or null to clear the expiry"

Addedv0.1.8Sep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the idempotentHint/destructiveHint annotations: expiry is advisory and never changes evaluation, find_stale_flags surfaces it once passed, and three named refusal codes (EXPIRY_IN_PAST, FEATURE_NOT_ENABLED, PERMANENT_FLAG_HAS_EXPIRY) are documented. Clearing-always-allowed is a genuinely useful behavioral guarantee.

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?

Front-loads the core action and the null-clearing alternative, then layers semantics and error conditions in a tight sequence. Dense but every sentence carries operational information; nothing is padding.

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?

With an output schema present, return values need no explanation, and the description covers formats, failure modes, and the interaction with set_flag_permanent. Nothing an agent needs to call this correctly is missing.

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 coverage is already 100%, but the description adds meaning: a bare date resolves to end-of-day UTC (matching the dashboard), while a full ISO-8601 timestamp is stored exactly. This disambiguates the two accepted formats beyond the schema's terser note.

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 precise verb+resource ('Set the date a flag is expected to be removed by'), plus the clearing variant via null. It is clearly distinguishable from siblings like set_flag_permanent and set_default_flag_lifetime because it names the exact field (expiresAtUtc) and scope (this flag).

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?

Explains the two modes (set vs. clear with null) and routing conditions, including that a permanent flag must first be made temporary with set_flag_permanent. It does not explicitly say when to prefer this over set_default_flag_lifetime, but the context is clear enough for correct selection.

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