Skip to main content
Glama

Generate persona

generate_persona

Create a persona JSON pack and, when confirmed and allowed, insert it into Studio SQLite for controlled persona setup in Msty Studio.

Instructions

Build a persona JSON pack and, when gated, insert it into Studio SQLite. Use this to create a persona. Use import_studio_pack for a full pack. Always writes a pack under ~/.msty-admin/imports/. SQLite insert needs confirm=true, MSTY_ALLOW_STUDIO_WRITES=1 in the server environment, and Studio must be closed. Name max 100 characters, system prompt max 20000. Returns JSON with pack_path and wrote.

Input Schema

NameRequiredDescriptionDefault
nameYesPersona name. 1 to 100 characters. Must be unique in Studio.
modelYesLocal model name to associate, for example llama3.2:3b. Used for partialModelInfo lookup only.
confirmNoSet true to insert into Studio after a backup. Default false (pack only).
system_promptYesSystem prompt text. 1 to 20000 characters. Stored as JSON with mode append unless you ask for replace via import_studio_pack.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv6.2.1
    • addedInput schema / properties / confirm / description
      Added value: +"Set true to insert into Studio after a backup. Default false (pack only)."
    • addedInput schema / properties / model / description
      Added value: +"Local model name to associate, for example llama3.2:3b. Used for partialModelInfo lookup only."
    • addedInput schema / properties / name / description
      Added value: +"Persona name. 1 to 100 characters. Must be unique in Studio."
    • addedInput schema / properties / system_prompt / description
      Added value: +"System prompt text. 1 to 20000 characters. Stored as JSON with mode append unless you ask for replace via import_studio_pack."
  2. Changed1 schema field changedv6.2.0
    • addedInput schema / properties / confirm
      Added value: +{
      +  "default": false,
      +  "title": "Confirm",
      +  "type": "boolean"
      +}
  3. First observedv5.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond annotations by disclosing the always-write side effect to ~/.msty-admin/imports/, the three gating prerequisites for the SQLite insert, and the backup-before-insert behavior. Annotations only supply the coarse hints (writes, not destructive); the description supplies the operational detail an agent needs.

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?

Front-loads the core action, then the alternative, then side effects, then gating, then return shape – a logical order with no filler. Every sentence carries information.

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?

Covers the two-mode behavior, prerequisites, side effects, and even the return keys, which is more than sufficient given an output schema also exists. Nothing needed to invoke it safely 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?

Schema coverage is 100%, so the baseline is 3; the description still adds value by tying confirm=true to the env-var and 'Studio must be closed' preconditions and noting name/system_prompt length limits. The model parameter's 'partialModelInfo lookup only' nuance stays in the schema rather than the description.

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?

States a specific verb and resource ('Build a persona JSON pack and, when gated, insert it into Studio SQLite') with its dual-mode behavior. It explicitly distinguishes itself from the sibling import_studio_pack, which handles full packs.

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?

Names the condition for the insert path (gated, confirm=true plus env var and Studio closed) and routes the full-pack case to import_studio_pack. The 'use this to create a persona' line removes ambiguity about when to pick it.

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