Skip to main content
Glama
Sign In
SAS MCP Server

SAS MCP Server

Official
by sassoftware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Publish Model

publish_model
Destructive

Publishes any registered model to MAS, CAS, a container registry, or Git; supports dry-run reporting and optional replacement of published models with the same name.

Instructions

Publish a registered model to a destination: MAS, CAS, a container registry, Git, ...

Any model in the Model Repository can be published, whatever made it. With dry_run the tool only reports what it would do: the destination and its type, the published name, and whether a published model of that name is already there. A published model of the same name is not replaced unless replace is true. Publishing runs in the background; list_published_models shows its state and validate_published_model checks the published copy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model_id": "<model_id>"
    },
    "name": "publish_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNoOnly report what would happen.
replaceNoReplace a published model of the same name.
model_idYesThe model's ID.
publish_nameNoThe published name (default: the model's name, with characters a destination refuses turned into underscores).
git_remote_pathNoFor a Git destination: the directory in the repository to publish to.
destination_nameNoDestination (see ``list_publishing_destinations``). Default: the deployment's ``MCP_DEFAULT_PUBLISH_DESTINATION``, ``maslocal`` unless an administrator changed it.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.19.2

TDQS

A4/5.0
Behavior4/5

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

The description adds real context beyond the annotations: publishing runs in the background, dry_run reports destination, type, published name and existence, and an existing model of the same name is preserved unless replace is true. Most useful is the background-execution disclosure, which the openWorldHint/destructiveHint annotations do not convey. It stops short of stating permissions, failure modes, or whether a partial publish can leave the destination in an inconsistent state.

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?

The key action and destination list are front-loaded, and the paragraph flows from what to how to verification. The trailing ellipsis in the destination list and the slight redundancy with the schema descriptions cost it a point.

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 six-parameter, async, destructive publishing tool with an output schema and fully-described params, the definition covers eligibility, safety defaults, async behavior, and the verification workflow. An agent has everything needed to call it correctly without extra context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented, and the description largely restates dry_run, replace, and the publish_name defaulting rule. It adds no new syntax, constraints, or interaction between parameters, so the baseline of 3 applies.

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 names a specific verb (publish) and resource (a registered model) and enumerates destination kinds (MAS, CAS, container registry, Git). It is clear what the tool does, but it never distinguishes itself from sibling publishing tools such as publish_ml_champion_model or publish_decision_flow, leaving that separation to inference.

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?

It states the eligibility condition plainly ("Any model in the Model Repository can be published, whatever made it") and routes follow-up work to list_published_models and validate_published_model. What is missing is any explicit when-not-to-use guidance or a pointer to an alternative when the target is a champion model or decision flow.

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