Skip to main content
Glama

The Bridge

by dev.thebridge
OverviewDiscussionsAdmin

Delete Feature Flag

delete_feature_flag
Destructive

Permanently delete a feature flag by its KEY. THIS IS IRREVERSIBLE — the flag, its targeting rule, its schedule and its evaluation history are gone, and any app code still calling the key silently falls back to its hard-coded default. There is no undo and no archive. Requires confirmation: pass confirm set to the exact flag key, and only after the user has explicitly asked for the deletion — do not supply it on your own initiative. Prefer toggle_feature_flag to switch a flag off, which is reversible and is what "turn this off" almost always means. To retire a flag properly, remove the code that reads it first, then delete. dryRun: true previews it first — the flag's state, rule and schedule and what deleting it does — without deleting anything or needing confirm. Fails with FLAG_NOT_FOUND when no flag has the given key. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoId of the Bridge app to act on for this call (see list_apps). Omit to use the current app.
keyYesFlag KEY to delete (see list_feature_flags).
dryRunNotrue previews what the deletion would affect and deletes nothing — no confirm needed. Do this first and show the user the result. Needs the same privilege as the deletion itself.
confirmNoRepeat the exact key of the resource being deleted, as confirmation. Required to delete; not needed with dryRun. This is a deliberate safety step — do NOT guess it or copy it from a fuzzy match. If you are not certain, list the resources first and ask the user which one they mean.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint/readOnlyHint/idempotentHint, but the description adds the details an agent actually needs: exactly what is destroyed (rule, schedule, evaluation history), the silent fallback to hard-coded defaults, no undo/no archive, the confirmation contract, and the FLAG_NOT_FOUND failure mode.

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 irreversibility warning, which is the right priority for a destructive tool, and every sentence carries actionable content. It runs long and packs multiple concerns (fallback behavior, integration guide pointer, error code) into one block, so it is dense but slightly over-full.

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 a destructive, no-output-schema tool, the description covers consequences, reversibility, confirmation semantics, dry-run preview, and failure modes — everything an agent needs to call it safely and correctly.

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, but the description adds real meaning: confirm must equal the exact key and must only be supplied after explicit user request (not agent initiative), and dryRun previews without needing confirm. The added constraint on confirm goes beyond the schema text, though per-parameter coverage is otherwise complete.

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 precise verb+resource+scope: 'Permanently delete a feature flag by its KEY.' It clearly distinguishes this from siblings (toggle_feature_flag, update_feature_flag, clear_flag_schedule) by naming the alternative that most callers actually want.

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?

Explicit when-to-use and when-to-prefer-an-alternative: 'Prefer toggle_feature_flag to switch a flag off, which is reversible.' It also prescribes the correct retire sequence (remove consuming code first, then delete) and positions dryRun:true as the required first step.

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

All The Bridge toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources