Skip to main content
Glama

Change a document of any type

update-document
DestructiveIdempotent

Modify fields of any Foundry VTT document using dotted paths or merge rules, with dry-run preview and rollback-safe changes.

Instructions

Generic fallback: change fields of one document of any type. changes follows Foundry's update rules: keys may be dotted paths, an object merges into the object that is there, lists and other values replace it. A list position in a key ("system.skills.2.value") changes only that entry. replace names keys of changes whose object replaces the stored object instead of merging; remove names paths to delete. The answer is the change as read back from Foundry, and what was stored differently. Ids, ownership, _stats, the type, embedded collections, the flags of this module and what a specialised tool guards (active scene, playback, chat recipients, macro commands) cannot be changed here. Use dryRun first. Prefer update-scene, manage-actors, journal-set-page, update-token, update-roll-table, manage-effects and the other specialised tools where they fit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoId of the document, together with documentType
uuidNouuid of the document, e.g. "Actor.abc", "Scene.abc.Token.def", "Compendium.dnd5e.monsters.Actor.abc"
dryRunNoOnly check and preview; nothing is written. Recommended before the real call
removeNoField paths to delete: a key, or a list entry such as "system.skills.1"
changesNoChanges by field, e.g. { "system.attributes.hp.value": 7, "name": "Grok" }
replaceNoKeys of changes whose object replaces the stored object instead of merging
parentUuidNouuid of the document that holds an embedded one, e.g. "Actor.abc" for its items, "Scene.abc" for its walls
documentTypeNoFoundry document name, e.g. "Actor", "JournalEntryPage", "Combat", "Wall"; with id when no uuid is given

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv14.2609.4

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description thoroughly discloses mutation semantics: dotted-path keys, object merge vs. list replacement, replace and remove behavior, and the exact restricted fields (IDs, ownership, _stats, type, embedded collections, module flags). It also tells the agent what the response contains, compensating for the missing output schema. The description does not contradict the annotations; it aligns with destructiveHint and adds safety guidance.

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?

The description is long by necessity for a generic generic tool, but every sentence earns its place. It front-loads purpose and scope, then explains rules, restrictions, response, and selection guidance.

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 8-parameter generic fallback with no output schema, the description covers purpose, behavioral nuance, forbidden fields, safe-use workflow, response shape, and alternatives. An agent can decide when to use it and how to invoke it without needing to inspect sibling tool definitions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial behavior beyond the schema: it defines Foundry update rules for changes keys, when object values merge vs. replace, how list indices in dotted paths work, and what replace/remove mean. This converts otherwise ambiguous parameters into actionable semantics.

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: "change fields of one document of any type". It positions itself as the "Generic fallback" distinct from the many specialized siblings, and it tells the agent this is not one of the specialized document tools.

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?

It explicitly names when to use the tool (generic fallback) and names the alternatives: "Prefer update-scene, manage-actors, journal-set-page, update-token, update-roll-table, manage-effects and the other specialised tools where they fit." It also gives a concrete operational rule: "Use dryRun first."

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

Deploy Server

Other Tools