SAS MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create Decision Flow

create_decision_flow

Creates SAS Intelligent Decisioning flows from ordered steps—rule sets, models, assignments, conditions, and branches—and stores the decision in a SAS Content folder.

Instructions

Create a SAS Intelligent Decisioning flow: rule sets, segmentation trees, code files, models, sub-decisions, assignments, conditions and branches.

Give the flow as steps (every step kind, wired by name) or, as before, rule_set_steps (rule sets only, wired by hand). A flow that sets defaults, scores a model, branches on its score and checks the result::

steps = [
    {"type": "assignment", "name": "Defaults",
     "assignments": {"offer": "NONE", "credit_limit": 0}},
    {"type": "model", "id": "<model repository id>"},
    {"type": "branch", "branch_type": "range", "variable": "P_BAD1", "cases": [
        {"label": "Low risk", "max": 0.1999, "steps": [
            {"type": "assignment", "assignments": {"offer": "GOLD", "credit_limit": 10000}}]},
        {"label": "Medium risk", "min": 0.2, "max": 0.4999, "steps": [
            {"type": "rule_set", "id": "<rule set id>"}]}],
     "default": [{"type": "assignment", "assignments": {"offer": "DECLINE"}}]},
    {"type": "condition", "expression": "offer = 'GOLD'",
     "on_true": [{"type": "code_file", "id": "<code file id>"}], "on_false": []},
]

Steps nest: a branch case, a branch default and either side of a condition hold steps of any kind, branches and conditions included.

Assignment — assignments maps a decision variable to a constant, written plainly ("GOLD", 10000): the service quotes strings itself and evaluates nothing, so "a + b" is stored as that text. Compute values in a rule set or code file. The variable must be in signature; name labels the step.
Model — id of a model in the model repository (list_registered_models, Tier 6). Its inputs map to same-named decision variables; its outputs (e.g. P_BAD1, I_BAD) are added as decision variables unless signature has them, a class label as a string. mappings renames: {"model variable": "decision variable"}.
Branch — variable (on the branch, or per case) and cases, checked in order; the first match runs, else default. range cases take min and/or max (leave one out for an open end) and compare inclusively, >= min and <= max; cases must not share a value, so end the lower case just below the next (max 0.1999 next to min 0.2). equals cases take one value; like cases a pattern with % and _ wildcards.
Condition — a DS2 expression over decision variables, e.g. score >= 630 and band = 'A'; check it with validate_decision_expression first.
Rule set, segmentation tree, code file, sub-decision — id, optional revision and mappings. Segmentation trees, code files, value lists and custom functions are created with the Tier 10 (Decisioning Advanced) tools; list_decisioning_assets finds existing ones.

The decision is always stored in a SAS Content folder. Without folder it goes to the deployment's default folder; when there is none, the call is refused and you should ask the user which folder to use. The result's folder says where it was stored.

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": {
      "name": "<name>",
      "signature": "<signature>"
    },
    "name": "create_decision_flow"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Decision name (max 60 chars).
`steps`	No	The flow, in order — any step kind (see above): ``rule_set``, ``segmentation_tree``, ``code_file``, ``decision`` (a sub-decision), ``model``, ``assignment``, ``condition`` or ``branch``. ``revision`` defaults to the newest locked revision (one is locked if there is none); "working" uses the editable one. Mappings default to same-named decision variables; ``{"step term": "decision variable"}`` renames. The result's ``steps_report`` lists the revisions used, the variables added and any step input nothing maps to.
`folder`	No	Where to store the decision: a folder path such as ``/Public/Content/Decisions``, ``My Folder`` (or a folder below it, ``My Folder/Risk``), a folder ID, or a folder URI (``/folders/folders/<id>``). Omit to use the default folder.
`signature`	Yes	Flow-level input/output variables, each ``{"name", "direction", "dataType"}`` — direction input or output; dataType string, decimal, integer, date, datetime, boolean.
`description`	No	Optional description.
`rule_set_steps`	No	Ordered list of rule set steps to execute in sequence, each ``{"ruleSetId", "versionId", "mappings"}`` — versionId is a locked rule set revision (see ``lock_business_ruleset_revision``); mappings is a list of ``{"stepTermName", "direction", "targetDecisionTermName"}`` connecting the rule set's terms to this decision's signature. A term produced as output by an earlier step can be consumed as input by a later step via a shared signature entry.
`add_missing_variables`	No	With ``steps``, add a decision variable for every step term none matches (default true): Intelligent Decisioning validates a step only when all its terms are mapped. The result's ``steps_report.variables_added`` lists them.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv1.19.0Oct 23, 2026

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): Intelligent Decisioning\nvalidates a step only when all its terms are mapped. The result's\n``steps_report.variables_added`` lists them.",
+  "type": "boolean"
+}

addedInput schema / properties / folder

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Where to store the decision: a folder path such as\n``/Public/Content/Decisions``, ``My Folder`` (or a folder below\nit, ``My Folder/Risk``), a folder ID, or a folder URI\n(``/folders/folders/<id>``). Omit to use the default folder."
+}

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 flow, in order — any step kind (see above): ``rule_set``,\n``segmentation_tree``, ``code_file``, ``decision`` (a sub-decision),\n``model``, ``assignment``, ``condition`` or ``branch``. ``revision``\ndefaults to the newest locked revision (one is locked if there is\nnone); \"working\" uses the editable one. Mappings default to\nsame-named decision variables; ``{\"step term\": \"decision variable\"}``\nrenames. The result's ``steps_report`` lists the revisions used,\nthe variables added and any step input nothing maps to."
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "signature",
-  "rule_set_steps"
-]New value: +[
+  "name",
+  "signature"
+]

Addedv1.5.0Jul 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare write, non-idempotent, non-destructive, non-open-world, so safety framing is covered. The description adds real behavioral context beyond that: the decision is always stored in a SAS Content folder, the call is refused with no default folder, the result's folder field reports placement, and assignment strings are stored literally rather than evaluated. It does not mention auth/permission requirements, but on balance it adds substantive value.

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 the purpose statement and mode selection, then organized by step kind with bolded headers. It is long, but nearly every sentence carries operational detail; the worked example is the only section an expert agent could skim.

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?

An output schema exists so return values need no explanation, yet the description still flags steps_report and variables_added. For a 7-parameter, deeply nested construction tool it covers folder behavior, step wiring, revisions, mappings and validation cross-references — nothing an agent needs is missing.

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 coverage is 100%, yet the description goes well past it: the steps array is free-form (additionalProperties: true) in the schema, and the description supplies the entire step-kind grammar — assignment quoting rules, model id/mappings and output variables, branch range inclusivity and non-overlapping case constraints, condition DS2 expressions, and add_missing_variables default behavior. This is exactly the semantic lift a description should provide.

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 ('Create a SAS Intelligent Decisioning flow') and enumerates the step kinds it accepts, which clearly separates it from siblings like update_decision_flow, create_business_ruleset, or create_segmentation_tree. An agent can identify it as the flow-construction tool without opening the schema.

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?

Explicitly routes between the two input modes ('give the flow as steps ... or, as before, rule_set_steps') and cross-references validate_decision_expression, list_registered_models and list_decisioning_assets. It also prescribes the fallback behavior when no default folder exists ('ask the user which folder to use'). Missing is any explicit statement of when to prefer this over update_decision_flow or creating assets individually.

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

Deploy Server