Skip to main content
Glama

write_page

Destructive

Create or refresh source-backed Wenlan wiki pages from conversation content, updating existing pages in place without breaking links.

Instructions

Create or refresh a wiki page. When the user asks to turn something from this conversation into a page, call write_page with a title and the content; source_memory_ids are optional. This write can replace an existing page: omit page_id to create a new page (title required); with enough cited sources it lands as a distilled page, otherwise as an authored page. The daemon writes the DB row and the on-disk /.md projection atomically (default ~/.wenlan/pages/, slug made unique on collision). Pass page_id (from the stale_pages block in distill output) to refresh that page in place — replaces content + source_memory_ids + optional summary, clears stale_reason, preserves page_id and created_at, bumps version monotonically so external [[wikilinks]] keep working. Never delete_page + recreate to refresh: that churns ids and loses version history. To change an existing page's title at the user's explicit request, use rename_page; refresh keeps the existing title. Before a refresh, read_page and pass its page.version as expected_version: if the page moved on, the write is refused with nothing changed, so re-read and retry. Without expected_version, a refresh of a page the user wrote or edited is refused the same way. A page with review_required set stages every refresh as a revision card for the user. basis [{page_id, version}] lists notes relied on (versions from read_page); a changed one lands pending (see page_basis). minor: true = small edit. code_basis [{repo_root, path, line_start, line_end}]: code lines relied on (see page_code_basis). Refresh is not available over remote HTTP MCP transport (local stdio only).

Input Schema

NameRequiredDescriptionDefault
basisNoOther notes (wiki pages) this page relies on, each as {page_id, version} where version is that note's page.version from your read_page. Use it for notes only; memories go in source_memory_ids and a note's page id never does. A listed note counts as confirmed only if it is still at that version; if it changed after your read it is recorded as pending instead. Existing bases of the page stay as they are. The reply lists the page's bases after the write.
minorNoRefresh only: true marks this write as a small edit (typo, formatting, a one-word fix), so pages relying on this one are told the change was minor. It never hides the change from them.
spaceNoTopic scope (e.g. 'origin', 'work'). Optional. Create only.
titleNoShort noun phrase that names the page (e.g. 'Wenlan daemon architecture'). Required when creating; ignored on refresh.
contentYesMarkdown body — 3-7 paragraphs of wiki prose with [[wikilinks]]. Do not cite source ids inline; pass them in source_memory_ids and the daemon attaches provenance automatically.
page_idNoOmit to create a new page. Pass an existing page id (e.g. 'page_abc', from the `stale_pages` block in distill output) to refresh that page in place.
sessionNoYour AI session as tool:id, e.g. claude-code:<session id>; links what you write back to this conversation.
summaryNoOptional one-sentence summary — the durable claim. On refresh: omit to keep the existing summary; pass empty string to clear it.
entity_idNoOptional entity_id (e.g. 'ent_abc') to anchor the page to a knowledge-graph entity. Create only.
code_basisNoLines of code this note relies on; Wenlan tells you when they change. Each entry is {repo_root, path, line_start, line_end}: repo_root is the absolute path of the repository, path is relative to it with `/` separators (no `..`), lines are 1-based and inclusive. Wenlan reads the file when you write; an unreadable file, a path outside the repository or lines past the end of the file refuse the whole write. Entries are added to the page's existing code bases (naming one again re-anchors it as `ok`). Local stdio only. The reply lists the page's code bases after the write.
expected_versionNoRefresh only: pass page.version from read_page. When the page has moved on, the write is refused and nothing changes; re-read the page with read_page and retry. A refresh of a page the user wrote or edited lands directly with it and is refused without it.
source_memory_idsNoMemory source_ids the page is distilled from. Memories only: a note's page id is refused here, pass it in `basis`. Optional: pass them when the page is built from captured memories, because they are its traceability (the daemon attaches provenance from them). Omit them for a page written from the conversation itself. On refresh, carry the page's existing list through; a page that has sources refuses an empty list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.19.3

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing exactly what is destroyed and preserved: content + source_memory_ids replaced, stale_reason cleared, page_id and created_at preserved, version bumped for wikilink stability, atomic DB + on-disk <slug>.md projection. It also documents refusal semantics on expected_version mismatch (nothing changed), review_required staging, and the local-stdio-only transport limit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and creation path are front-loaded, but the body is a dense, run-on block that repeats itself ('from the `stale_pages` block in distill output' and the expected_version refusal appear twice). Nearly every sentence carries information, yet the lack of structure makes it harder to parse than it needs to be.

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 12-parameter, destructive, versioned tool it covers creation, refresh, atomicity, version guard, review staging, basis/code_basis and transport constraints. The gap is return values: with no output schema, the description only incidentally mentions that the reply lists bases/code bases, and says nothing about the returned page object or version.

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% and the schema descriptions are already rich, so baseline is 3; the description still adds meaning, e.g. why expected_version exists ('if the page moved on, the write is refused... so re-read and retry'), that basis is notes-only while source_memory_ids is memories-only, and refresh carry-through of existing source lists. Some of this duplicates the schema text rather than extending it.

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 and resource ('Create or refresh a wiki page') and immediately separates the two modes by page_id presence. It also names the siblings it is not (rename_page, delete_page) and the anti-pattern (delete + recreate), so an agent can route correctly without opening a schema.

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?

Explicit when-to-use ('When the user asks to turn something from this conversation into a page'), when to create vs refresh (omit page_id vs pass page_id), and concrete alternatives: rename_page for title changes, read_page before refresh, never delete_page + recreate. Exclusions and prerequisites are all stated.

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