Skip to main content
Glama
Sign In

Kuro

by com.meetkuro.api
OverviewDiscussionsAdmin

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subject_id": "<subject_id>"
    },
    "name": "update_subject"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
nameNo
tagsNoThe 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.
coverNoThe wide one, behind the name on its card. Null takes it off.
sheetNoA 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.
voiceNoThe voice this subject speaks in — cast_voice reads a portrait and returns ids to choose from. Null unbinds it.
avatarNoThe small round one — a shelf, a rail, a tag. Null takes it off.
favoriteNo
canonicalNoTrue promotes `add_identity` to the face that travels.
subject_idYes
descriptionNo
add_identityNoA generation or upload to add to the identity strip.
prompt_fragmentNoThe words that travel into every prompt this subject is tagged into. Null clears them.
remove_identityNoA media object id from the subject's identity strip (get it from list_subjects), taken off the strip.

Output Schema

NameRequiredDescriptionDefault
messageYes
subjectYesSomeone or something you make again and again. Name it in `subjects` and Kuro brings its face and description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changed
    • addedOutput schema / properties / subject / description
      Added value: +"Someone or something you make again and again. Name it in `subjects` and Kuro brings its face and description."
    • addedOutput schema / properties / subject / properties / app_url / $ref
      Added value: +"#/properties/subject/properties/preview_url/anyOf/0"
    • removedOutput schema / properties / subject / properties / app_url / format
      Removed value: -"uri"
    • removedOutput schema / properties / subject / properties / app_url / type
      Removed value: -"string"
    • addedOutput schema / properties / subject / properties / created_at
      Added value: +{
+  "format": "date-time",
+  "type": "string"
+}
    • addedOutput schema / properties / subject / properties / has_voice
      Added value: +{
+  "description": "Whether a voice is bound to it, for voice-overs.",
+  "type": "boolean"
+}
    • addedOutput schema / properties / subject / properties / id
      Added value: +{
+  "format": "uuid",
+  "type": "string"
+}
    • addedOutput schema / properties / subject / properties / identity_images / description
      Added value: +"How many reference pictures travel with it. Zero: it travels as words alone."
    • changedOutput schema / properties / subject / properties / identity_images / type
      Previous value: -"number"New value: +"integer"
    • addedOutput schema / properties / subject / properties / kind / description
      Added value: +"\"character\", \"location\", \"product\", \"prop\" or \"wardrobe\". New values may be added."
    • removedOutput schema / properties / subject / properties / kind / enum
      Removed value: -[
-  "character",
-  "location",
-  "product",
-  "prop",
-  "wardrobe"
-]
    • addedOutput schema / properties / subject / properties / object
      Added value: +{
+  "const": "subject",
+  "type": "string"
+}
    • removedOutput schema / properties / subject / properties / subject_id
      Removed value: -{
-  "format": "uuid",
-  "type": "string"
-}
    • changedOutput schema / properties / subject / required
      Previous value: -[
-  "subject_id",
-  "name",
-  "kind",
-  "description",
-  "prompt_fragment",
-  "identity_images",
-  "identity_object_ids",
-  "voice",
-  "tags",
-  "favorite",
-  "preview_url",
-  "appearance_count",
-  "subject",
-  "app_url"
-]New value: +[
+  "object",
+  "id",
+  "name",
+  "kind",
+  "description",
+  "identity_images",
+  "has_voice",
+  "tags",
+  "preview_url",
+  "created_at",
+  "app_url",
+  "prompt_fragment",
+  "identity_object_ids",
+  "voice",
+  "favorite",
+  "appearance_count",
+  "subject"
+]
  2. Changed1 schema field changed
    • 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."
  3. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is carried structurally. The description adds real behavioral context beyond that: what `canonical` promotes and the generate-promote loop that makes a subject improve. But it never states that omitted fields are left unchanged, that images are added to an identity strip versus replaced, or what happens on an unknown or archived subject — notable gaps for a destructive 14-parameter mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, which is good structure. But the phrasing is impressionistic ('push a new identity image onto it', 'the one that travels', 'stronger with use'), so space that could have documented the destructive semantics is spent on metaphor without adding callable detail.

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 an output schema present, return values need not be described, and annotations cover safety. Still, a destructive 14-parameter update should clarify that this is a partial update (unset fields untouched), that nulls explicitly clear fields, and that identity images are appended/removed rather than overwritten. The description covers the headline and the `canonical` mechanic but leaves those mechanics to the schema.

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 64%, with informative descriptions on `tags` (full replacement), `sheet`, `voice`, `remove_identity`, and `prompt_fragment`. The description only adds semantics for `canonical` and `add_identity` (promotion of the traveling face); it says nothing about `favorite`, `cover`, `avatar`, `name`, or `kind`, leaving several parameters to the schema alone. That is an acceptable baseline but not compensating for the coverage gap.

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 states a clear verb and resource: change a subject's kind/description, bind its voice, and attach a new identity image. It also explains the `canonical` concept, which is the tool's distinctive behavior. It does not explicitly distinguish itself from `create_subject` or `delete_subject`, though the update framing makes the distinction largely self-evident.

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?

The second sentence sketches a usage pattern (generate, promote the best result via `canonical`, regenerate) which is genuinely helpful workflow guidance. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of the sibling tools that create or remove subjects, and no stated prerequisites such as obtaining `subject_id` or identity media ids. Usage is implied rather than spelled out.

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

All Kuro toolsInspect
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