Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Flag evaluations in environment

flag_evaluations

Read-only

Analyze flag evaluation counts over 7, 30, or 90 days in one environment: variation split, serving rule, and rollout weight mismatch checks to spot misconfigured targeting.

Instructions

What a flag actually served in ONE environment over the last 7, 30 or 90 days: total evaluations, the split by variation, and which rule (or fallthrough, off, prerequisite, error) served what. Percentage-rollout rules include their configured weights and a sample-ratio check; rollout.flagged=true means the served split is statistically off the configured weights. A live rollout rule is always listed, with count 0 and no variations when it served nothing. rollout.unreached is set when a live rollout rule got no evaluations while the flag's rules got 100 or more: usually the context lacks rollout.bucketBy, or an earlier rule or the conditions catch the traffic. These are evaluation counts, NOT unique users. Counts come from SDK-reported events, so zero means no evaluations were reported, not necessarily no traffic.

Input Schema

Name	Required	Description
`days`	No	Window in UTC days: 7 (default), 30 or 90
`flag`	Yes	Flag key or id
`project`	Yes	Project key
`environment`	Yes	Environment key, e.g. production

Output Schema

Name	Required	Description
`days`	No	The window requested: 7, 30 or 90.
`toUtc`	No	When the counts were read.
`fromUtc`	No	Start of the window: UTC midnight `days - 1` days ago, or the flag's creation day if later.
`sources`	No	Evaluations per part of the targeting that served them: live rules in evaluation order, then deleted rules, then fallthrough, off, prerequisite, error, notFound and unknown. A live percentage-rollout rule is always listed, with a count of 0 and no variations when it served nothing in the window, so its rollout check (and rollout.unreached) has a row.
`totalCount`	No	Evaluations in the window. Evaluation counts, not unique users.
`variations`	No	Evaluations per variation over the window.
`environmentKey`	No	The environment's key.
`lastEvaluatedAtUtc`	No	The last reported evaluation, or null if none was reported.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Nov 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already establish read-only safety, and the description adds substantial behavioral context beyond that: SDK-reported event semantics, statistical rollout checks, unreached rollout explanations, and how live rollout rules appear when they serve nothing. These are exactly the nuances an agent needs to interpret results correctly.

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?

The description is front-loaded with the core purpose and every sentence carries useful caveats about evaluation semantics. It is dense and somewhat long as a single paragraph, but it does not waste words on restating structured fields.

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?

Given the read-only annotation, complete input schema, and existing output schema, the description is complete for correct use. It goes further by explaining how to interpret zero counts, rollout weights, flagged splits, and unreached rollout rules.

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 the schema already documents project, flag, environment, and the days window. The description restates the 7/30/90-day window but adds little parameter-level meaning beyond what the schema provides.

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 exactly what the tool returns: evaluation counts for a flag in one environment over a 7/30/90-day window, split by variation and serving rule. This is specific enough that an agent can distinguish it from configuration-oriented siblings like get_flag or get_targeting.

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

Usage Guidelines4/5

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

The description gives clear context for when this data is relevant and warns that counts are evaluations, not unique users, with zero meaning no reported events rather than no traffic. It does not explicitly name sibling alternatives or exclusions, which keeps it below a 5.

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