SAS MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Publish Decision Flow

publish_decision_flow

Publishes a locked decision revision to a MAS destination and polls the async job, returning the real module ID required before score_data can execute the decision.

Instructions

Publish a locked decision revision to a Micro Analytic Score (MAS) destination.

Required before score_data can execute the decision — MAS runs published modules, not decision flows directly. Requires the DS2 code generation service to be healthy for this decision's rule sets; an error mentioning rule set code generation is an environment-level issue, not a bad payload.

Publishing is asynchronous and the resulting MAS module ID is server-generated — it is NOT publish_name. This polls the publish job (properties.masModules[0].jobUri) until it reaches a terminal state and returns the real moduleId alongside the publish record, so the result is directly usable with get_mas_module_step_signature/score_data without a separate lookup via list_mas_modules.

The code is generated for MAS, as SAS Intelligent Decisioning does when it publishes, so lookup tables are read from MAS. Unlike a module the Intelligent Decisioning UI publishes, whose inputs end in an underscore (credit_score_), the module's inputs keep the decision's variable names.

Input Schema

Name	Required	Description	Default
`decision_id`	Yes	The decision flow UUID (not its name — list_decision_flows returns both).
`revision_id`	Yes	The locked revision UUID (see ``lock_decision_flow_revision``).
`poll_timeout`	No	Max seconds to wait for the publish job to reach a terminal state before giving up (default 60.0).
`publish_name`	Yes	The published name shown in Model Publish (not the MAS module ID — see above).
`destination_name`	No	The configured MAS publishing destination (default "maslocal").	maslocal

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.7.0Aug 7, 2026

changedInput schema / properties / decision_id / description

Previous value: -"The decision flow UUID."New value: +"The decision flow UUID (not its name — list_decision_flows returns both)."

Addedv1.5.0Jul 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare mutation/async safety (readOnly=false, idempotent=false). The description adds substantial value: async polling behavior, server-generated module ID distinct from publish_name, environment-level error diagnosis for rule-set codegen, and MAS-side lookup table reads. Strong beyond-annotation disclosure, though the exact terminal-state/error return shape is left to the output schema.

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 core action in the first sentence, then behavior details. Fairly long and dense with parenthetical caveats, but each paragraph carries useful distinction (score_data prerequisite, polling, input naming). Minor redundancy around publish_name/module ID.

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?

Given a mutation tool with an output schema and full annotation coverage, the description supplies the prerequisite chain, async polling semantics, module-ID distinction, and environment-error guidance. Nothing critical for correct invocation is missing.

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 already 100%, so baseline is 3. The description still adds meaning: it clarifies publish_name is the Model Publish name and NOT the MAS module ID, and clarifies that decision_id is a UUID (not a name). That reinforces/extends schema intent without exceeding it.

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+resource+precondition: 'Publish a locked decision revision to a MAS destination.' This distinguishes it from publishing siblings (publish_ml_champion_model) and from consumers like score_data.

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?

Explicitly says it is required before score_data can execute, that the revision must be locked, and that the returned moduleId is usable directly with get_mas_module_step_signature/score_data rather than via list_mas_modules. Clear when-to-use and alternatives.

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

Deploy Server