Skip to main content
Glama

Read one document of any type

get-document
Read-onlyIdempotent

Retrieve any Foundry VTT document by UUID or type and ID, selecting only needed fields or handling large documents via chunked responses.

Instructions

Generic fallback: read one document of any type by uuid, or by documentType and id (with parentUuid for an embedded document, pack for a compendium), whole or only the given fields. A large answer comes in parts: call again with chunkStart and the fingerprint of the first part and join the parts. embedded "summary" shortens embedded collections to ids and names. Prefer get-character, get-current-scene, get-roll-table, get-compendium-item and get-token-details where they fit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoId of the document, together with documentType
packNoCompendium id "package.name" to read from; compendiums are read only here
uuidNouuid of the document, e.g. "Actor.abc", "Scene.abc.Token.def", "Compendium.dnd5e.monsters.Actor.abc"
fieldsNoDotted paths to return, list positions as ".0" or "[0]" and "*" for every entry, e.g. "system.attributes.hp.value", "items.*.name". ["*"] returns all data
embeddedNoEmbedded documents in full or as ids and names; default include
maxCharsNoCharacter budget of the answer, 1000 to 200000; default 60000
chunkStartNoCharacter position to continue from, from the previous part
parentUuidNouuid of the document that holds an embedded one, e.g. "Actor.abc" for its items, "Scene.abc" for its walls
fingerprintNoFingerprint of the first part, so a change in between is noticed
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

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds genuinely new behavior beyond annotations: large answers come in parts requiring a second call with chunkStart and fingerprint, and embedded 'summary' shortens embedded collections to ids and names. No contradiction with annotations.

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?

Three sentences with no filler; each sentence earns its place. It front-loads 'Generic fallback', then covers identification, field selection, chunking behavior, embedded summaries, and preferred alternatives. Nothing is redundant.

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 10-parameter tool with no output schema, the description covers identification modes, partial field selection, chunked responses, embedded summary behavior, and routing to specialized tools. Minor gaps remain, such as not explicitly stating that at least one identifier combination is required, but the schema descriptions fill most remaining details.

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 100%, so the baseline is 3. The description adds relational meaning beyond the schema by grouping parameters into identification modes (uuid vs documentType+id with parentUuid/pack) and by explaining the chunkStart/fingerprint continuation protocol. It does not re-explain every parameter, but the schema already does that.

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 'Generic fallback: read one document of any type by uuid, or by documentType and id', giving a specific verb, resource, and two identification modes. It also names specialized siblings to prefer, so the tool is clearly distinguished from get-character, get-roll-table, and similar 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 states 'Prefer get-character, get-current-scene, get-roll-table, get-compendium-item and get-token-details where they fit,' which tells the agent when to use alternatives. It also clarifies the choice between uuid and documentType+id, including parentUuid for embedded documents and pack for compendiums.

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