Skip to main content
Glama

update_character

Idempotent

Save a character's display name and/or personality notes. Without this, a character stays 'Untitled Character' with no description even after portrait/body images exist. account must be whichever Google account's project owns this entity_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountYes
entity_idYes
display_nameNo
personality_notesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already convey mutation, idempotence, and non-destructiveness. The description adds useful behavioral context: without this call the character stays 'Untitled Character' and account must be the owning project, an access requirement not present in annotations. It doesn't explain overwrite/clearing behavior for nullable fields, but the main side effects are disclosed.

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?

Three sentences: the action, why it matters, and the account prerequisite. Each sentence adds distinct, necessary information and the main operation is front-loaded.

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?

For a simple update with only two required parameters and idempotent/non-destructive annotations, this is nearly complete: an agent can construct a correct call with entity_id, owning account, and one or both fields. It lacks explicit 'at least one optional field' guidance, but the overall context is sufficient.

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 description coverage is 0%, so the description carries the burden. It directly maps display_name and personality_notes, and explains that account must own the entity_id. All parameters get some semantic meaning, though it doesn't explain null semantics for clearing existing values.

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?

Description opens with a specific verb and resource: 'Save a character's display name and/or personality notes.' It further clarifies the purpose by describing the default 'Untitled Character' state and tying the action to an existing entity_id, which distinguishes it from the create_* sibling tools.

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?

It gives a clear trigger context: use this when you need to set a character's name or personality notes, especially after portrait/body images already exist. It also specifies the account ownership prerequisite. It does not explicitly name create_character as the alternative for new characters, so it stops short of full exclusion guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.