Skip to main content
Glama

list_rule_transforms

Read-onlyIdempotent

List the transform steps and condition operators a product rule may use (an attribute-value transformation — the feature Koongo's UI and help call "Attribute Rules" / "Rules"). Use this to look up the vocabulary FIRST, before you write a rule. Read-only reference data: a transform step (trim, replace text, map values…) is a pure value transformation stored in a rule document and applied when Koongo builds a feed — not an action any tool runs. GUARDRAIL: a Rule must never be keyword-matching — if a value would need MORE THAN 3 text-contains conditions to derive (color, material, gender… from free text), STOP and enrich per-product with set_api_source/set_ai_source; do not build the Rule. A Rule patches FEED OUTPUT only and writes NOTHING onto the products; if the user asked to enrich the products, use set_api_source/set_ai_source (or ask first) — never substitute a Rule. Returns {operations:[{name, label, group, returnType, valueType, arguments}], conditions:[{operator, label, disabledFor, arguments}], ruleSchema, examples} — operations is the rule document's key for its transform steps. Filter to one step group with group; set detail 'full' for the complete argument specs and 'compact' (default) for a lighter list. include_conditions adds the condition operators; include_examples adds curated end-to-end worked examples. Steps in a group run left-to-right; each step's returnType must match the next step's valueType. str_replace searches LITERAL text (., *, | mean themselves) unless the search has regex delimiters, like /\s*\|.*$/. Full authoring recipe — the rule-document and condition-tree shape, sortId precedence and the Default Rule, matching a condition value's type to its attribute, and the map_attribute_value (search/replace as ARRAYS OF OBJECTS {value:'…'} paired by index — the #1 gotcha) and setoption recipes: call get_koongo_help with slug 'rule-authoring'. Always validate_rule a rule before create_rule / update_rule.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_rule_transforms"
  }
}

Input Schema

NameRequiredDescriptionDefault
groupNoLimit the list to one catalog group label of transform steps; omit for all.
detailNo
include_examplesNo
include_conditionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only annotations, the description explains that this returns pure reference data, that steps are stored in a rule document and applied only when Koongo builds a feed, and that a Rule patches feed output only and writes nothing onto products. It also discloses the return shape and the str_replace literal-search caveat.

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 content is front-loaded and mostly earns its place, with guardrails first and details later. It is dense and somewhat lengthy for a list tool, including authoring recipes and gotchas that are useful but border on tangential, keeping it just short of a 5.

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?

No output schema exists, yet the description spells out the returned keys (operations, conditions, ruleSchema, examples) and explains the relationship between returnType and valueType. Given the complexity of rule authoring and the four optional parameters, it is complete enough for an agent to invoke correctly.

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?

Schema description coverage is only 25%, but the description compensates fully: it explains filtering by `group`, the `detail` compact vs full modes, and the effects of `include_conditions` and `include_examples`. Every parameter gains meaning beyond the bare schema.

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?

States a specific verb and resource: list the transform steps and condition operators a product rule may use. It disambiguates the term 'Attribute Rules' and clarifies that a transform step is a stored value transformation, not an action a tool runs, making it easy to distinguish from siblings like create_rule or set_api_source.

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?

Explicitly says to use this FIRST before writing a rule, names the alternatives (set_api_source/set_ai_source) and the condition under which they are preferred, and gives a concrete guardrail (more than 3 text-contains conditions → stop). It also routes the agent to validate_rule before create_rule/update_rule.

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