Skip to main content
Glama
sassoftware

SAS MCP Server

Official
by sassoftware
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

upload_file

Upload a file to SAS Viya Files Service, optionally specifying a target folder. Provide content, a file path, or a URL as the source.

Instructions

Upload a file to the Viya Files Service, optionally into a Content folder.

Provide the file content through exactly one of:

  • content — inline text (the original behaviour; text files only).

  • file_path — a path the server reads directly from its own disk (in stdio mode that's your machine). Handles binary files (xlsx, zip, images) untouched. Disable with ALLOW_LOCAL_FILE_UPLOAD=false.

  • url — an HTTP(S) URL the server fetches the file from. Also binary-safe.

file_path and url sources larger than MAX_UPLOAD_BYTES (default 100 MiB — SAS Viya's own default file-upload limit) are refused.

parent_folder_uri files the upload into a Content folder (e.g. /folders/folders/{folderId}) — the location %include/filesrvc ingestion and other folder-scoped consumers need. Without it the file lands unfiled under the caller's user context.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoHTTP(S) URL the server fetches the file from.
contentNoFile content as an inline string (small text files).
file_nameYesName for the file.
file_pathNoPath to a file the server reads directly from disk.
content_typeNoMIME type. Defaults to ``text/plain`` for ``content``, else guessed from ``file_name`` (``application/octet-stream`` when unguessable).
parent_folder_uriNoTarget folder URI (``/folders/folders/{id}``); get one from list_files or the Folders service.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed12 schema fields changedv1.7.0
    • addedInput schema / properties / content / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / content / default
      Added value: +null
    • changedInput schema / properties / content / description
      Previous value: -"File content as a string."New value: +"File content as an inline string (small text files)."
    • removedInput schema / properties / content / type
      Removed value: -"string"
    • addedInput schema / properties / content_type / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / content_type / default
      Previous value: -"text/plain"New value: +null
    • changedInput schema / properties / content_type / description
      Previous value: -"MIME type (default 'text/plain')."New value: +"MIME type. Defaults to ``text/plain`` for ``content``,\nelse guessed from ``file_name`` (``application/octet-stream``\nwhen unguessable)."
    • removedInput schema / properties / content_type / type
      Removed value: -"string"
    • addedInput schema / properties / file_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Path to a file the server reads directly from disk."
+}
    • addedInput schema / properties / parent_folder_uri
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Target folder URI (``/folders/folders/{id}``);\nget one from list_files or the Folders service."
+}
    • addedInput schema / properties / url
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "HTTP(S) URL the server fetches the file from."
+}
    • changedInput schema / required
      Previous value: -[
-  "file_name",
-  "content"
-]New value: +[
+  "file_name"
+]
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

The description adds transparency about server-side behavior (reads from disk, fetches URL, handles binary files) and configuration flags. It does not contradict the annotations (readOnlyHint=false, etc.). Since annotations already exist, this extra context is valuable but not exhaustive, earning a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with bullet points, but it is verbose and repeats much of the schema content. The bullet lists are helpful, but the text could be more concise without losing clarity.

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?

The description covers all essential usage aspects: content sources, target folder, constraints, and configuration sensitivity. Since an output schema exists, return values are not explained, which is acceptable. The description is complete enough for an agent to use the tool correctly.

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% and the description repeats parameter descriptions, but it adds meaningful context: clarifies that file_path is server-side, url is fetched, content is inline, and parent_folder_uri is a target folder. It also mentions size limits and binary safety, enriching beyond the schema.

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?

The description clearly states the tool uploads a file to the Viya Files Service, optionally into a Content folder, and specifies three input methods. This is specific and distinguishes from siblings like upload_data or upload_inline_data by focusing on file-based uploads.

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 description explains when to use each input method (content for inline text, file_path for server disk, url for remote) and notes constraints like size limits and the ALLOW_LOCAL_FILE_UPLOAD flag. However, it does not explicitly contrast with sibling upload tools, so guidance on tool selection is implicit rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sassoftware/sas-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server