Skip to main content
Glama
sassoftware

SAS MCP Server

Official
by sassoftware

Update Glossary Term

update_glossary_term
DestructiveIdempotent

Update an existing glossary term by merging your changes into its current fields—definition, label, parent, or custom attributes—and publish a draft when ready.

Instructions

Update a business term's text, parent or custom attributes — and publish a draft.

The glossary API replaces the whole term on update, so this reads the current one first and merges your changes into it: omitting an argument leaves that field alone rather than blanking it. attributes merges the same way, per attribute — pass only the ones you are changing, and set one to "" to clear it. A boolean is the exception: the glossary has no empty boolean and rejects "", so set it to True/False rather than trying to clear it.

Because the whole term is rewritten, every attribute the type marks required must hold a value — including ones made required after this term was created. That is checked before the call, and reported by name.

A term's type cannot be changed after creation. Its parent can: pass parent_id to move it, or "" to make it a root term.

A draft is a different resource. A term left unpublished by create_glossary_term(publish=false) can be read and deleted at the ordinary path, but not written there — the service answers a plain PUT on a draft with a 404. This routes the write to the draft instead, so editing one works; and publish then promotes it to a published term, which nothing else here could do. Publishing a term that is already published is reported, not attempted: there is no draft to promote and the service answers that with a 404 too.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew name (unique among siblings, max 100 characters).
labelNoNew display label.
publishNoPublish the term if it is still a draft (default false). Pass it on its own to publish without changing anything else.
term_idYesThe glossary term UUID.
parent_idNoMove the term under a different parent, or ``""`` to make it a root term. A term cannot be its own ancestor.
attributesNoCustom attributes to change, keyed by label. Same value forms as create_glossary_term — booleans as True/False, multi-select as a list.
definitionNoNew definition.
descriptionNoNew description, max 1000 characters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.14.0

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing whole-term replacement with merge semantics, field preservation when omitted, per-attribute merging with "" clearing, the boolean exception, required-attribute validation, type immutability, parent movability, and draft 404 handling. This is rich, accurate behavioral context with no contradiction against readOnlyHint=false, destructiveHint=true, or idempotentHint=true.

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 long but every paragraph earns its place: merge behavior, required-attribute risk, type/parent rules, and draft routing are each separate hazards an agent must understand. The summary sentence front-loads the core purpose before the deeper behavioral details.

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?

Given eight parameters, full schema coverage, and an output schema, the description covers the non-obvious behaviors needed to call the tool safely: draft 404s, publish behavior, required attribute enforcement, type immutability, and merge semantics. Nothing essential for correct invocation is left unexplained.

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 description coverage is 100%, so the schema already defines each parameter's basic meaning. The description adds operational semantics beyond the schema: omitting arguments leaves fields untouched, attributes merge per attribute and can be cleared with "", booleans cannot be cleared, and publish can be passed alone. This supplements rather than duplicates 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 opens with a specific verb and resource: 'Update a business term's text, parent or custom attributes — and publish a draft.' This clearly distinguishes the tool from glossary creation, deletion, and assignment siblings by focusing on mutating an existing term.

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 gives explicit draft-related usage context, naming create_glossary_term(publish=false) and explaining that this tool routes the write to a draft and can promote it with publish. It does not explicitly enumerate all alternatives such as assign/unassign_glossary_term, but the draft and publish guidance makes the primary selection criteria clear.

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