SAS MCP Server

Official

by sassoftware

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Execute Sas Code

execute_sas_code

Destructive

Run SAS code in a SAS Viya compute session and retrieve job results, logs, and output. Use a fresh session to avoid inherited state between runs.

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	Default
`sas_code`	Yes	the SAS code snippet to be executed using the Viya Job Execution API Service
`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.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?

The description discloses state persistence across calls, the creation and execution of a job definition, and the concrete risk of leftover session state causing double-counting on re-runs. This goes well beyond the annotations' destructiveHint and readOnlyHint flags, surfacing a non-obvious behavioral trap that could otherwise lead an agent to produce incorrect results.

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?

The description is front-loaded with a one-sentence purpose, then uses clearly marked IMPORTANT and Tip sections for operational guidance. Each paragraph earns its place: the state-persistence warning prevents a real failure mode, and the CAS tip saves an agent from avoidable log noise. There is no padding or repetition beyond the concise actionable restatement of the clean-session remedy.

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 tool that runs arbitrary SAS code, the description covers the core action, the session-persistence failure mode, the clean-slate remedy, the job-definition lifecycle, and a practical CAS data-access recommendation. An output schema exists to document return values, and both parameters are fully described, so no critical invocation detail 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?

The input schema already documents both parameters at 100% coverage. The description adds meaningful context for fresh_session by explaining the shared warm compute session and explicitly linking fresh_session=True to reset_compute_session, which helps an agent decide when to use the parameter. It does not add syntax-level detail for sas_code, but the schema description is already sufficient there.

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?

The first sentence states a clear verb (Executes), direct object (provided SAS code), environment (Viya), and outcome (returns information about the completed Job). It does not explicitly contrast with siblings like submit_batch_job or query_data, so an agent may need to infer selection from the name and schema rather than being told, but the core action is unmistakable.

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 IMPORTANT note gives concrete usage guidance: pass fresh_session=True when code must start clean, and mentions reset_compute_session as an equivalent alternative. It also offers a practical CAS data-access preference over caslib _all_ assign. However, it never states when to choose execute_sas_code over execution/data siblings such as submit_batch_job or query_data, so explicit exclusions are absent.

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

Deploy Server