SassyMCP

Official

Overview Schema Source Related Servers Discussions Admin

sassy_setup_wizard

Destructive

Set up your MCP user profile through a one-time questionnaire, store it as persona.md, and get tool recommendations tailored to your Android/Linux setup.

Instructions

Mutating: first-run questionnaire that writes the user profile to ~/.sassymcp/persona.md (keeping a one-deep persona.md.bak backup of any existing file before overwriting) and marks setup_complete in config. All parameters are optional: role (developer, sysadmin, security, devops, data, designer, manager, other; default developer), expertise_level (junior, mid, senior, principal, staff; default senior), communication_style (terse, balanced, verbose; default terse), security_posture (standard, hardened, paranoid; default standard), plus comma-separated specializations, languages, frameworks, newline-separated systems and projects, mcp_clients, and notes. The has_android and has_linux booleans (default false) drive the returned tools_to_install list: tesseract always included, adb and scrcpy when has_android is true, plink when has_linux is true. The wizard installs nothing itself; the response includes next_steps and a hint to run sassy_setup_tools(action=install_required), and reloads the persona module in-process. Re-run anytime to update the profile. The result includes a persona_backup field with the backup path (null on first run).

Input Schema

TableJSON Schema

Name	Required	Default
`role`	No	developer
`notes`	No
`systems`	No
`projects`	No
`has_linux`	No
`languages`	No
`frameworks`	No
`has_android`	No
`mcp_clients`	No
`expertise_level`	No	senior
`specializations`	No
`security_posture`	No	standard
`communication_style`	No	terse

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_wizardOutput"New value: +"sassy_setup_wizardDictOutput"

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?

Beyond the destructiveHint annotation, the description discloses the exact file path, the one-deep .bak backup behavior, overwrite semantics, in-process persona module reload, and the fact that no external tools are installed. It also reveals state changes such as marking setup_complete and the persona_backup field, which is far more transparent than annotations alone.

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 dense but high-signal, front-loading the mutation and file target. Some default values are repeated from the schema, and the long parameter list would be easier to scan as bullets, but every sentence adds meaningful information and none is wasted.

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?

Given 13 parameters, no schema descriptions, a destructive mutation, and a rich output schema, the description covers the essential contextual ground: backup behavior, rerun safety, no-install semantics, and key return fields. The existing output schema handles return-value details, so nothing critical is missing.

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?

With 0% schema description coverage, the description carries the full burden of explaining 13 parameters. It enumerates enum choices and defaults for role, expertise_level, communication_style, and security_posture; specifies comma-separated vs newline-separated input formats; and explains how has_android and has_linux conditionally drive the tools_to_install list. This is exactly the semantic depth an agent needs.

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 names a specific action and resource: it 'writes the user profile to ~/.sassymcp/persona.md' and marks setup_complete in config. It also distinguishes itself from installation/setup siblings by explicitly stating the wizard installs nothing itself and that sassy_setup_tools should be run for installs.

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 clearly identifies this as a first-run questionnaire and says it can be re-run anytime to update the profile. It also states what it does not do ('installs nothing itself') and points to the specific alternative, sassy_setup_tools(action=install_required), giving the agent an explicit when/when-not guideline.

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

Deploy Server