Skip to main content
Glama

writeDocument

Create or replace a markdown document at a vault path, keeping full version history and turning [[wikilinks]] into graph edges. Add optional frontmatter and scope to control metadata and visibility.

Instructions

Create or replace a markdown document at path with body (stored verbatim, event-sourced — full history is kept). [[Wikilinks]] in the body resolve to canonical entities and other documents as graph edges; dangling links reconcile automatically when their target appears. Optional title/pinned/tags/frontmatter synthesize a YAML frontmatter block when the body has none. Frontmatter about: <name|entities/{uid}> records the document's primary subject as a high-confidence describes edge (distinct from body [[wikilinks]], which are mentions); resolve it by uid where you can, since a renamed subject keeps the link. Frontmatter canonical: true lets this document win name resolution over a same-named non-document entity, so a later-created entity cannot silently steal the name. The document materializes as an editable file in the vault. Idempotent: rewriting identical content is a no-op. scope picks who sees the document (personal by default; team requires membership, else E_PERMISSION) and is fixed at creation — the same path in a different scope is a separate document. Result counts (edges, unresolved, reconciled) are whole-document snapshots after the write, not deltas. A non-fatal warnings field appears when the title shadows a same-named non-document entity.

Input Schema

NameRequiredDescriptionDefault
bodyYesThe full markdown body, stored verbatim. May include its own YAML frontmatter block.
pathYesVault-relative path, e.g. notes/project-alpha.md (.md appended when no extension).
tagsNoTags, synthesized into frontmatter.
scopeNoStorage scope, fixed at creation. personal (default) = only you; project = a shared project; team = every team member (requires membership, else E_PERMISSION); draft = private staging. The same path in a different scope is a SEPARATE document.
titleNoOptional title, synthesized into frontmatter. Only when body has no frontmatter of its own.
pinnedNoPin the document (synthesized into frontmatter). Pinned documents surface first in context packs.
frontmatterNoAdditional frontmatter keys (JSON object), synthesized into a YAML block. Only when body has no frontmatter of its own.

Output Schema

NameRequiredDescriptionDefault
fileNoAbsolute path of the materialized vault file.
nameYesentities/{uid} resource name of the document-as-entity.
pathYes
edgesNoTotal resolved wikilink and frontmatter edges the whole document holds after this write (snapshot, not a delta — counts all [[links]] in the current body that resolved, regardless of how many were already in the graph).
changedYesFalse when the content matched the latest revision (no-op).
warningsNoNon-fatal advisory messages — e.g. a title-collision warning when the document's display name shadows a non-document entity. Does not affect the written content; the document body is stored byte-for-byte as supplied. Omitted when empty.
reconciledNoCount of wikilinks in OTHER vault documents that this write newly made resolvable (cross-document reconcile pass; separate from the document's own edge snapshot above).
unresolvedNoCount of [[wikilinks]] left dangling in the whole document after this write (snapshot, not a delta).
documentUidYes
pendingEditNoTrue when the vault file holds an un-ingested manual edit and was left untouched.
revisionUidNo
unresolvedTargetsNoThe dangling wikilink targets by name (text inside [[…]] that matched nothing) — fix a typo or create the target. Omitted when none dangle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations are empty, so the description carries the full burden and does so thoroughly: event-sourced full history, idempotent no-op on identical content, scope fixed at creation with a same-path/different-scope being a distinct document, E_PERMISSION on team scope, non-fatal warnings, and result counts being whole-document snapshots rather than deltas. These are exactly the traits an agent cannot infer from schema or annotations.

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?

It is a single dense paragraph of roughly 150 words, but nearly every sentence carries non-obvious semantics and the core action is front-loaded. It would read better segmented into bullets (write behavior / links / frontmatter / scope / return values), which is the only thing keeping it from 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?

An output schema exists, yet the description still notes that `edges`/`unresolved`/`reconciled` are post-write snapshots and that `warnings` is non-fatal — precisely the interpretation an agent needs. Combined with link reconciliation, idempotency, and scope rules, nothing material for correct invocation is missing.

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 earns above baseline by explaining semantics the schema cannot: frontmatter `about:` produces a high-confidence `describes` edge (distinct from `mentions` from wikilinks) and should be given by uid, while `canonical: true` makes the document win name resolution — behaviorally meaningful for a key passed inside the `frontmatter` object.

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 pair ('Create or replace a markdown document at `path` with `body`') and immediately distinguishes itself from siblings like editDocument/readDocument by the replace-in-full semantics. The scope of the write (verbatim body, synthesized frontmatter, materialized vault file) is stated concretely.

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

Usage Guidelines3/5

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

Usage is implied by 'create or replace' and by the scope semantics (personal default; team requires membership else E_PERMISSION), which helps an agent choose a scope value. However, there is no explicit guidance on when to pick writeDocument over editDocument, which is the obvious sibling for modifying an existing document, so the routing decision is left to inference.

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