SassyMCP

Official

Overview Schema Source Related Servers Discussions Admin

sassy_session_stop_all

DestructiveIdempotent

Terminate all active persistent terminal sessions and return stopped names with exit codes. Use at task end to clean up leftover dev servers, builds, and watchers.

Instructions

Mutating: terminates every active persistent terminal session (each process is terminated and cleaned up) and returns a list of stopped names with exit codes plus a total count. Use it at the end of a task to clean up leftover dev servers, builds, and watchers; use sassy_session_stop when you only want to end one session.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.15.1Sep 18, 2026

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "title": "Result",
-    "type": "string"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"sassy_session_stop_allOutput"New value: +"sassy_session_stop_allDictOutput"

First observedv0.1.0Jul 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, and the description adds context beyond them: it states what gets destroyed ('each process is terminated and cleaned up') and what is returned (list of stopped names with exit codes plus a total count). The description is consistent with all annotations, including the idempotent state effect.

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?

Two sentences with no filler. The mutating/destructive nature is front-loaded, followed by the action, output, usage guidance, and the sibling alternative. Every sentence earns its place.

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 destructive bulk operation with no parameters and an existing output schema, the description is complete: it covers what is terminated, cleanup semantics, return value, when to use it, and when to use the alternative. The existing annotations carry the safety profile, so nothing an agent needs to call it correctly is missing.

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?

The tool has zero parameters, so the schema is trivially 100% covered and the description needs no parameter explanations. Baseline 4 applies for 0-parameter tools; the description does not need to compensate for missing schema detail.

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 uses a specific verb ('terminates') with a precise resource ('every active persistent terminal session') and explicitly notes the cleanup behavior and return value. It distinguishes itself from sassy_session_stop by naming that sibling as the single-session alternative.

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 gives explicit when-to-use context: 'Use it at the end of a task to clean up leftover dev servers, builds, and watchers.' It also names the alternative and the condition that triggers it: 'use sassy_session_stop when you only want to end one session.' No inference is required.

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

Deploy Server