Embers: Tabletop RPG Toolkit

Change a campaign's party order

play_update_campaign_party_order

Make one change to a campaign's Party Order (marching order or watches) and get the saved order back in the play_get_campaign_party_order shape. One op per call; make several calls for several changes. Ranks, positions, and watches are numbered from 1. A character must be in the campaign (any seat, active or inactive) to be placed or assigned. Caller must be the campaign's GM or an accepted player; watchers and pending invitees get 403.

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": {
      "campaignId": "<campaignId>",
      "op": "<op>"
    },
    "name": "play_update_campaign_party_order"
  }
}

Input Schema

Name	Required	Description
`op`	Yes	The one change to make. addRank: add an empty rank at the back. removeRank (rank): remove that rank and the characters in it. placeCharacter (characterId, rank, optional position): put the character in that rank at that position (default: the end of the rank), moving it there if it already stands elsewhere in the marching order. removeCharacter (characterId): take the character out of the marching order. setWatchCount (count, 1-12): raise or lower the number of watches; lowering drops the last watches and who was on them. assignWatch (watch, characterId, optional fromWatch): put the character on that watch (a character may stand several watches); with fromWatch, take it off that watch in the same change, moving it. unassignWatch (watch, characterId): take the character off that watch.
`rank`	No	Rank number, 1 = the front rank.
`count`	No	Number of watches, 1-12. setWatchCount only.
`watch`	No	Watch number, 1 = the first watch.
`position`	No	Place within the rank, 1 = leftmost. placeCharacter only; omit to add at the end.
`fromWatch`	No	assignWatch only: the watch the character leaves, to move it from one watch to another in one change.
`campaignId`	Yes	Campaign id.
`characterId`	No	Vault character id: the `_id` of a row from play_list_campaign_characters. The character must be in the campaign.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the annotations, the description discloses the permission model with a specific failure mode (403 for watchers and pending invitees), the 1-based numbering convention for ranks/positions/watches, the precondition that a character must be in the campaign in any seat, and that the full saved order comes back. It also surfaces data-loss behavior (removeRank "remove that rank and the characters in it", lowering watch count "drops the last watches and who was on them"), which is real value even though it sits in mild tension with destructiveHint=false since those effects are subtractive within the party-order structure.

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?

Four sentences, front-loaded with what the tool does and its return contract, then call-cardinality, indexing convention, membership precondition, and authorization in descending order of importance. No sentence restates the name or wastes words; the detailed per-op explanation lives in the schema where it belongs.

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

Completeness5/5

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

With an output schema present the description need only point at the return shape, which it does via play_get_campaign_party_order, and 100% schema coverage handles argument detail. The remaining agent-critical unknowns — permissions, error behavior, indexing base, and character-eligibility — are all stated, so nothing needed to call this correctly is absent.

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 100%, so the schema already documents every parameter and the per-op argument mapping, making 3 the baseline. The description adds only cross-cutting semantics on top: 1-based numbering for ranks, positions, and watches, plus the membership precondition on characterId. Useful, but not a meaningful expansion over the schema's own op documentation.

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 opening sentence states a specific verb ("Make one change"), the exact resource (a campaign's Party Order, parenthetically defined as marching order or watches), and the return payload (the saved order in the play_get_campaign_party_order shape). This cleanly separates it from its read-only sibling play_get_campaign_party_order without requiring the agent to open either schema.

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?

"One `op` per call; make several calls for several changes" gives concrete usage mechanics, and the permission sentence ("Caller must be the campaign's GM or an accepted player; watchers and pending invitees get 403") tells the agent who can invoke it. What is missing is an explicit pointer telling the agent to read state first via play_get_campaign_party_order rather than mutating blind; the return-shape reference implies it but never says it.

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

All Embers: Tabletop RPG Toolkit 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?