Flagbearer

Turn a flag on or off

set_flag

Idempotent

Turn a flag on or off in one environment, by flag key and environment key. When turning a flag on, rolloutPercent says who gets it: 100 for everyone, or a percentage of users. Ask the user whether it should be on for everyone. Without rolloutPercent it's 0, which turns it on only for the environment's testers. Changing production needs confirmProduction: true. Only send that after the user has confirmed the change.

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": {
      "applicationId": "<applicationId>",
      "flagKey": "<flagKey>",
      "environment": "<environment>",
      "enabled": "<enabled>"
    },
    "name": "set_flag"
  }
}

Input Schema

Name	Required	Description	Default
`enabled`	Yes
`flagKey`	Yes
`environment`	Yes
`applicationId`	Yes
`rolloutPercent`	No
`confirmProduction`	No

Output Schema

Name	Required	Description	Default
`enabled`	Yes
`flagKey`	Yes
`environment`	Yes
`rolloutPercent`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only supply idempotentHint, so the description carries most of the burden and does well: it discloses the rolloutPercent default of 0 (testers only), the 100-means-everyone semantics, and the production confirmation gate. It stops short of saying what happens to an existing rollout when the flag is turned off, and says nothing about permissions.

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 core action, then escalated to the risky case (rollout percentage, then production confirmation). Every sentence carries information, though the on/off phrasing is restated once more than strictly necessary.

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?

An output schema exists and the safety-critical mutation semantics are covered, so an agent can call this correctly for the common cases. Minor gaps remain around failure behavior when the flag or environment key does not exist, and around what 'off' does to a previously set rollout.

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 description coverage is 0% across six parameters, so the description must compensate. It does this well for the two non-obvious parameters, rolloutPercent and confirmProduction, but leaves applicationId, flagKey, environment and enabled to be inferred from their names and patterns.

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?

Names a specific verb (turn on/off), a specific resource (a flag), and a scope (one environment, addressed by flag key and environment key). This cleanly separates it from create_flag, list_flags and get_user_flags without needing to name them.

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 operating instructions: ask the user whether it should be on for everyone, and require confirmProduction only after the user has confirmed a production change. The when-to-use-safely conditions are stated rather than left to inference.

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

All Flagbearer tools Inspect

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.