Skip to main content
Glama
sassoftware

SAS MCP Server

Official
by sassoftware

Create Segmentation Tree From Table

create_segmentation_tree_from_table

Converts FICO-style strategy tables (TRIAD, Blaze) into SAS Intelligent Decisioning segmentation trees by ordering decision keys and assigning leaf outcomes.

Instructions

Build one segmentation tree from a strategy table: one row per branch, a column per decision key.

This is how a FICO-style strategy export (TRIAD, Blaze) becomes a SAS Intelligent Decisioning tree. Decision keys are tested in the order of key_columns; a key whose values do not differ within a subtree is not tested there. Each leaf leads to an outcome that assigns the row's outcome_columns.

With split="lower_bound" a key's value is the lower bound of a range, as such exports write it: sibling values 0, 600, 630 become >= 630, 600 to < 630 and, for the lowest, Other (missing values included). With split="exact" each distinct value is its own branch.

The table comes from exactly one of rows (inline, small tables), file_path (a CSV the server reads, gated by ALLOW_LOCAL_FILE_UPLOAD) or caslib_name + table_name (a CAS table — load an Excel sheet with upload_data first). Repeated column names in a CSV get _2, _3.

The result reports what was built — leaves, split nodes, outcomes, and rows whose path is identical but whose outcome differs (conflicts) — not the tree itself, which can be hundreds of kilobytes.

Input Schema

NameRequiredDescriptionDefault
nameYesTree name.
rowsNoInline rows, each an object of column to value.
splitNo"lower_bound" (range lower bounds) or "exact" (values).lower_bound
folderNoWhere to store the tree (and value lists): a folder path, ``My Folder``, a folder ID or URI. Omit to use the default folder; if there is none, ask the user.
file_pathNoA CSV file the server reads.
server_idNoCAS server (default cas-shared-default).cas-shared-default
table_nameNoThe CAS table.
caslib_nameNoCaslib of a CAS table to read.
descriptionNoOptional description.
key_columnsYesDecision key columns in strategy order. A column name, or ``{"column": ..., "variable": ...}`` to name the tree variable; two columns may test the same variable (a key that appears twice in the strategy).
outcome_typesNoData type per outcome column, overriding the one inferred from the values: ``{"Scenario Group": "string"}``. Types must match the decision variables the tree is mapped to.
outcome_prefixNoPrefix of outcome names (default: the first outcome column).
outcome_columnsYesColumns the leaves assign, e.g. ["Scenario ID", "Scenario Group"].
row_label_columnNoColumn that identifies a row in the report, e.g. the branch number.
create_value_listsNoAlso create a value list per tested variable, holding the conditions its nodes use, and tie the variable to it.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.19.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare the non-read-only, non-destructive, non-idempotent posture; the description adds real behavior: the source is exactly one of rows/file_path/caslib+table, local file reads are gated by an env flag, duplicate CSV headers become _2/_3, and the response reports counts and conflicts rather than the (potentially huge) tree. No auth or rate-limit context, but the disclosure goes well beyond the annotations.

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 one-line purpose, then layered paragraphs for split semantics, source selection, and the return summary. Four paragraphs for 15 parameters is justified, though the split paragraph could be tighter and repeats some field-level detail already in the schema.

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 15-parameter, 3-required builder tool this covers what an agent actually needs: which source to supply, how to pre-stage Excel, the default-folder caveat ('if there is none, ask the user'), and that the response is a summary, not the tree. The output schema carries the rest.

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 above that by stating the mutual-exclusivity rule between the three source modes and by explaining how key_columns order drives testing and how lower_bound vs exact reshape branch values in ways the enum alone does not convey.

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?

Specific verb+resource with scope: 'Build one segmentation tree from a strategy table: one row per branch, a column per decision key.' The 'from table' framing plus the FICO/TRIAD/Blaze export context implicitly separates it from create_segmentation_tree, but that sibling is never named, so the agent must infer the split.

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?

Says when this applies ('This is how a FICO-style strategy export (TRIAD, Blaze) becomes a SAS Intelligent Decisioning tree') and routes to two prerequisites — upload_data for Excel sheets and the ALLOW_LOCAL_FILE_UPLOAD gate for CSV. It does not state when to prefer create_segmentation_tree instead, which is the main remaining ambiguity.

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