Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Create, update, rotate, or delete a flag trigger

manage_flag_trigger

Destructive

Instructions

Manage a flag's triggers in one environment. A trigger is a secret URL a monitoring tool POSTs to (no body) to turn the flag on (Enable) or off (Disable); calling it when the flag is already in that state changes nothing. action=create needs name + triggerAction and returns the URL ONCE. action=update needs trigger and changes only the fields you pass (name, description, enabled; enabled=false stops the URL working until re-enabled). action=rotate needs trigger: the old URL stops working at once and the new one is returned ONCE. action=delete needs trigger. The action (Enable/Disable) is fixed at creation. Creating, re-enabling and rotating need the Team plan or above; every write needs a Member token; at most 10 per flag per environment. To change the flag yourself, use toggle_flag instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "project": "<project>",
      "flag": "<flag>",
      "environment": "<environment>"
    },
    "name": "manage_flag_trigger"
  }
}

Input Schema

Name	Required	Description
`flag`	Yes	Flag key or id
`name`	No	Trigger name, e.g. "Grafana: checkout error rate"; required for create
`action`	Yes	create needs name + triggerAction; update, rotate and delete need trigger
`reason`	No	Why you are making this change. Recorded in the audit log, and required when the environment (or, for project-wide changes, any environment in the project) is marked critical.
`enabled`	No	update only: false stops the URL working, true turns it back on
`project`	Yes	Project key
`trigger`	No	Trigger id (see list_flag_triggers); required for update, rotate and delete
`description`	No	What calls the trigger and why; "" clears it
`environment`	Yes	Environment key, e.g. production
`triggerAction`	No	Required for create: Disable turns the flag off (a kill switch), Enable turns it on
`idempotency_key`	No	Idempotency-Key header for create

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.9.0Nov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The only annotation is destructiveHint=true, so the description carries most of the burden and does so thoroughly: rotate kills the old URL immediately, enabled=false disables the URL until re-enabled, the URL is returned only once on create and rotate, and the Enable/Disable action is immutable after creation. Plan, token and per-flag-count limits are disclosed beyond anything structured data provides.

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-loads the purpose, then segments behavior by "action=..." prefixes, which makes it scannable despite covering four operations. It is dense (plan/token/limit caveats appended as a block) but nearly every clause carries operational weight; only the trailing limits sentence feels somewhat stacked.

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?

For an 11-parameter, four-mode mutation tool this covers what an agent needs: mode requirements, side effects, irreversibility of rotate, one-time secret return, and prerequisites. An output schema exists, so return-value detail beyond "the URL is returned once" is correctly omitted.

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 100%, so baseline is 3; the description still adds cross-field meaning the schema only implies — which parameters each action consumes and that update changes only the fields passed. It also explains the consequence of enabled=false and the one-time visibility of the returned URL, which is behavioral meaning not captured in the parameter docs.

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?

Opens with a specific verb+resource ("Manage a flag's triggers in one environment") and then defines the resource itself: a secret URL a monitoring tool POSTs to with no body. The four supported actions (create/update/rotate/delete) are enumerated, so an agent can tell this apart from toggle_flag, list_flag_triggers and delete_flag without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit routing guidance: "To change the flag yourself, use toggle_flag instead," which names the alternative and the condition that selects it. It also states per-action prerequisites (create needs name + triggerAction; update/rotate/delete need trigger) and eligibility constraints (Team plan for create/re-enable/rotate, Member token for every write, max 10 per flag per environment).

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