Skip to main content
Glama
sassoftware

SAS MCP Server

Official
by sassoftware

Create Code File

create_code_file

Creates SAS Intelligent Decisioning code files in DS2, Python, or SQL from provided code and an optional signature, then reports whether the code parsed.

Instructions

Create a SAS Intelligent Decisioning code file: DS2, Python or SQL.

Viya reads the signature from the code. DS2: a package with method execute(...) — in_out parameters are outputs: package "${PACKAGE_NAME}" /inline; method execute(double score, in_out varchar band); ... end; endpackage;. Python: def execute(score): with 'Output: band' as the first statement and the outputs returned. SQL: {?:name:type} marks an input and {:name:type} an output column; the result rows also come back as a data grid.

Python cannot state types in its code, so give signature with the dataType of every input and output, or they stay unknown; for DS2 it adds descriptions and lengths. The result's status and errorMessage say whether the code parsed.

Input Schema

NameRequiredDescriptionDefault
codeYesThe code.
nameYesCode file name.
folderNoWhere to store it: a folder path, ``My Folder``, a folder ID or URI. Omit to use the default folder; if there is none, ask the user.
code_typeYesds2, python or sql.
signatureNoOptional ``[{"name", "dataType", "direction", "description"}]``.
descriptionNoOptional description.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.19.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses real behavior: Viya parses the code to derive the signature, Python cannot declare types so they remain unknown unless supplied, and the result's status/errorMessage indicate parse success. That post-creation validation behavior is exactly the kind of context annotations cannot carry.

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 in the first sentence, followed by per-language specification details in the order an agent would need them. The formatting is dense and skimmable, with only minor redundancy in restating the type/signature rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter creation tool with an output schema, the description covers the essentials: required code shape per language, when signature details matter, folder defaulting (in schema), and how to detect a parse failure. It omits what happens on name collision or overwrite and whether any permissions/locking are needed before creation.

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?

With 100% schema coverage the baseline is 3, but the description goes further by explaining what the loosely-typed `signature` objects must contain for Python (dataType for every input and output) versus what they add for DS2 (descriptions and lengths). It also ties code structure to the code_type enum, which 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?

The first line states a specific verb, resource, and the three supported code types (DS2, Python, SQL), so an agent can immediately tell this is a creation tool for code files rather than a decision flow or ruleset. It does not name the sibling it is not (update_code_file), so differentiation from the modify path relies on the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the purpose statement and reinforced by format-specific requirements per code_type, but there is no explicit 'use this when... / use update_code_file instead when...' guidance. The closest to a rule is the folder note ('omit to use the default folder; if there is none, ask the user'), which appears in the schema rather than as routing guidance.

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