Skip to main content
Glama
SpirrowGames

spirrow-prismind

Official
by SpirrowGames

upsert_identity

Create or update an identity record to persist allowed roles, independence class, and persona description, enabling persona continuity across projects.

Instructions

Create or update an identity record (cross-project actor declaration). Identity records persist allowed_roles / independence_class / persona_description in a key space separate from session state (prismind:identity:{user}:{identity_name}), realizing ADR-2026-05-27-09 D-3's persona-continuity gate at the API level. identity_name is the same string SessionState.author uses; list_context_authors joins the identity record onto each author entry so callers see allowed_roles in one round-trip. independence_class is required on every upsert (re-declared, not preserved) -- this is the '書き忘れ不能' guarantee. allowed_roles is required unless keep_allowed_roles=True. persona_description defaults to preserve-on-omit. embodiment is DEPRECATED (ADR-2026-05-29-12); runtime self-declared via the five APIs on Magickit (checkpoint/resume/chatroom_*). Pass omit or null; the field is preserved in the schema only for the staged migration window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNoOwning user (defaults to the configured user_name).
embodimentNoDEPRECATED (ADR-2026-05-29-12). Pass null or omit. Runtime form is now self-declared on the five APIs at Magickit level.
allowed_rolesNoRoles this identity may assume (e.g. ['proposer', 'reviewer']). Required unless keep_allowed_roles=True. An empty list [] is a legal explicit declaration of 'no allowed roles' (distinct from preserve -- use keep_allowed_roles=True for that). Magickit enforces; Prismind only persists.
identity_nameYesStable identity slug (e.g. 'Heisenberg'). Same value as SessionState.author.
independence_classYesActor's gating class for ADR-09 D-3. Required on every upsert.
keep_allowed_rolesNoIf true, preserve the existing allowed_roles list. Mutually exclusive with allowed_roles. Only valid when the identity already exists.
persona_descriptionNoOptional human-readable persona note. Omit to preserve the existing value.
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: persistence in a distinct key space, required re-declaration of independence_class, preservation semantics for allowed_roles and persona_description, and deprecation of embodiment with migration guidance. It clearly states the '書き忘れ不能' guarantee, which is behavior, not already present in annotations.

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 and front-loaded with the core purpose, with each sentence conveying a distinct piece of behavioral or semantic information. While somewhat lengthy and technically terse (ADR references), it is appropriately sized for a tool with 7 parameters and complex update semantics, containing no wasted words.

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 no output schema and no annotations, the description covers the essential behavioral context: key space, required fields, preservation defaults, deprecation, and relation to list_context_authors. It does not explicitly discuss return values or error conditions, but for a tool with this complexity, the narrative is complete enough for correct invocation.

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%, but the description adds meaning beyond the schema by explaining the 're-declared, not preserved' guarantee for independence_class, the distinction between empty list [] and preserve for allowed_roles, and the deprecated embodiment's schema-only retention. These enrich the bare schema definitions.

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: 'Create or update an identity record (cross-project actor declaration)'. It clearly distinguishes this from read-only siblings like get_identity and list_context_authors by centering on creation/update semantics and persistent storage.

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 provides clear context on when to use this tool, including the relationship to SessionState.author and mentions that list_context_authors joins the identity record for one-round-trip reads. It does not explicitly contrast with get_identity, but the provided context and parameter interaction guidance (required fields, preservation defaults) sufficiently imply usage.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SpirrowGames/spirrow-prismind'

If you have feedback or need assistance with the MCP directory API, please join our Discord server