SAS MCP Server

Official

by sassoftware

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Create Performance Definition

create_performance_definition

DestructiveIdempotent

Configure project model performance monitoring over time from period CAS tables, including scoring, drift bins, and champion or challenger tracking.

Instructions

Define how a project's models are monitored over time (a performance definition).

The data comes as one CAS table per period in data_caslib, named <data_prefix>_<n>_<label>: CREDIT_1_Q1, CREDIT_2_Q2, ... Each holds the model's inputs and the actual target. With score_data (the default) Model Manager scores them itself; otherwise they must already hold the model's outputs. Results go to the ModelPerformanceData caslib, and run_performance_definition computes them.

The project needs its target fields and a champion first: set_project_champion sets both. A project has one performance definition: when it has one already, that one is returned, and replace changes it to these settings instead (it keeps its ID).

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>",
      "data_caslib": "<data_caslib>",
      "data_prefix": "<data_prefix>"
    },
    "name": "create_performance_definition"
  }
}

Input Schema

Name	Required	Description
`name`	No	Definition name (default: "<project> performance").
`replace`	No	Change the project's existing definition to these settings.
`max_bins`	No	Bins for the drift statistics (default 10).
`model_ids`	No	Models to monitor (default: the project's champion).
`project_id`	Yes	The project.
`score_data`	No	Score the period tables first (default true).
`data_caslib`	Yes	Caslib of the period tables.
`data_prefix`	Yes	Their common prefix.
`input_variables`	No	Inputs to check for drift (default: the first model's inputs).
`monitor_champion`	No	Also follow whichever model is champion later.
`output_variables`	No	Outputs to assess (default: the event probability variable, else the model's outputs).
`monitor_challengers`	No	Also monitor the project's challengers.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.19.2Nov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true; the description explains exactly why — a project has one definition, an existing one is returned rather than duplicated, and 'replace' mutates it while keeping its ID. It also discloses the on-disk contract (one CAS table per period named <data_prefix>_<n>_<label>), the scoring default, and where results land (ModelPerformanceData), all beyond what annotations convey.

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 core purpose is front-loaded in the first sentence, followed by data layout, prerequisites, and replace semantics in a logical order. It is dense but long, with typesetting markup (reStructuredText-style backticks) that adds minor noise for an agent reader.

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 12-parameter mutation tool, the description covers the data contract, prerequisite tools, single-definition/upsert behavior, and the follow-on run step; return values are covered by the existing output schema, so nothing essential is missing for correct invocation.

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%, so the baseline is 3, but the description adds real meaning the schema lacks: the period-table naming convention tied to data_prefix and data_caslib, and the distinction that with score_data the engine scores the tables itself whereas otherwise they must already hold model outputs. Defaults such as model_ids→champion are already documented in the schema, so this is enrichment rather than full compensation.

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 opening line gives a specific verb and resource — 'Define how a project's models are monitored over time (a performance definition)' — and the remaining text makes clear this is configuration, not computation, by pointing to run_performance_definition for the actual scoring. An agent can distinguish it from the sibling run tool without opening either schema.

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

Usage Guidelines5/5

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

It states explicit prerequisites ('The project needs its target fields and a champion first: set_project_champion sets both') and names the downstream step ('run_performance_definition computes them'). It also spells out the alternative/adjustment path: when a definition already exists, it is returned and 'replace' changes it to these settings.

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

Deploy Server