Skip to main content
Glama
canopy-labs

Featureflip

Official

Toggle flag in environment

toggle_flag
Destructive

Enable or disable a feature flag in one environment. Changes affect live evaluation immediately, so verify the target environment before applying the switch.

Instructions

Enable or disable a flag in ONE environment. Affects live evaluation immediately — double-check the environment.

Input Schema

NameRequiredDescriptionDefault
flagYesFlag key or id
enabledYestrue to turn the flag on in this environment, false to turn it off
projectYesProject key
environmentYesEnvironment key, e.g. production

Output Schema

NameRequiredDescriptionDefault
flagYes
enabledYes
projectYes
environmentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / properties / enabled / description
      Added value: +"true to turn the flag on in this environment, false to turn it off"
    • addedInput schema / properties / project / description
      Added value: +"Project key"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "enabled": {
      +      "type": "boolean"
      +    },
      +    "environment": {
      +      "type": "string"
      +    },
      +    "flag": {
      +      "type": "string"
      +    },
      +    "project": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "project",
      +    "flag",
      +    "environment",
      +    "enabled"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.6

TDQS

A4/5.0
Behavior4/5

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

The annotation already declares destructiveHint=true, so the description need only add context. It does so by stating the change affects live evaluation immediately, which is a valuable behavioral trait beyond the annotation and reinforces why the warning matters.

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, front-loading the core action and appending the critical warning. Every sentence earns its place with no filler.

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 annotations and an output schema, the description covers the action and its immediate live-evaluation impact. It lacks a note on prerequisites or whether changes are reversible, but the destructive annotation and output schema fill much of that gap.

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 description coverage is 100%, so the schema documents all four parameters fully. The description adds only the single-environment constraint, which is minor against the schema baseline of 3.

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 verb (enable/disable) and resource (flag in one environment), and flags the scope as a single environment. It is clearly distinguishable from siblings like update_flag or update_flag_environment_config.

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 implies usage for toggling a flag in an environment but gives no explicit when-to-use vs. alternatives such as update_flag or update_flag_environment_config. The caution to double-check the environment is a usage note, not a comparison.

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