Skip to main content
Glama
rbilleci

bsh-mcp

by rbilleci

scene_commit

Persist campaign scene changes so discoveries, movements, and secrets survive a restart. Use it after key events to update visible facts, hidden changes, clocks, and present characters.

Instructions

Commit a durable fictional change to the campaign files.

Call this after the party discovers an entrance, alarms a faction, moves to a new location, learns a secret, or changes the situation in a way that must survive a restart.

visible_changes records what the party knows, including the party's own secret actions: a hiding place the party made is the party's knowledge, not a game-master secret, even when the scene hides it from others. hidden_changes records only facts the party does not know. Filing a party action as hidden makes the game master unable to answer the party about their own deed.

This tool never changes hit points, Doom, inventory, or any other mechanic that belongs to a dedicated tool.

new_clocks entries take the form {"id": "tide", "name": "The tide", "segments": 6}. clock_updates maps a clock id to a signed segment change.

environment_tags replaces the scene's open-vocabulary descriptors (e.g. "natural", "urban") when passed; omit it to leave the current tags unchanged. Some backgrounds' rest-time mechanics read these -- e.g. a Herbalist's stock only replenishes on a long rest whose scene carries "natural". Tag the scene here before that rest happens, not as an argument to rest.

persons records people present who have no NPC record yet -- a clerk, a trader, someone the party only talks to. Each entry takes the form {"name": "Salt Magistrate clerk", "role": "counts barrels for the Magistrates"}; role is optional. The server allocates the id from the name, so the same name later names the same person, and npc_create on that name promotes the person to a full NPC when a fight needs one. Pass present_npcs, not persons, for anyone npc_create already created. departed_persons names persons who have left the scene, by the same name; a move to a new location_id already takes every person and every located NPC of the old scene with it.

refs optionally lists the recorded identifiers this commit's changes are about (characters, NPCs, persons, objects); unknown identifiers are dropped. retire_facts removes a fact that is no longer true from the visible record: quote the line exactly as the Visible facts list states it. The fact stays in the campaign's history; it simply stops being current.

party_secrets records knowledge the party holds that the world's people do not -- a hiding place the party made, a plan they whispered. It is the party's own knowledge: answer the party about it freely, and never treat it as a game-master secret. hidden_changes remains only for facts the party does not know.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refsNo
exitsNo
personsNo
new_hooksNo
new_clocksNo
location_idNo
scene_titleNo
present_npcsNo
retire_factsNo
clock_updatesNo
party_secretsNo
hidden_changesNo
public_summaryYes
resolved_hooksNo
visible_changesNo
departed_personsNo
environment_tagsNo
in_game_time_delta_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains side effects: durable changes to campaign files, the distinction between visible_changes, hidden_changes, and party_secrets, the fact that retire_facts stops a fact from being current but keeps it in history, and how persons are allocated IDs and can be promoted via npc_create. It also clarifies that party_secrets are the party's own knowledge and should be answered freely. This is comprehensive and transparent.

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?

The description is long (~350 words) but every sentence adds value. It is well-structured with paragraphs for each concept, front-loading the purpose and when-to-call instructions. There is slight redundancy: party_secrets vs hidden_changes is explained twice, once in the visible_changes paragraph and again in the party_secrets paragraph. This could be consolidated, but the overall structure is logical and the length is justified by the tool's complexity.

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 a tool with 18 parameters, no annotations, and no output schema, the description is remarkably complete. It covers the purpose, usage conditions, all major parameter semantics, interactions with other tools (npc_create, rest), and the distinction between party knowledge and hidden facts. The only missing elements are the semantics of a few less-critical parameters (exits, new_hooks, resolved_hooks, in_game_time_delta_minutes), but these are either self-explanatory or have defaults. An agent would be able to call this tool correctly in nearly all scenarios based on this description alone.

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?

The schema has 18 parameters with 0% description coverage, so the description must compensate. It does an excellent job for the most critical parameters: visible_changes, hidden_changes, party_secrets, new_clocks (with format), clock_updates (mapping to signed segment changes), environment_tags (replaces tags, affects rest mechanics), persons (with role optional), departed_persons, refs, retire_facts (exact quoting), and present_npcs (contrasted with persons). However, it leaves exits, new_hooks, resolved_hooks, in_game_time_delta_minutes, and scene_title unexplained. Given the high parameter count and zero schema coverage, this is a minor gap but prevents a perfect score.

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 description opens with a specific verb and resource: 'Commit a durable fictional change to the campaign files.' It immediately lists concrete triggering events (discovering an entrance, alarming a faction, moving to a new location, learning a secret) and explicitly states what the tool does NOT do ('never changes hit points, Doom, inventory...'), which distinguishes it from sibling tools like combat_start, inventory_update, and rest. This is a clear, unambiguous purpose that an agent can act on.

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?

The description provides explicit when-to-use guidance ('Call this after the party discovers an entrance...') and when-not-to-use guidance ('This tool never changes...'). It also gives detailed routing instructions: 'Pass present_npcs, not persons, for anyone npc_create already created,' and notes that a move to a new location_id automatically carries persons and located NPCs. It even explains the timing for environment_tags relative to rest mechanics. This is exemplary usage guidance.

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