Skip to main content
Glama
canopy-labs

Featureflip

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_projectsA

List projects in the Featureflip organization. Paginated: pass cursor from next_cursor to continue.

list_environmentsA

List the environments of a project (e.g. development, staging, production).

list_segmentsA

List reusable user segments in a project. Segments are referenced from targeting rules via userSegmentId.

get_segmentA

Get one user segment (its conditions, id, and metadata) by key or id.

list_flagsA

List feature flags in a project. Filter with search (key/name substring), tag, type, archived. Paginated via cursor.

get_flagA

Get one feature flag with its variations and metadata. Address by flag key or id.

create_flagA

Create a feature flag. type is one of Boolean|String|Number|Json. Boolean flags get true/false variations automatically; for other types pass initialVariations. The flag is created in every environment of the project (disabled).

update_flagA

Update flag name/description/tags/clientSideVisible. Key and type are immutable. Use toggle_flag / update_targeting for behavior changes.

delete_flagA

PERMANENTLY delete a flag across all environments. Fails with FLAG_HAS_DEPENDENTS if other flags use it as a prerequisite. Prefer archive_flag unless the flag must be fully removed.

archive_flagA

Archive a flag (soft-hide, evaluation stops serving it). Reversible with restore_flag. 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.

restore_flagB

Restore a previously archived flag.

toggle_flagA

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

update_flag_environment_configA

Update a flag's per-environment serving config: defaultVariationId (served on fallthrough, required), strategy (SingleVariation | PercentageRollout | TargetedRollout — only SingleVariation is currently supported at the environment level), and prerequisites. Percentage rollouts are configured on targeting rules via update_targeting.

flag_statusB

Compact cross-environment view of one flag: enabled state, strategy, default variation, and prerequisites per environment.

get_targetingA

Get a flag's current targeting configuration (enabled flag + ordered rules) in one environment.

update_targetingA

REPLACE all targeting rules of a flag in one environment (full PUT — rules not included are removed). Rules are evaluated in order. Get the current rules first with get_targeting.

manage_variationA

Manage a flag's variations. action=add requires key + value; action=update/remove require variationId (get ids via get_flag). Removing a variation fails with VARIATION_HAS_DEPENDENTS if other flags depend on it.

find_stale_flagsA

Find flags that look ready for code cleanup: not updated in N days AND either enabled in every environment (verify rollout is complete before removing — per-rule percentage ramps are not inspected) or disabled in every environment (dead — remove flag and code path). Checks at most 50 candidates per call.

wrap_featureA

Create a Boolean feature flag and get back the SDK code snippet to guard the new code path with it. Returns the snippet only — apply the edit yourself. The flag starts DISABLED in every environment; enable it with toggle_flag when ready.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 19 tools

Disambiguation4/5

Most tools pair a specific verb with a distinct resource (flags, targeting, variations, segments), so agent selection is generally clear. A few boundaries require care — update_flag_environment_config vs update_targeting, and get_targeting vs flag_status — but the descriptions draw meaningful lines.

Naming Consistency4/5

Tool names consistently use snake_case verb_noun patterns like list_flags, get_targeting, and archive_flag. Minor deviations such as flag_status and the generic manage_variation are understandable but break the otherwise uniform pattern.

Tool Count4/5

Nineteen tools is heavier than the typical well-scoped server but each tool covers a concrete operation in the feature-flag lifecycle. The count is justified by the broad domain (flags, environments, targeting, variations, segments, cleanup workflows), though it is slightly over the ideal range.

Completeness4/5

Flag CRUD, archiving, restoring, targeting, toggling, variation management, and stale-flag cleanup form a complete workflow with no dead ends. Notable read-only edges exist (segments and environments cannot be created or modified), but these appear to be out of scope rather than fatal gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues