Embers: Tabletop RPG Toolkit

Update a play campaign

play_update_campaign

Idempotent

PUT updates to one campaign by id. Caller must be the campaign's owner, an admin with Admin Mode on, or the campaign's GM (an accepted gamemaster). Play writes only name, summary, description, image, public, hideSections, dismissedSessionZeroNudge, xCardEnabled, and showCreatureDetails, plus active for the owner or an admin with Admin Mode on, and ignores any other field; seats change only through the invite tools; making the campaign public needs Premium, VIP, or admin. Only supplied fields are sent. legs is NOT writable here (it is stripped): add a leg with play_add_campaign_leg, toggle one with play_set_campaign_leg_active, and change a leg's contents with the add/remove rule/item/spell/character tools. REQUIRES baseUpdatedAt: copy updatedAt from a fresh play_get_campaign read; a stale or fabricated value is rejected with OUT_OF_SYNC and nothing is written.

Input Schema

Name	Required	Description
`id`	Yes	Mongo `_id` of the campaign.
`name`	No	Campaign name.
`image`	No	Image URL. Stored as a plain string.
`active`	No
`public`	No	Whether non-members can see the campaign. Making the campaign public needs Premium, VIP, or admin.
`summary`	No	Short campaign summary. Max 150 characters.
`description`	No	Full campaign description. Markdown supported.
`hideSections`	No
`xCardEnabled`	No
`baseUpdatedAt`	Yes	REQUIRED proof that you are working from the latest version: copy the `updatedAt` value verbatim from a FRESH read of this exact record (use the matching get tool first). Values from memory, from an earlier conversation, or guessed timestamps are rejected with OUT_OF_SYNC and nothing is written. After a successful update, the response carries the new `updatedAt` — use that for any follow-up write.
`showCreatureDetails`	No	Whether players see a creature's details (its health and armor class, per ruleset) at the top of a token's details on the campaign's battlemaps. A battlemap shows them only when every one of its campaigns has this on. Off by default.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / showCreatureDetails

Added value: +{
+  "description": "Whether players see a creature's details (its health and armor class, per ruleset) at the top of a token's details on the campaign's battlemaps. A battlemap shows them only when every one of its campaigns has this on. Off by default.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 15, 2026

changedInput schema / properties / public / description

Previous value: -"Whether non-members can see the campaign."New value: +"Whether non-members can see the campaign. Making the campaign public needs Premium, VIP, or admin."

removedInput schema / properties / sessions

Removed value: -{
-  "items": {
-    "description": "Mongo `_id` reference (24-character hex string).",
-    "minLength": 1,
-    "type": "string"
-  },
-  "type": "array"
-}

Changed14 schema fields changedSep 25, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

addedInput schema / additionalProperties
```
Added value: +{}
```
addedInput schema / properties / active
```
Added value: +{
+  "type": "boolean"
+}
```

addedInput schema / properties / baseUpdatedAt

Added value: +{
+  "description": "REQUIRED proof that you are working from the latest version: copy the `updatedAt` value verbatim from a FRESH read of this exact record (use the matching get tool first). Values from memory, from an earlier conversation, or guessed timestamps are rejected with OUT_OF_SYNC and nothing is written. After a successful update, the response carries the new `updatedAt` — use that for any follow-up write.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / description

Added value: +{
+  "description": "Full campaign description. Markdown supported.",
+  "type": "string"
+}

addedInput schema / properties / hideSections

Added value: +{
+  "additionalProperties": {},
+  "properties": {
+    "characters": {
+      "type": "boolean"
+    },
+    "logistics": {
+      "type": "boolean"
+    },
+    "players": {
+      "type": "boolean"
+    },
+    "rules": {
+      "type": "boolean"
+    },
+    "safetyTools": {
+      "type": "boolean"
+    },
+    "sessionZero": {
+      "type": "boolean"
+    },
+    "sessions": {
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / id

Added value: +{
+  "description": "Mongo `_id` of the campaign.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / image

Added value: +{
+  "description": "Image URL. Stored as a plain string.",
+  "type": "string"
+}

addedInput schema / properties / name

Added value: +{
+  "description": "Campaign name.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / public

Added value: +{
+  "description": "Whether non-members can see the campaign.",
+  "type": "boolean"
+}

addedInput schema / properties / sessions

Added value: +{
+  "items": {
+    "description": "Mongo `_id` reference (24-character hex string).",
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / summary

Added value: +{
+  "description": "Short campaign summary. Max 150 characters.",
+  "maxLength": 150,
+  "type": "string"
+}

addedInput schema / properties / xCardEnabled
```
Added value: +{
+  "type": "boolean"
+}
```

addedInput schema / required

Added value: +[
+  "id",
+  "baseUpdatedAt"
+]

First observedSep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes far beyond the annotations (readOnly=false, idempotent=true, destructive=false): it discloses the permission model, the field whitelist with `active` restricted to owner/admin, that unknown fields are ignored, the Premium/VIP/admin gate on making a campaign public, that only supplied fields are sent, and the optimistic-concurrency contract with OUT_OF_SYNC and no write. That is substantive behavioral context the annotations cannot carry.

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?

Front-loaded with the operation, then permissions, then field scope, then the concurrency requirement – a sensible information hierarchy with no throwaway sentences. It is dense and long, with a small amount of repetition against the schema (public/Premium, baseUpdatedAt), which keeps it off a 5.

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?

For an 11-param, nested-object mutation with an output schema present, the description covers the gaps an agent needs: authorization, field whitelist, ignored fields, concurrency protocol, and the post-write updatedAt handoff for follow-up writes. Return values need not be explained because the output schema exists.

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 coverage is 73% and the description compensates well: it explains which of the 11 parameters are actually writable, that `legs` is stripped despite additionalProperties allowing it, and elaborates on baseUpdatedAt's freshness requirement. Some content (the Premium gate on `public`, the baseUpdatedAt read-first instruction) duplicates the schema descriptions, so not a perfect 5.

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?

Opens with a specific verb+resource+scope: 'PUT updates to one campaign by id.' Immediately distinguishes itself from sibling update tools (play_update_session, play_update_move, play_update_page) by naming the resource and the exact field whitelist it touches.

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

Usage Guidelines5/5

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

Explicitly states who may call it (owner, Admin Mode admin, accepted GM) and routes excluded operations to alternatives by name: legs go to play_add_campaign_leg / play_set_campaign_leg_active, seats go through the invite tools, leg contents through the add/remove rule/item/spell/character tools. An agent can determine when to use this tool and when not to without guessing.

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?