Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Compare environments

compare_environments

Read-only

Identify feature flags that differ between two environments and see changed sections: state, default variation, strategy, rules, or prerequisites. Returns only differing flags by default.

Instructions

Compare flag configuration between two environments: which flags differ and in which sections (state, defaultVariation, strategy, rules, prerequisites). Returns only differing flags unless different_only is false. To see exactly what would change for one flag, preview copy_flag_config (Team plan and above, Member role).

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": {
      "project": "<project>",
      "base": "<base>",
      "other": "<other>"
    },
    "name": "compare_environments"
  }
}

Input Schema

Name	Required	Description
`tag`	No	Only flags with this tag
`base`	Yes	Base environment key
`limit`	No	Page size (default 20)
`other`	Yes	Environment key to compare against
`owner`	No	Owner email, or "none" for unowned flags
`cursor`	No	next_cursor from a previous response
`project`	Yes	Project key
`different_only`	No	Only flags whose configuration differs (default true)

Output Schema

Name	Required	Description	Default
`items`	No
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds value by disclosing the default filtering behavior (different_only defaults to true) and the plan/role requirement attached to the recommended alternative. It doesn't discuss pagination or result size, but the output schema carries return-shape information.

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?

Three tight sentences: purpose and comparison dimensions first, then the default output behavior, then the alternative path. Nothing is repeated or padded, and the most decision-relevant information is front-loaded.

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?

With annotations, a full-coverage schema and an output schema, the description covers what an agent needs: what is compared, what is returned by default, and where to go for a single-flag diff. Minor gaps such as pagination behavior and the tag/owner filters are adequately handled by the schema rather than the prose.

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 all eight parameters are already documented in the schema, including different_only's default and the base/other environment keys. The description only restates the different_only default and the compared sections, adding little beyond the structured fields — baseline 3 is appropriate.

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 and resource ('Compare flag configuration between two environments') and further names the axes of comparison (state, defaultVariation, strategy, rules, prerequisites). That level of detail separates it cleanly from siblings like get_flag or update_flag_environment_config, which operate on a single flag.

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?

It gives an explicit routing rule: for a single flag's exact change set, use preview copy_flag_config instead, and it notes the plan and role required for that path. Combined with the stated default behavior ('returns only differing flags unless different_only is false'), an agent can decide when this tool is the right call without guessing.

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