Kuro

Update a subject

update_subject

DestructiveIdempotent

Change what a subject is or how it is described, bind the voice it speaks in, and push a new identity image onto it. canonical makes that image the one that travels — this is how a subject gets stronger with use: generate, promote the best result, and the next generation is better.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No
`name`	No
`tags`	No	The same tags the account puts on its work, so one tag can group a client's people and products beside what was made of them. Replaces the whole list — send the tags it should end up with.
`cover`	No	The wide one, behind the name on its card. Null takes it off.
`sheet`	No	A character sheet for a person to read: hero pose, turnaround, palette. Held for a reader and never seated as a model reference — seating a collage teaches the model to render the collage. Null takes it off.
`voice`	No	The voice this subject speaks in — cast_voice reads a portrait and returns ids to choose from. Null unbinds it.
`avatar`	No	The small round one — a shelf, a rail, a tag. Null takes it off.
`favorite`	No
`canonical`	No	True promotes `add_identity` to the face that travels.
`subject_id`	Yes
`description`	No
`add_identity`	No	A generation or upload to add to the identity strip.
`prompt_fragment`	No	The words that travel into every prompt this subject is tagged into. Null clears them.
`remove_identity`	No	A media object id from the subject's identity strip (get it from list_subjects), taken off the strip.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`message`	Yes
`subject`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedInput schema / properties / tags / description

Previous value: -"Replaces the whole list — send the tags it should end up with."New value: +"The same tags the account puts on its work, so one tag can group a client's people and products beside what was made of them. Replaces the whole list — send the tags it should end up with."

First observedOct 15, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare idempotentHint=true and destructiveHint=true, so the safety profile is covered structurally. The description adds the conceptual consequence of `canonical` (the promoted image is 'the one that travels') and the iterative-quality rationale, but says nothing about permissions, what destructive edits overwrite, or behavior on partial updates.

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?

Two sentences, front-loaded with the core purpose and the three change categories. The second sentence is motivational rationale rather than operational detail, but it is short and justifies the `canonical` parameter, so it mostly earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 parameters, a destructive edit hint, and an output schema (so return values needn't be explained), the description frames the tool conceptually but omits practical update semantics: whether unspecified fields are left unchanged and how identity add/remove, tags replacement, and null-clearing interact. Adequate but incomplete for a tool of this breadth.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 64%, and the description contributes almost no parameter-specific detail beyond restating `canonical`/identity-image behavior already documented in the schema. High-value fields like tags (whole-list replacement), voice, and add_identity/remove_identity get no added meaning from the prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb ('Change') plus resource ('a subject') and enumerates the three categories of change: descriptive fields, voice binding, and pushing a new identity image. 'Update' vs 'create/delete' is inferable from the verb, but no sibling is named to sharpen the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the canonical workflow ('generate, promote the best result') which implies when to use this tool for identity promotion, but it never states when to use update_subject rather than create_subject, cast_voice, or save_subject_performances. Usage is implied rather than explicit.

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

All Kuro tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?