Skip to main content
Glama
Sign In
SAS MCP Server

SAS MCP Server

Official
by sassoftware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Update Decision Flow

update_decision_flow
DestructiveIdempotent

Replace an existing SAS Intelligent Decisioning flow with the full set of steps and signature. File the decision into a folder if it has none.

Instructions

Update an existing SAS Intelligent Decisioning flow.

Pass ALL steps (existing + new), as steps or rule_set_steps — the full flow is replaced on update, it is not a partial patch.

The decision stays in its folder. One that is in no folder (created before folders were required) is filed into folder, or the default folder. The result's folder says where the decision is.

Input Schema

NameRequiredDescriptionDefault
nameYesDecision name (max 60 chars).
stepsNoThe whole flow, every step kind — assignments, models, branches, conditions, rule sets, trees, code files, sub-decisions; ``create_decision_flow`` describes each, with an example.
folderNoOnly used when the decision is in no folder yet: a folder path, ``My Folder``, a folder ID or a folder URI to file it in.
signatureYesFlow-level input/output variables.
decision_idYesThe existing decision flow UUID (not its name — list_decision_flows returns both).
descriptionNoOptional description.
rule_set_stepsNoOrdered list of rule set steps (see ``create_decision_flow`` for the shape).
add_missing_variablesNoWith ``steps``, add a decision variable for every step term none matches (default true; see ``create_decision_flow``).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.19.0
    • addedInput schema / properties / add_missing_variables
      Added value: +{
+  "default": true,
+  "description": "With ``steps``, add a decision variable for every\nstep term none matches (default true; see ``create_decision_flow``).",
+  "type": "boolean"
+}
    • addedInput schema / properties / folder
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only used when the decision is in no folder yet: a folder\npath, ``My Folder``, a folder ID or a folder URI to file it in."
+}
    • addedInput schema / properties / rule_set_steps / anyOf
      Added value: +[
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / rule_set_steps / default
      Added value: +null
    • removedInput schema / properties / rule_set_steps / items
      Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}
    • removedInput schema / properties / rule_set_steps / type
      Removed value: -"array"
    • addedInput schema / properties / steps
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The whole flow, every step kind — assignments, models,\nbranches, conditions, rule sets, trees, code files, sub-decisions;\n``create_decision_flow`` describes each, with an example."
+}
    • changedInput schema / required
      Previous value: -[
-  "decision_id",
-  "name",
-  "signature",
-  "rule_set_steps"
-]New value: +[
+  "decision_id",
+  "name",
+  "signature"
+]
  2. Changed1 schema field changedv1.7.0
    • changedInput schema / properties / decision_id / description
      Previous value: -"The existing decision flow UUID."New value: +"The existing decision flow UUID (not its name — list_decision_flows returns both)."
  3. Addedv1.5.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds the essential detail of what is destroyed (the entire step list is overwritten) and the folder side effect for legacy folderless decisions. It does not mention revision-locking requirements or concurrency behavior, which would be the remaining behavioral gap for a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight paragraphs, front-loaded with the operation and the non-obvious full-replacement constraint before the folder edge case. Every sentence carries a constraint an agent could otherwise get wrong.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the note about the result's 'folder' field is a nice touch. For an eight-parameter destructive update it is nearly complete; the notable omission is any mention of revision locking or permission prerequisites.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by emphasizing the semantics that matter most — that 'steps' must carry existing plus new steps, and that 'folder' is only consulted when the decision currently has no folder. It does not add anything on 'signature' or 'add_missing_variables' beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Update an existing SAS Intelligent Decisioning flow' — which cleanly separates it from create_decision_flow and the read siblings (get_decision_flow, list_decision_flows). It does not name those siblings explicitly, but 'existing' plus the replacement semantics make the intent unambiguous.

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 critical usage rule is stated up front: pass ALL steps because the flow is fully replaced, not patched. It also defers step-shape detail to create_decision_flow, implicitly routing the agent there for construction. What's missing is when an agent should prefer this over delete+create, or prerequisites such as locking a revision (a lock_decision_flow_revision sibling exists).

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

Deploy Server

Other Tools