Skip to main content
Glama
Sign In
SAS MCP Server

SAS MCP Server

Official
by sassoftware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Publish Ml Champion Model

publish_ml_champion_model
Destructive

Publish the champion model from an AutoML pipeline automation project to a chosen destination, defaulting to the configured deployment destination.

Instructions

Publish the champion model from an AutoML pipeline automation project to a destination.

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": {
      "project_id": "<project_id>"
    },
    "name": "publish_ml_champion_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYesID of the ML pipeline automation project.
destination_nameNoName of the destination to publish to (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. Changed5 schema fields changedv1.19.2
    • addedInput schema / properties / destination_name / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / destination_name / default
      Added value: +null
    • changedInput schema / properties / destination_name / description
      Previous value: -"Name of the destination to publish to."New value: +"Name of the destination to publish to (see\n``list_publishing_destinations``). Default: the deployment's\n``MCP_DEFAULT_PUBLISH_DESTINATION``, ``maslocal`` unless an\nadministrator changed it."
    • removedInput schema / properties / destination_name / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
-  "project_id",
-  "destination_name"
-]New value: +[
+  "project_id"
+]
  2. Addedv1.2.1

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the agent knows this is an irreversible mutation. The description adds no behavioral context beyond that: it does not say what happens at the destination (overwrite of a previously published model?), that a champion must exist first, or what permissions/authorization are needed. For a destructive publish operation this is a meaningful gap.

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?

A single front-loaded sentence with no wasted words and the action stated first. It is efficient, though its brevity is partly the cause of the missing guidance rather than a virtue in itself.

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?

Scored against what the structured fields already carry: output schema exists, both parameters are fully documented, and annotations disclose the destructive/irreversible profile. What is left missing is prerequisite and side-effect context (champion must be set, destination overwrite behavior), which is a real but moderate gap given the structured coverage. Overall, an agent has enough to call it, but not enough to call it safely with full understanding.

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 description coverage is 100%, and the schema already explains project_id, destination_name, and the default-destination fallback including the list_publishing_destinations pointer. The description adds no additional meaning about either parameter, so the baseline 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 description names a specific verb ('Publish') and a specific resource ('the champion model from an AutoML pipeline automation project') plus the target ('a destination'). That is enough for an agent to distinguish it from register_ml_champion_model (registration vs. publication) and from publish_model (which the description implies is a different, presumably non-AutoML path). It does not explicitly call out those siblings, so it stops short of a 5.

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

Usage Guidelines2/5

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

There is no when-to-use guidance: nothing says the project must already have a champion set, nothing says when to prefer this over publish_model or publish_decision_flow, and no preconditions are stated. Usage is only weakly implied by 'champion model from an AutoML pipeline automation project'.

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