Skip to main content
Glama

Write a document

write_doc

Create a new Tisty document or rewrite an existing one whole, converting imported Markdown into Tisty's language and reporting what changed; pass print to overwrite safely and compact to reorganize.

Instructions

Write something to keep and read again — a recipe, a procedure, a reference, a summary; work to do is a task (propose). In the Tisty language (language has it whole): Markdown from elsewhere is turned into it on the way in, the answer says what changed under turned, and only what has no way in is refused, naming it. Left alone it writes a new document; with doc and print it writes an existing one again, whole — pages the body does not name keep their lines, put back at the end — except, when compacting, the pages you marked, which leave the body. To change one passage, edit_doc does it without carrying the whole both ways. Before writing a new one, find: a subject that has a document gets edit_doc, or this with doc and print, not a second document; a title carrying a ticket, a date or «v2» is the sign you are writing one, and a title already taken is refused, naming it. With compact it writes a document back into the living shape the instructions give: needs print, keeps the old body for restore_doc, and the answer gives the size before and after and what was kept back. A document is tagged by writing #word in its own text, for what it is about: six is already a lot, past 64 the rest are dropped, and tags lists those in use.

Input Schema

NameRequiredDescriptionDefault
docNoThe id of a document to write again — an opaque name like `q7ntmzbm-0001`, not its title — replacing its body. Needs `print`. Left out, a new document is written instead
bodyYesThe whole document. Its first line becomes its title. Each paragraph goes on one line, however long: in the Tisty language a single newline is a line break, so markdown wrapped at 80 columns reads broken in the middle of its sentences. Nothing checks this on the way in
printNoThe `print` `read_doc` gave you with the text you are working from. If the document has moved on since, nothing is written and you are told to read it again — so the person cannot lose what they wrote while you were thinking
anywayNoA new document whose title names the same subject as one already here is refused; this writes it all the same. Only when it truly is another subject
folderNoThe existing folder its subject belongs in, by its name, its whole path or its id. Expected: `docs` says which exist, the `folder` tool makes a new one once the person agrees, and a name no folder has is refused here. Left out, it sits outside them all, and that needs a reason. Writing an existing document again with `doc` and `print` cannot take `folder`: `file_doc` moves one that is already here
compactNoWith `doc` and `print`: this writing puts the document back in order — what holds today, the subject, the decisions, the history — rather than changing what it says. Call `rules` first: it says the order. In one whole write: before it, move what leaving pages hold and mark them; in it, today first, then the subject, the decisions and a history naming every link and file taken out — one lost without a name is refused. Only what Tisty confirms is stated as today; what you only read stays dated and unconfirmed. Refused on a document the person began unless `person_asked`. The window shows the person it was compacted, by whom and when, with one click to undo; until they decide, only one more whole `compact` of yours goes in
page_ofNoThe id of the document this one is a page of — an opaque name like `q7ntmzbm-0001`, not its title. The page is named at the end of that document, and where it is named is where it sits; `page_doc` with `after` puts that line somewhere else. A page follows that document everywhere and takes its folder, so `folder` is ignored, and it holds no pages of its own
person_askedNoWith `compact`: the person asked you in this conversation to compact a document they began. Never otherwise
keep_compactionNoOnly when the person told you in this conversation to keep a compaction of this document that waits for their word: it is kept, and this write goes ahead

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and discloses important traits: Markdown is converted into the Tisty language, unconvertible content is refused with its name, `print` prevents overwriting concurrent changes, duplicate titles are refused unless `anyway`, and `compact` preserves the old body for `restore_doc`, exposes undo, and limits further compactions.

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

Conciseness2/5

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

The description is a single dense paragraph with long, nested clauses and parenthetical asides, making it hard to scan. The content is valuable, but the structure is not front-loaded for quick understanding of the several distinct modes.

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 9-parameter mutation tool with no annotations or output schema, the description covers creation, rewriting, compaction, folder and page placement, tagging, and key response fields such as `turned` and `size`. Some operational details remain implicit, but the core behavior is well covered.

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 still adds meaningful mode semantics beyond the schema: `doc` and `print` must be used together for rewrites, `compact` requires `print`, `page_of` ignores `folder`, and `person_asked` / `keep_compaction` are constrained to prior conversation.

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?

States a specific verb and resource ('Write something to keep and read again') and explicitly distinguishes it from `propose` for work to do and `edit_doc` for changing one passage. It also distinguishes creating a new document from rewriting an existing one with `doc` and `print`.

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?

Gives explicit when-to-use guidance: run `find` before writing a new document, use `edit_doc` for a single passage, use `doc` plus `print` to rewrite an existing document, and use `compact` with `print` to reorganize. It also names alternatives like `file_doc` for moving a document and `page_doc` for placing pages.

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