SassyMCP

Official

Overview Schema Source Related Servers Discussions Admin

sassy_panel

Idempotent

Manage the local Control Panel web UI for permissions, settings, and event log. Check status, start or stop it, and rotate the bearer token without restarting.

Instructions

Mutating (start/stop/rotate change state). Controls the Control Panel, the loopback-only web UI for the permission engine, settings, event log, and classifiers. Optional action (default "status"): status returns running state, the startup-enabled flag, and a tokenless URL — the bearer token is never revealed here; start launches the panel and enables auto-start at future startups (flips panel.enabled in config) and returns a tokenless URL plus a hint to call action="url"; stop shuts it down and disables auto-start; url prints the tokenized URL without starting (this is the explicit token-reveal action); rotate regenerates the panel bearer token, persists it to the token file, audit-logs the rotation, and returns the new token (the old token stops working immediately, no restart needed). Binds 127.0.0.1 on the configured port (default 8765, auto-increments if taken). Send the token in the X-Panel-Token header (the ?token= query form is deprecated but still accepted). Use for interactive inspection and tuning of permissions/settings rather than doing it by hand with sassy_set_config.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`action`	No		status

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_panelOutput"New value: +"sassy_panelDictOutput"

First observedv0.1.0Jul 31, 2026

TDQS

A4.2/5.0

Behavior1/5

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

Annotations declare idempotentHint=true, but the description's rotate action 'regenerates the panel bearer token... old token stops working immediately' — repeated calls produce different tokens and effects, clearly non-idempotent. This contradicts the annotation, and the rule requires a score of 1 for contradiction.

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?

The description is long but dense; each sentence earns its place. It front-loads the mutating nature, then systematically covers actions, network binding, token transport, and alternative tools. The semicolon-separated action list improves scannability.

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 tool with five actions, security implications (token reveal), and network details, the description covers everything: action outcomes, token handling, header vs deprecated query form, port behavior, and autostart config changes. Despite the annotation contradiction, the description itself is complete for correct invocation.

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

Parameters5/5

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

Schema coverage is 0% for the lone `action` parameter, but the description fully documents every possible value (status, start, stop, url, rotate) with detailed behavior and outcomes. This adds critical semantics absent from the schema.

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 states a specific verb ('Controls') and resource ('Control Panel, the loopback-only web UI...'), and distinguishes the tool from sibling sassy_set_config by explaining it is for interactive tuning rather than manual config. This makes the purpose unmistakable.

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 explicitly says 'Use for interactive inspection and tuning of permissions/settings rather than doing it by hand with sassy_set_config,' naming the alternative and the condition. It also enumerates each action's effect (status, start, stop, url, rotate), leaving no ambiguity about when to invoke it.

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

Deploy Server