mcp-server

update_rule

DestructiveIdempotent

Update an EXISTING product rule (Attribute Rule). Use this to change a saved rule after validate_rule passes. Always validate_rule the new document first and fix every error. Identify the rule by rule_id (from list_rules / get_rule) and 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}}]}]}]}. The safe pattern is: get_rule, edit the returned document, validate_rule, then update_rule with it. Only name, description, category, icon and rules are editable; usage/bookkeeping fields are preserved server-side. A get_rule document already carries map_attribute_value search/replace in the correct {value:''}-objects form (paired by index) — edit those entries verbatim, never flatten them to plain strings (plain strings save but map nothing). update_rule keeps ruleId + every attachment, so the edit updates all attributes using this rule; the value/options mapping is not run by validate_rule's dry-run — verify after a real export/build. scope selects the library: 'project' (default) or 'shared_template' (a template_read_only error means your access cannot write there). Returns {ruleId, scope, status, changed, reason, validation}; status 'updated' / 'no_changes' on success, or 'rejected' with the validation errors when invalid (HTTP 200, nothing written). SAVE-ONLY: this stores the document and runs none of its transform steps; the edit reaches a feed's output only after export_feed on the feeds that use this rule. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects). OVERWRITES the pipeline in every feed that uses the rule.

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_id": "<rule_id>",
      "rule": "<rule>"
    },
    "name": "update_rule"
  }
}

Input Schema

Name	Required	Description
`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	Which library the rule lives in: 'project' (default) = the project's own library; 'shared_template' = the reusable shared template library.
`rule_id`	Yes
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / rule / description

Added value: +"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."

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes well beyond: it discloses the overwrite blast radius ("OVERWRITES the pipeline in every feed that uses the rule"), the save-only semantics, which fields are editable vs. preserved server-side, the HTTP-200-with-'rejected' behavior, and the template_read_only error for shared_template. That is exactly the context annotations cannot carry.

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?

Front-loaded with purpose, then preconditions, then mechanics, then return values — a sensible order. However it is a single dense block of long compound sentences (the map_attribute_value and validation/dry-run sentences are heavy), and some of the schema-restating document shape could be trimmed or bulleted.

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?

For a destructive mutation tool with nested objects and no output schema, the description covers return shape ({ruleId, scope, status, changed, reason, validation}), the status enum, the save-only/export dependency, scope routing, and the project_id fallback. An agent has everything needed to call it correctly and interpret the result.

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?

With only 50% schema coverage and two undocumented params (rule_id, project_id), the description compensates: it says rule_id comes from list_rules/get_rule, that project_id is optional and inferred for single-project customers (project_id_required otherwise, then call list_projects), and it spells out the `rule` document shape and the scope enum's meaning and failure mode.

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?

Opens with a specific verb+resource and a scope qualifier: "Update an EXISTING product rule (Attribute Rule)." The uppercase EXISTING plus the named siblings (validate_rule, get_rule, list_rules, create_rule) let an agent separate this from create_rule and from read tools without opening a schema.

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?

States the preconditions and the ordering explicitly: "Use this to change a saved rule after validate_rule passes. Always validate_rule the new document first and fix every error," and then gives the canonical sequence "get_rule, edit the returned document, validate_rule, then update_rule." It also names when NOT to expect effect (no transform runs until export_feed).

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

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?