Skip to main content
Glama

AgentPlaybooks

by ai.agentplaybooks

Create persona

create_persona
DestructiveIdempotent

Set the playbook's singleton persona name and system prompt. This does not add a second persona; it is a backward-compatible alias that overwrites those fields. Requires personas:write or full permission. Prefer update_persona to change a subset of fields. Use update_playbook only when you also need playbook name, visibility, config, or project instructions. Do not use delete_persona unless you intend to reset to the default Assistant.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the persona
metadataNoOptional metadata
playbook_idYesUUID of the playbook
system_promptYesThe system prompt that defines this persona's behavior

TDQS

A4.5/5.0
Behavior4/5

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

The description goes beyond the annotations by clarifying the tool's behavior: 'This does not add a second persona; it is a backward-compatible alias that overwrites those fields.' This adds important context about side effects (overwriting) and the alias nature, which is not fully captured by the annotations alone. The permission requirement is also disclosed. No contradiction with annotations.

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 concise and well-structured: a single focused opening sentence, followed by clarifications and usage alternatives. Each sentence adds value, and there is no fluff or repetition.

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?

The description covers the tool's purpose, behavioral details, permission requirements, and clear distinctions from related tools. Given the rich annotations and complete schema, this description is fully sufficient for an agent to decide when and how to use it.

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

Parameters3/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 implies the roles of name, system_prompt, and playbook_id through its main clause, but does not add detailed parameter-level semantics beyond the schema. Since the schema is thorough, this is adequate.

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 clearly states the tool's purpose: 'Set the playbook's singleton persona name and system prompt.' It specifies the exact resources affected and explicitly differentiates from sibling tools like update_persona and update_playbook, leaving no ambiguity about what this tool does.

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?

Provides explicit usage guidance: 'Prefer update_persona to change a subset of fields' and 'Use update_playbook only when you also need playbook name, visibility, config, or project instructions.' It also warns against delete_persona unless resetting, and states the required permission level. This is exemplary decision-support.

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

All AgentPlaybooks toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct entity and action (e.g., delete_memory vs delete_skill vs delete_run), and even similar operations like read_memory vs search_memory vs get_memory_context have clearly differentiated purposes. The descriptions are detailed and explicitly cross-reference other tools to avoid confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (create_*, list_*, update_*, delete_*, read_*, etc.), with plurals used uniformly for list operations (list_playbooks, list_runs, list_secrets). No mixed conventions or ambiguous verbs; the naming is highly predictable and systematic.

Tool Count4/5

With 48 tools, the server covers a broad but coherent set of domains (playbooks, personas, skills, memory, canvas, runs, secrets, MCP servers, and discovery). While this exceeds the typical 3-15 range, each tool serves a distinct and necessary function within the comprehensive playbook management scope, so the count feels justified rather than bloated.

Completeness5/5

The tool surface provides complete CRUD and lifecycle coverage for every entity type: playbooks, personas, skills (including versioning and rollback), memory (including hierarchical tasks and tiering), canvas (with locking and patching), runs, secrets (including rotation and usage), and MCP servers. Additionally, find_tools covers discovery for federated tools, leaving no apparent dead ends.

Resources