create_rule
Create a NEW product rule (an Attribute Rule). Use this to save a new rule after validate_rule passes. GUARDRAIL: a Rule is never a substitute for per-product enrichment — if you would need MORE THAN 3 text-contains conditions (contains/contains_any/starts_with on a description/title) to derive a value (color, material, gender…), do NOT create a Rule; enrich instead with set_api_source/set_ai_source and map that source attribute (see the server ENRICH guidance). A Rule patches FEED OUTPUT only and writes NOTHING onto the products; if the user asked to enrich the products / add attribute X to the products, use set_api_source/set_ai_source (or ask first) — never substitute a Rule. Always validate_rule it first and fix every error. Pass the full rule document as rule — {name, description, category, icon, rules:[{sortId, enabled, type, conditions, operationGroups:[{mode, parentMode, attributes, operations:[{name, arguments:{key:value}}]}]}]} (see list_rule_transforms for the vocabulary). Any _id/id you include is IGNORED — the server always mints a new one (this tool never overwrites an existing rule; use update_rule for edits). scope selects where it is created: 'project' (default) = the project's own library; 'shared_template' = the reusable shared template library (a template_read_only error means your access cannot write there). Returns {ruleId, scope, status, changed, reason, validation}; status 'created' on success, or 'rejected' with the validation errors when the rule is invalid (HTTP 200, nothing written). SAVE-ONLY: this stores the document and runs none of its transform steps; a new rule has NO effect on any feed until you attach it to a feed attribute with map_feed_attribute (rule_id) and then export_feed; a shared_template rule affects no feed at all until it is used by a project. VALUE/OPTIONS MAPPING: for a map_attribute_value step, search and replace are arrays of {value:''} objects paired by index (NOT plain strings — plain strings save but map nothing, showing empty rows); replace optional. That step is not executed by validate_rule's dry-run (passthrough computedValue) — verify only after a real export/build. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects).
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": {
"rule": "<rule>"
},
"name": "create_rule"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | The full rule document (stored configuration data) — {name, description, category, icon, rules:[{sortId, enabled, type, conditions, operationGroups:[{mode, parentMode, attributes, operations:[{name, arguments}]}]}]}. `operations` holds pure value-transform steps (see list_rule_transforms) that Koongo applies to the attribute value when it builds a feed; they are data, never actions this tool runs. | |
| scope | No | Where to create the rule: 'project' (default) = the project's own library; 'shared_template' = the reusable shared template library. | |
| project_id | No |