SassyMCP

Official

Overview Schema Source Related Servers Discussions Admin

sassy_setup_license

Destructive

Manage your SassyMCP supporter license via LemonSqueezy: check status, activate with a key, deactivate to free a seat, or force a validation re-check.

Instructions

Manages the optional SassyMCP supporter license against LemonSqueezy. The action parameter (default "status") accepts status, activate, deactivate, validate; the key parameter is required only for activate and must look like XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. All tool groups are unlocked for everyone with no key, so activating registers your seat and tier label but unlocks nothing. action=status is read-only and reports tier, addons, validity, email, expiry, the license file path, and any LemonSqueezy instance identifiers. action=activate registers this machine and mints a local HMAC payload for offline use. action=deactivate frees the machine's seat and deletes the local file. action=validate forces an immediate LemonSqueezy re-check (normally weekly). Use status to inspect the current tier; only activate with a key purchased from sassyconsultingllc.com/store.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`key`	No
`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_setup_licenseOutput"New value: +"sassy_setup_licenseDictOutput"

First observedv0.1.0Jul 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Even though annotations already flag destructiveHint=true, the description goes far beyond that by detailing exactly what each action does: status is read-only and reports specific fields; activate registers the machine and mints an HMAC payload; deactivate frees the seat and deletes the local file; validate forces a re-check instead of the normal weekly cycle. It also discloses the surprising fact that activating unlocks nothing, which is critical behavioral context an agent needs before invoking.

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 description is long but every sentence adds distinct value: overview, parameter rules, unlock revelation, per-action behavior, and usage guidance. It is front-loaded with the core purpose and then systematically details each action. The only minor inefficiency is some redundancy in repeating action names and behaviors, but it remains tight and scannable.

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?

Given the output schema exists and the description covers all four action semantics, key format, side effects, and the 'no unlock' reality, an agent has what it needs to call the tool correctly. Minor gaps like error handling for invalid keys or absence of a license are not mentioned, but these are edge cases rather than essential call context for a well-behaved tool.

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 description coverage is 0%, so the description carries the full burden of explaining both parameters. It thoroughly covers the 'action' parameter by listing all accepted values and their defaults, and the 'key' parameter by specifying when it is required and giving its exact format (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX). This is more than enough to compensate for the empty 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 opens with a specific verb-resource pair ('Manages the optional SassyMCP supporter license against LemonSqueezy') and then enumerates distinct actions, making it unmistakably different from sibling setup tools like sassy_setup_status or sassy_setup_wizard. It clearly positions the tool as a license manager rather than a general setup utility.

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

Usage Guidelines4/5

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

The description gives explicit usage advice: 'Use status to inspect the current tier; only activate with a key purchased from sassyconsultingllc.com/store.' It also clarifies that activation is not necessary because all groups are unlocked, which prevents unnecessary activation. However, it does not explicitly compare against sibling tools or exclude them, relying on the obvious domain difference rather than named alternatives.

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

Deploy Server