Sas MCP Server

SAS Viya MCP Server

A Model Context Protocol (MCP) server for executing SAS code, training AutoML projects, scoring models and so much more for SAS Viya environments.

Features

• 115 tools across 11 selectable tiers, spanning the Analytics Life Cycle on SAS Viya
• Interactive views (MCP Apps) for data, SAS logs and glossary editing in clients that render them — Claude, ChatGPT, Microsoft 365 Copilot, VS Code, Cursor
• Prompt Templates for improving your SAS Code
• OAuth2 authentication with PKCE flow
• HTTP-based MCP server compatible with MCP clients

Articles & Videos

Here you can find getting articles on how to use and integrate the SAS MCP Server in different tools and what to build with it:

• From REST APIs to AI Agents: Why the SAS Viya MCP Server Matters
• Connecting GitHub Copilot to SAS Viya with the SAS Viya MCP Server
• Bring Your Own Key: SAS Viya MCP Server with GitHub Copilot CLI
• Putting the SAS Viya MCP Server to Work in GitHub Copilot
• Connecting Claude Code CLI to SAS Viya with the SAS Viya MCP Server
• Putting the SAS Viya MCP Server to Work in Claude Code CLI
• Integration with SAS Retrieval Agent Manager (RAM)
• Five Industry Use Cases using the SAS Viya MCP Server as Videos

Getting Started

Prerequisites

• Required

  • Python 3.12+
  • uv 0.8+
  • SAS Viya environment with compute service
  • Setup the Viya environment for MCP
    • See configuration.md

• Optional

  • Docker: refer to container setup
  • Kubernetes: sample manifests (Contour or nginx) and a Helm chart in deploy/

Installation

1. Clone the repository:

git clone <repository-url>
cd sas-mcp-server

1. Install dependencies

uv sync

NOTE: This will by default create a virtual environment called .venv in the project's root directory.

If for some reason the virtual environment is not created, please run uv venv and then re-run uv sync.

Usage

1. Configure environment variables:

cp .env.sample .env

Edit .env and set

VIYA_ENDPOINT=https://your-viya-server.com

1. Start the MCP server (see Choosing a deployment mode below):

Option A: HTTP mode (pre-run the server, connect from MCP client)

uv run app

The server will be available at http://localhost:8134/mcp by default. Authentication is handled via OAuth2 PKCE flow in the browser.

Option B: Stdio mode (MCP client starts the server on demand)

Authenticate once. Two equivalent options:

# Option B1 — if you have the SAS Viya CLI installed:
sas-viya auth loginCode

# Option B2 — built-in helper, no external CLI needed (Viya 2022.11+):
uv run sas-mcp-login

Both flows write an access token to a local cache (~/.sas/credentials.json and ~/.sas-mcp-server/credentials.json respectively); the stdio server reads whichever it finds. When the token expires, re-run the same command.

Then configure your MCP client to launch the server directly (see below).

Option C: Docker / Podman (containerized deployment)

Pull the pre-built image from GitHub Container Registry:

docker pull ghcr.io/sassoftware/sas-mcp-server:latest
docker run -e VIYA_ENDPOINT=https://your-viya-server.com -p 8134:8134 ghcr.io/sassoftware/sas-mcp-server:latest

Or build locally from source:

docker build -t sas-mcp-server .
docker run -e VIYA_ENDPOINT=https://your-viya-server.com -p 8134:8134 sas-mcp-server

Available image tags:

• latest — most recent tagged release
• <major>.<minor>.<patch> (e.g. 1.0.0) — specific release
• <major>.<minor> (e.g. 1.0) — latest patch of a minor release
• edge — tip of main (unreleased, for testing)
• sha-<short> — pinned to a specific commit

Programmatic clients with a pre-existing Viya token

If your caller already holds a Viya access token (e.g. an automation script that obtained one via the SAS Viya CLI), start the HTTP-mode server with ALLOW_RAW_BEARER=true and pass the token directly:

curl -H "Authorization: Bearer $VIYA_TOKEN" http://localhost:8134/mcp ...

The server validates the token against Viya's JWKS and uses it upstream as-is, bypassing the MCP JWT swap. The default OAuth2 PKCE flow keeps working alongside — both client types share the same /mcp endpoint.

If your Viya APIs are intentionally exposed without auth (for example, a local/dev Compute API endpoint), set VIYA_AUTH=false to bypass all SASLogon/OAuth flows in both HTTP and stdio modes. In this mode the server sends upstream requests without an Authorization header.

If your compute deployment does not expose /compute/contexts and only supports a fixed session, set COMPUTE_SESSION_ID=<session_id>. The compute tools will use that session directly instead of creating context-backed sessions.

Choosing a deployment mode

Quick guidance:

• Starting out or exploring? Use stdio — one sas-viya auth loginCode or uv run sas-mcp-login, then your MCP client manages the server lifecycle.
• Need secure, interactive auth? Use HTTP — no stored passwords, each user authenticates via browser.
• Deploying for a team or on a server? Use Docker — portable, no Python dependency on the host, easy to integrate with orchestrators.
• Running it for a whole organisation? Use Kubernetes — sample manifests and a Helm chart are in deploy/, including the routing the OAuth flow needs for either Contour (the chart's default, and the only one that can mount the server under a path prefix on an existing hostname) or ingress-nginx.
• Using Gemini CLI? Use stdio — Gemini CLI does not support HTTP mode or browser-based OAuth. See Gemini CLI configuration.
• Integrating with Microsoft 365 Copilot? Use Kubernetes (or any remote HTTPS deployment) — Copilot declarative agents only reach remotely hosted MCP servers. A ready-to-sideload agent package and walkthrough are in examples/m365-copilot/.
• Adding it to a Microsoft Copilot Studio agent? Same remote HTTPS deployment, plus MCP_TOOL_RENAME=catalog_=infocat_ — Copilot Studio's agent runtime fails on tool names that start with catalog_. The steps are in examples/copilot-studio/.
• Not sure which Microsoft route fits? examples/microsoft-copilot.md compares the declarative agent and the Copilot Studio agent, and shows the settings for one deployment that serves both.
• Installing from a client's server catalogue? That path runs the published container in stdio mode (app-stdio), not as an HTTP server, so it authenticates from your ~/.sas token cache — which has to be mounted into the container at /app/.sas.

Limiting exposed tools (tiers)

Tools are grouped into numbered tiers. By default the server exposes all of them; set MCP_TIERS to expose only a subset — handy for keeping a client's tool list small and focused, or hiding capabilities a deployment shouldn't offer. Accepts ranges and comma lists (e.g. MCP_TIERS=0-4 or MCP_TIERS=0,1,6,7); unset means all tiers.

# Example: expose only compute/discovery/data-ops and reporting
MCP_TIERS=0-3 uv run app

Read-only mode

Set MCP_READ_ONLY=true to expose only tools that neither change server-side state nor cause server-side work — 57 of the 115 tools. Withheld tools are never registered, so they are absent from the client's tool list entirely: the model cannot see them, so it cannot attempt them.

This is a filter over the tiers, not a tier of its own — the read/write split cuts across every tier (Tier 3 has both get_report and delete_report). The two settings compose:

# Every read tool, all tiers
MCP_READ_ONLY=true uv run app

# Read tools of the reporting and decisioning tiers only
MCP_TIERS=3,7 MCP_READ_ONLY=true uv run app

The definition is strict: a tool qualifies only if it can neither write nor start work. Beyond the obvious create/update/delete tools, that withholds:

Classification is fail-closed: a tool that is not explicitly classified as read-only is withheld. The list lives in src/sas_mcp_server/tools/_access.py, and a test asserts it covers every registered tool, so a newly added tool cannot silently land in read-only mode.

Tool annotations (what clients are told)

The same classification is advertised to every client as MCP tool annotations on each tools/list entry — whether or not read-only mode is on:

Clients use these to shape their approval UX — e.g. Claude groups read-only tools for one-click approval and warns before destructive ones — and to decide when to interrupt the user. They are hints, not enforcement: the spec tells clients to treat them as untrusted unless the server is trusted, and MCP_READ_ONLY remains the server-side control. Without annotations a client must assume the spec's pessimistic defaults (writable, destructive, open-world) for every tool, so this only ever reduces friction. The browser landing page marks each tool read-only / write / destructive from the same hints.

Interactive views (MCP Apps)

Some results read badly as text however well the tool shapes them: a hundred rows of a table, a SAS log, a form's worth of typed attributes. Ten tools therefore also carry a small HTML view, using the MCP Apps extension, that a supporting client renders in a sandboxed frame beside the result:

Every view has a ⤢ button that opens it fullscreen where the host offers that (Claude does), which is where a wide table or a long log is meant to be read; the button does not appear on a host without it.

Everything about this is additive. The tool's return value is unchanged, so a client without the extension — Claude Code, a script, an older client — sees exactly what it saw before. Every request a view makes travels through the host to this server as an ordinary tool call with the session's token; the browser never talks to Viya, and a tool a deployment withholds through MCP_TIERS or MCP_READ_ONLY has no view either — nor does any control inside a view that would have called it, so a read-only deployment shows the glossary browser without its Publish button rather than with one that can only fail. The pages are fully inlined — the vendored @modelcontextprotocol/ext-apps bridge included — so they render on hosts that ignore CSP declarations and on an air-gapped Viya. MCP_APPS=false registers no views.

Whether a view is rendered depends on the client and on how it is connected:

A view's own controls call other tools (the Results tab reads the page through download_file, Tier 2), so a deployment that withholds those tiers gets the view without that control. View URIs carry a fingerprint of the page (ui://sas-viya/sas-log/execute_sas_code.<hash>.html) that changes with the server version, the page files and the tier selection, because hosts cache a page by its URI — claude.ai even across a connector being removed and added again; the plain URI is served too, for hosts holding an older tool listing.

HTML results

execute_sas_code returns the SAS log and listing as text, which is what the model reads. By default it also produces the page SAS Data and AI Studio would show, with tables styled by ODS and graphs drawn, and returns a link to it:

• How. The compute context opens no HTML destination of its own, so the server runs the code between an ods html5 statement and its close. Before the close comes ;*';*";*/;run;quit;, which ends whatever the code left open (an unterminated statement, quote or comment, or a step without run;) so that the close still runs. None of this appears in the log the model reads. html_results=false submits the code exactly as given.
• The link. When the code printed something, the page is saved to the Viya Files service and the result gains html_results_url. Opening it in a browser asks you to sign in to SAS Viya; the file sits in no folder, so Viya's default rules let only the person who ran the code (and administrators) open it. Pages are saved without an expiration, the Files service's default, so they stay until someone deletes them.
• In the SAS log view, the page is the Results tab, shown first when the code ran cleanly. The view fetches it through download_file, so a deployment without Tier 2 gets the link but not the tab.
• Cost. Opening and closing the destination adds about a tenth of a second to a job, and saving the page is one more request. The page itself, 40–70 KB and mostly ODS's stylesheet, never enters the model's context; only the link does.

Available Tools

The headings below match the numbered tiers above, so MCP_TIERS maps directly to the tools you expose (e.g. MCP_TIERS=0-3 gives Tiers 0–3).

Tier 0 — Compute Contexts & Code Execution

• execute_sas_code: Execute SAS code snippets and retrieve execution results (log and listing output), plus a link to the HTML results unless html_results=false. Runs in a reusable, per-user compute session that is kept warm across calls, so SAS state (WORK tables, macro variables, assigned librefs) persists between successive calls — use reset_compute_session to start fresh.
• list_compute_contexts: List available compute contexts
• reset_compute_session: Delete the cached compute session for a context, discarding its SAS state and forcing a fresh session on the next call

Tier 1 — Data Discovery

SAS Data Governance (metadata discovery & profiling):

• catalog_search: Search the catalog for assets (tables, columns, reports, …) using the SAS catalog search grammar (free text, facets like AssetType:Report, ranges). Each hit carries a resource_uri you can hand to the matching tool (e.g. get_report, get_castable_data).
• catalog_search_helper: Discover how to query the catalog — list the available facets, or the valid values for one facet — so you can build precise catalog_search queries.
• catalog_find_instance: Resolve the catalog instance for a source-asset resource_uri, bridging a search hit to the profiling and download tools without handling an instance id by hand.
• catalog_run_adhoc_analysis: Submit an ad-hoc profiling job for a table. NLP enrichment (language, sentiment, semantic IDs) is on by default, populating informationPrivacy, nlpTerms, nlpTags, and mostImportantFields.
• catalog_get_adhoc_analysis: Poll a profiling job and cross-check the target instance, reporting profile_ready once results have landed on the asset — so a download isn't fired too early.
• catalog_download_table_profile: Download a table's data dictionary and column profile as CSV, identified by either instance_id or resource_uri.
• catalog_list_agents: List the catalog's discovery agents (the crawlers that populate metadata).
• catalog_run_agent: Start a discovery agent run (asynchronous) to crawl its data source and refresh catalog metadata.
• catalog_get_agent_history: Inspect an agent's run history — status and how much metadata each run enumerated/added/updated/removed.

CAS data (in-memory):

• list_cas_servers: List available CAS servers
• list_caslibs: List CAS libraries on a server
• list_castables: List tables in a CAS library
• list_source_tables: List source tables not yet loaded into memory (candidates for promotion)
• get_castable_info: Get table metadata (row count, columns, size)
• get_castable_columns: Get column names, types, labels, formats
• get_castable_data: Fetch sample rows from a CAS table
• query_data: Run a FedSQL SELECT against CAS or compute data and get the rows back — one SQL surface over both storage tiers. Pick the tier with target (cas for caslib.table, compute for libref.table); joins, subqueries, aggregation, and UNION all work, and the row cap is applied server-side by the tool (a LIMIT you write is ignored, since a malformed one is silently discarded by CAS). Optionally returns the query as CREATE VIEW text for you to run yourself. Reads only: writes are refused pre-flight, and SAS macro triggers (%/&) are rejected because the macro processor would expand them outside SQL. Note the two tiers cannot be joined in one statement.

Compute libraries (SAS/Compute, within a compute context):

• list_compute_libraries: List the SAS libraries (librefs) assigned in a compute context
• list_compute_tables: List the tables in a SAS library within a compute context
• list_compute_columns: List the columns of a table in a SAS library
• get_compute_table_data: Fetch a page of rows from a table in a SAS library, values formatted as SAS displays them — the compute-tier counterpart of get_castable_data

Tier 2 — Data Operations & Files

• upload_data: Upload a data file into a CAS table — read server-side so the data never passes through the model's context — from file_path (the server reads it off disk) or url (the server fetches it and converts it to the multipart upload the endpoint requires). Ingests the formats the casManagement uploadTable API accepts — csv, tsv (csv + tab delimiter), xls, xlsx (single sheet), sas7bdat, sashdat — auto-detected from the extension or set with data_format. parquet is not accepted by that endpoint and is rejected up front with guidance (load via a path-based caslib + promote_table_to_memory, or convert to csv/sas7bdat).
• upload_inline_data: Create a small CAS table from inline csv/tsv text passed as a string (a lookup/mapping table the model builds on the fly, or a quick test table). The payload travels through the model's context, so it's for tiny tables only — use upload_data for files or anything larger.
• promote_table_to_memory: Load a source table into memory at global scope (idempotent)
• list_files: List files in the Viya Files Service
• upload_file: Upload a file to the Viya Files Service, optionally into a Content folder (parent_folder_uri). Content comes from exactly one of content (inline text), file_path (read server-side, binary-safe — xlsx, zip, images — gated by ALLOW_LOCAL_FILE_UPLOAD), or url (server-side fetch)
• download_file: Download file content
• find_folder: Look up a SAS Content folder by path (/Public/Content/Decisions, My Folder, My Folder/Risk), ID or URI, and return its ID, URI, name and full path — for confirming a folder the user named, or getting the URI that upload_file and MCP_DEFAULT_FOLDER take

Tier 3 — Reports & Visualization

• list_reports: List Visual Analytics reports
• get_report: Get report metadata and definition
• export_report: export a report (or specific report objects) in any format the VA service supports — package (zip), pdf, png, svg, csv, tsv, xlsx, or summary. Text formats come back inline, png as image content, and binary formats (package/pdf/xlsx) as an embedded file with the right MIME type.
• describe_report_objects: Discover what a report can contain — the eight report operations and every addable object (bar chart, list table, geo map, key value, …) with a one-line purpose, its data roles, common options, and an example payload. Call with no arguments for the catalog (including an intent→object map, placement guide, layout recipes, and the API's hard limits), object_type= for one object's contract (colloquial aliases like kpi resolve), category= to filter, or operation= for one operation's full shape — operation="addData" documents dataItems (column renames, SAS formats, aggregations, geography classification). Backs the apply_report_operations loop.
• create_report: Create a Visual Analytics report and return its id. Optionally pass an operations array to build the whole report in one atomic call; the result carries the created page/object names+labels and a verify hint.
• apply_report_operations: The authoring workhorse — apply an ordered batch of native VA operations (addData, addPage, addObject, updateObject, setParameterValue, updateData, changeData, applyDataView) to a report. Give a page a title with addPage's title field (a text band at the top of the page body — VA headers are controls-only); title every chart at add time via options.object.title; arrange objects with placement — page, relativeToObject (left/right/top/bottom for columns, rows, and grids), container (group into a standardContainer), or report (new_page creates-and-names a page inline for one-batch multi-page reports). The batch is atomic. Validates every operation, object key, and placement against the catalog first (reporting all errors at once), supports dry_run, handles the ETag concurrency handshake, and — with save_as=true plus result_report_name/result_folder — applies the batch save-as to a new report, leaving the source untouched. The flag alone decides the mode: without it the report is edited in place, and a name or folder given without it is refused rather than acted on. Typical loop: describe_report_objects → get_castable_columns → apply_report_operations → get_report_outline / export_report (png, page-by-page) to verify.
• get_report_outline: Read a report's structure back — pages → objects with the handles the other tools need (object name for placement/updateObject targets, label for export_report, page label for page placement).
• copy_report: Copy a report to a new one (optionally renaming/refoldering). Pairs with a changeData operation for the copy-and-replace pattern.
• delete_report: Delete a report and its content.

Tier 4 — Batch Jobs & Async Execution

• submit_batch_job: Submit a SAS job for async execution
• get_job_status: Check job state
• list_jobs: List recent/running jobs
• cancel_job: Cancel a running job
• get_job_log: Retrieve job log

Tier 5 — Automated Machine Learning

• list_ml_projects: List AutoML projects
• create_ml_project: Create a new AutoML project from a loaded, global-scope CAS table (caslib + table + optional CAS server)
• run_ml_project: Run pipeline automation
• register_ml_champion_model: Register an AutoML project's champion model to the Model Repository
• publish_ml_champion_model: Publish an AutoML project's champion model to a scoring destination

Tier 6 — Model Management & Scoring

• list_registered_models: List models in repository
• list_publishing_destinations: List available scoring/publishing destinations, for use with publish_ml_champion_model
• list_mas_modules: List published MAS modules
• get_mas_module_step_signature: Inspect a published MAS module step's input/output variable signature before scoring
• score_data: Score data against a published model or decision; for a decision published from the Intelligent Decisioning UI, whose inputs carry a trailing underscore, the plain names are accepted and mapped (inputs_renamed)

Tier 7 — Decisioning Foundation (SAS Intelligent Decisioning)

Build and run SAS Intelligent Decisioning decisions — rule sets that consult lookup tables, and decision flows that combine them with models, branches, conditions, assignments and sub-decisions — then publish a flow to Micro Analytic Score (MAS) so score_data can execute it. The life-cycle tools read, lock, copy and delete every kind of decisioning content. Segmentation trees, code files, value lists and custom functions are written with Tier 10; enable both (MCP_TIERS=...,7,10) for everything — the server logs a warning when Tier 10 is on without Tier 7.

Rule sets and decision flows are always stored in a SAS Content folder. The create tools take a folder — a path such as /Public/Content/Decisions, My Folder or My Folder/Risk, a folder ID, or a folder URI — and fall back to the deployment's MCP_DEFAULT_FOLDER. With neither, they refuse and the model asks the user where to store the asset. An update leaves an asset in its folder; one created before folders were required is filed by its next update, into the folder given or the default. Every create and update result carries folder, with the path the asset is in.

Business rules — rule sets:

• create_business_ruleset / update_business_ruleset / get_business_ruleset / list_business_rulesets / delete_business_ruleset: Manage rule sets (the input/output signature the rules operate on)
• lock_business_ruleset_revision: Lock the current rule set state as an immutable revision (what a decision step references)
• list_business_ruleset_revisions: List a rule set's locked revisions

Business rules — rules:

• create_business_rule / update_business_rule / get_business_rule / list_business_rules / delete_business_rule: Manage the conditional rules inside a rule set

Decision flows:

• create_decision_flow / update_decision_flow / get_decision_flow / list_decision_flows / delete_decision_flow: Manage decision flows that chain rule set steps
• get_decision_flow_code: Retrieve the generated DS2 execution code for a flow
• lock_decision_flow_revision / list_decision_flow_revisions / get_decision_flow_revision: Lock, list, and fetch immutable decision revisions
• publish_decision_flow: Publish a locked decision revision to a MAS destination, polling to completion and returning the server-generated MAS moduleId (directly usable with get_mas_module_step_signature / score_data). The code is generated for MAS, as SAS Intelligent Decisioning publishes it, so lookup tables work; the module's inputs keep the decision's variable names (the UI would add a trailing underscore, credit_score_)

create_decision_flow and update_decision_flow take steps, in which each step names what it is and the server wires it: {"type": "rule_set" | "segmentation_tree" | "code_file" | "decision", "id": ...} (a sub-decision is a decision), {"type": "model", "id": <model repository id>}, {"type": "assignment", "assignments": {"band": "GOLD"}}, {"type": "condition", "expression": "score >= 630", "on_true": [...], "on_false": [...]} and {"type": "branch", "branch_type": "range" | "equals" | "like", ...}. A referenced object's newest locked revision is used (one is locked if there is none); step terms map to same-named decision variables, and a term the decision has none for is added as a variable of its type and direction, because Intelligent Decisioning validates and publishes a step only when every term is mapped. Mappings never cross type families. Assignments set constants (compute in a rule set or code file); a model is referenced by its model repository ID and its outputs become decision variables; range branches compare inclusively (>= min, <= max) and their cases must not share a value; steps nest inside branch cases and conditions. The tool's description carries a worked example of each. rule_set_steps still works for rule-set-only flows. The result's steps_report lists the revisions used, the variables added and anything to check.

Content — one life cycle for every kind: asset_type is rule_set, decision, segmentation_tree, code_file, value_list, lookup_table, custom_function or function_category.

• list_decisioning_assets / get_decisioning_asset / delete_decisioning_asset: List, read (with the folder it is in; a rule set with its rules, a code file with its code, a value list with its entries, a lookup table with its versions and active entries; content over 150,000 characters is summarised) and delete any of them — a lookup table that rule sets use is refused, naming them, because Viya would delete it and leave those rules invalid
• get_decisioning_asset_code: The DS2 Viya generates for a rule set, decision or segmentation tree, or a code file's source
• list_decisioning_asset_revisions / lock_decisioning_asset_revision: Revisions of rule sets, decisions, segmentation trees and code files. Locking freezes the current state and opens the next revision; the result says which revision was locked
• copy_decisioning_asset: Copy a rule set (with its rules), decision, segmentation tree, code file, value list or lookup table into a folder
• validate_decision_expression: Compile a DS2 expression — a rule condition or action, a branch, a condition step — against a signature and return the compiler's error lines, before it goes into a rule set or decision

Lookup tables — keys and the value stored for each, which rules consult: a lookup condition tests whether a variable's value is a key, a lookupValue action assigns the value for a key. create_business_rule / update_business_rule take the lookup table by name and resolve its ID (a reference without one is stored as invalid), and report any condition or action Viya stored as invalid in problems. Rules read a lookup table's active version, which activation publishes to MAS and CAS; a decision already published uses newly activated entries on its next call, without being published again.

• get_lookup_table: Versions (which one is active, which failed to activate and why), one version's entries — paged, filtered by key — and the rule sets that use the table
• create_lookup_table: Create one from {"key": "value"} or a list of entries, with optional column labels, in a folder; activate publishes it right away
• update_lookup_table: Add or overwrite entries, remove keys, or replace them all; rename; relabel. An active version is never changed — a new version is started from it — and rules keep the active one until the new one is activated (activate does that in the same call)
• activate_lookup_table: Make a version the active one and wait for the publish to settle (active, running or failed with the reason); an earlier version (a rollback) or one whose activation failed is activated as a new version with its entries; republish copies the active version to MAS and CAS again

Tier 8 — Workbench (Execute Code Only)

• execute_sas_code: Execute SAS code snippets and retrieve execution results (log and listing output), plus a link to the HTML results unless html_results=false. Runs in a reusable compute session that is kept warm across calls, so SAS state (WORK tables, macro variables, assigned librefs) persists between successive calls

Tier 9 — Business Glossary (SAS Data Governance)

Read and author the SAS Business Glossary, and link its terms to the columns they describe. Tier 1 tells you a column is called CD_NAC_RSK; this tier tells you what that means and who says so.

Two things about the glossary are worth knowing before you start, because both are invisible in the raw API and both are handled for you here:

• A term has two ids. It exists as a Glossary object and as a Catalog entity, with different identifiers. Every tool returns both — term_id (glossary) and catalog_entity_id (catalog) — so you never have to work out which one you are holding.
• Custom attributes are stored under UUID keys. These tools read and write them by the label the glossary UI shows ({"Scope": "Group"}), validating required attributes and single-select values before the call is made.

Documentation truncated — see the full README on GitHub.