Skip to main content
Glama

Set up world Status

set_world_status
DestructiveIdempotent

Set up or change a world's Status: the values characters have, who is left out, and the window look. For a relationship, name the one bond the story is about (Trust, Love, Friendship, Rivalry, Respect or Fear, 0 to 10, appliesTo others) with a precise changesWhen; one or two bonds track better than many. Only the parts you send change. fields replaces the whole list (send every value you keep, with its id). Every character of the world has the values, plus the player's character, unless their id is in excludedIds. remove: true takes Status out of the world. Every story of the world uses the new setup from its next reply; each story keeps its own numbers. No AI writes anything here.

Input Schema

NameRequiredDescriptionDefault
lookNoHow the status window looks in the story: board = a game status board, profile = a character card.
slugNo
fieldsNoAt most 6 values. A value plays only with a name and a changesWhen line.
removeNotrue takes Status out of this world.
worldIdNoWorld id from list_worlds.
excludedIdsNoCharacters left out (characterId from get_world_status; "hero" is the player's character). [] gives everyone the values.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / fields / items / properties / start / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the destructiveHint/idempotentHint annotations, it discloses the exact blast radius: 'fields replaces the whole list (send every value you keep, with its id)', 'Only the parts you send change', and that every story of the world adopts the new setup on its next reply while keeping its own numbers. That is precisely the kind of mutation semantics an agent needs before overwriting a shared schema.

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?

Purpose is front-loaded in the first clause, and nearly every sentence adds a distinct operational fact (merge semantics, exclusion, cross-story effect). It is a dense, comma-spliced single paragraph that could be broken into bullets for faster scanning, which keeps it from a 5.

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 6-parameter mutation tool with no output schema, the description covers the consequential behavior: replacement semantics, character coverage and exclusions, removal, and downstream effect on existing stories. It does not say what the call returns or confirm there are no required parameters, a small residual gap.

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?

With 83% schema coverage the schema carries most of the load, but the description adds real meaning: it explains the patch-vs-replace semantics of fields, the role of id in preserving story numbers, the appliesTo 'others' pattern for relationship bonds, and the exclusion behavior via excludedIds. The numeric range hint (0–10) is the only place it partially duplicates the schema's min/max.

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?

States a specific verb and resource — configure a world's Status schema (values, exclusions, window look) — and the scope sentence about all stories reusing the setup makes clear this is world-level, not per-story. It never names the sibling tools it differs from (get_world_status, set_status_start), so it stops short of explicit differentiation.

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?

Gives clear context for when to call it (setting up or changing a world's Status, including removal via remove: true) and even tuning advice such as 'one or two bonds track better than many' with a precise changesWhen. It lacks explicit when-not guidance or named alternatives, so it sits below a 5.

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.

Resources