Skip to main content
Glama

Preview rule

preview_rule
Read-only

Preview an UNSAVED rule against a sample of the latest run: match/change/exclusion counts, per-field change tallies, danger warnings (required fields emptied, identifiers stripped, heavy exclusion), audit deltas, and example before/after diffs. Nothing is written anywhere. Rule definition format: {"when":{"all":[conditions],"any":[conditions],"anyOf":[{"all":[conditions]}]},"then":[actions]} — anyOf is an OR of condition groups, AND-ed with the top-level conditions. Actions: set/copy/replace/append/prepend/lookup/extract/shorten/calculate/round/concat/normalize/strip_html/remove_duplicates (dedupe a separator-delimited list value)/clear/fallback/from_parent/exclude/exclude_group. Condition ops: eq, ne, contains, not_contains, starts_with, not_starts_with, ends_with, not_ends_with, regex, not_regex, gt, lt, gte, lte, between, not_between (take "values": [min,max]), longer_than, shorter_than, in_list, not_in_list (take "values": string[]), in_list_regex, not_in_list_regex (take "values" of regex patterns; match when any pattern matches), date_before, date_after ("today", "today+/-N" or "YYYY-MM-DD"), date_range_active, date_range_inactive (no value; test the ISO range in the field against now), empty, not_empty. Conditions may use "valueField" to compare against another field instead of a literal. Variant groups (items sharing custom:item_group_id): exclude_group {"match":"any"|"all", default "any"} removes the whole family when any/every member matches the conditions and must be the rule's only action; from_parent {"field"} copies the group parent's value onto matching variants (parent = the member whose id equals the group id, else the first member); the condition pseudo-field "group:size" is the family's member count (numeric ops only). Group exclusions are reported as whole groups in the preview warnings.

Input Schema

NameRequiredDescriptionDefault
feedIdYesFeed id from list_feeds.
definitionYesThe rule definition JSON to preview.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations, including match/change/exclusion counts, per-field tallies, danger warnings, audit deltas, and before/after diffs. It also reinforces the non-mutating behavior and explains how group exclusions appear in preview warnings.

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 preview behavior and safety, then transitions into a dense but necessary DSL reference. It is long, but for a complex rule format the detail largely earns its place.

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 nested definition object, no output schema, and complex rule DSL, the description is complete enough to support correct invocation. It explains return metrics and the rule format in enough detail that an agent can both choose and call the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the schema only says definition is an object; the description provides extensive semantics for the rule definition format, condition operators, action types, and variant-group handling. This is exactly the context an agent needs to construct a valid definition.

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 opens with a specific verb and resource: preview an UNSAVED rule against a sample of the latest run. It clearly scopes the operation and distinguishes previewing from saving or listing rules through the emphasis on UNSAVED and 'Nothing is written anywhere.'

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?

It gives a clear usage context: previewing unsaved rules against the latest run sample, which implies checking before saving. However, it does not explicitly name create_rule as the save alternative or state when not to use the tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources