SAS MCP Server

Official

by sassoftware

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Execute Sas Code

execute_sas_code

Destructive

Runs SAS code in a reusable Viya compute session and returns job results, logs, and HTML output. Use fresh_session=True when code must start without inherited SAS state.

Instructions

Executes the provided SAS code in the Viya environment and returns information about the completed Job. This will create a job definition for the SAS code, execute it, and then retrieve the results.

IMPORTANT — state persists between calls: the code runs in a reusable compute session that is kept warm and shared across calls (per user), so SAS state — WORK tables, macro variables, and assigned librefs — survives between successive execute_sas_code calls. A re-run can therefore see leftovers from earlier calls (e.g. a check that counts results twice). Pass fresh_session=True (or call reset_compute_session) when the code must start from a clean slate.

Tip: to reach CAS data, prefer libname casuser cas; (or a targeted caslib statement) over caslib _all_ assign; — on tenants with many caslibs the latter floods the log with assignment NOTEs.

Input Schema

TableJSON Schema

Name	Required	Description
`sas_code`	Yes	the SAS code snippet to be executed using the Viya Job Execution API Service
`html_results`	No	When True (the default), the output is also written as an HTML page, as SAS Data and AI Studio shows it, graphs included, and saved so the person can open it in a browser. The code runs between an ``ods html5`` statement and its close, preceded by ``;';";*/;run;quit;`` so that an unterminated statement or quote cannot swallow the close; neither appears in the log. Pass False to submit the code exactly as given.
`fresh_session`	No	When True, discard any cached compute session first so the code runs with no inherited SAS state (equivalent to calling ``reset_compute_session`` immediately before).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.18.0Sep 30, 2026

addedInput schema / properties / html_results

Added value: +{
+  "default": true,
+  "description": "When True (the default), the output is also written\nas an HTML page, as SAS Data and AI Studio shows it, graphs\nincluded, and\nsaved so the person can open it in a browser. The code runs\nbetween an ``ods html5`` statement and its close, preceded by\n``;*';*\";*/;run;quit;`` so that an unterminated statement or\nquote cannot swallow the close; neither appears in the log.\nPass False to submit the code exactly as given.",
+  "type": "boolean"
+}

Changed1 schema field changedv1.7.0Aug 7, 2026

addedInput schema / properties / fresh_session

Added value: +{
+  "default": false,
+  "description": "When True, discard any cached compute session first\nso the code runs with no inherited SAS state (equivalent to\ncalling ``reset_compute_session`` immediately before).",
+  "type": "boolean"
+}

Changed1 schema field changedv1.2.0Jun 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "type": "object"
+}

First observedv0.1.0May 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond annotations by disclosing a major non-obvious behavior: SAS state (WORK tables, macro variables, librefs) persists across calls via a warm per-user session, so re-runs can see leftovers. It also explains the html_results wrapping behavior. This is exactly the behavioral context annotations cannot convey.

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?

Purpose is front-loaded, the state-persistence warning is called out as IMPORTANT, and the CAS tip closes it out. Everything earns its place, though the CAS log-flooding tip is somewhat tangential to core use and adds length.

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?

With an output schema present, return values need no explanation. The description covers the execution workflow, session/state semantics, the fresh_session escape hatch, and a practical CAS access tip — an agent has everything needed to call this correctly and safely.

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

Parameters3/5

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

Schema coverage is 100% and the schema descriptions are already detailed (html_results ODS wrapping, fresh_session discard behavior). The description supports the fresh_session semantics with the state-persistence rationale but adds no new parameter-level detail beyond what the schema provides, so baseline 3 is correct.

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 ('Executes the provided SAS code in the Viya environment') and further clarifies the internal workflow (create job definition, execute, retrieve results). This clearly distinguishes it from siblings like submit_batch_job or query_data, which do different unit-of-work things.

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?

Gives explicit conditions for fresh_session (start from clean slate) and names the alternative reset_compute_session, plus a preference for libname casuser over caslib _all_. It stops short of comparing itself against other code-execution siblings, but the when-to-use/reset guidance is substantive.

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

Deploy Server