End the active SAS Viya connection's Compute and CAS sessions and stop lingering runs, so the next execution starts new sessions and reruns startup code.
End the Workspace's SAS Compute and CAS sessions of a SAS Viya connection (default: the active one); the next run starts new ones (startup code runs again). Runs on it (also one a Stop couldn't end) are stopped.
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No |
Changes observed during successful MCP inspections.
v0.11.0Input schema / properties / connectionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Connection"
+}v0.10.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing concrete side effects: both Compute and CAS sessions end, the target defaults to the active connection, startup code re-runs on the next run, and in-flight runs (even ones a Stop failed to kill) are terminated. That is exactly the state-destruction context an agent needs. Worth noting a mild tension with destructiveHint=false, since live work is killed, though the change is recoverable via new sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, purpose front-loaded, minimal padding. The parenthetical recovery clause "(also one a Stop couldn't end)" is awkwardly spliced and the final clause reads backwards, costing some clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter, no output schema, and annotations covering the safety profile, the description supplies what matters: what is torn down, which connection is targeted by default, and what happens on the next run. Only auth/permission expectations and error behavior when no connection is active are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single optional 'connection' parameter, so the description must carry the load. It does explain the one critical default: null means the active connection. It does not say how a connection is identified (name, ID, or alias), which leaves format ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: "End the Workspace's SAS Compute and CAS sessions of a SAS Viya connection". It is distinguishable from sibling sas_stop because it targets sessions rather than a run, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the situation — you want the next run to start fresh sessions with startup code re-run — and hints at a recovery case ("also one a Stop couldn't end"). But it never states when to prefer this over sas_stop, sas_connection_activate, or sas_viya_sign_out, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.