Skip to main content
Glama

essay.pack.render_word

Writes a validated essay pack to a .docx file only after the confirm step; drafts save nothing and confirmation must match the same pack.

Instructions

Essay: essay.pack.render_word (Confirm two-step). Draft writes nothing. Confirm writes a .docx only for the same pack after validation confirm. The essay id must be a sequence id. A bare module code is refused, so Word is not written at Essay-writer//output/. Say that reply to the user. File work does not own the chat. A sequence id writes that sequence's Word file, not the module's other sequences. Word only. No student name unless the assignment record requires it. When that record requires a registration number, print the number stored on the sequence. Do not invent it. Put the page number where the record says. Never confirm a changed pack. The first draft is authored from the stage 4b critical-review markdowns, one markdown per paper. Pass critical_reviews on the pack. Re-open a source paper only with reopen when that markdown does not cover the gap. Pass stage 6 for the first Word file or stage 9 for the final Word file. Those paths need an EQR PASS from the reviewer seat. This writer door does not review itself. Follow the server instructions for the Basics checklist. Stage 1 limiting conditions. The chat outcome is the short Basics pass, then a clean Confirm. After 4a and 4b Confirm, revisit the stage 3 plan before stage 5. Revisit stage 2 only if research breaks that lock: the essay thesis, or the report purpose and scope. The report central theme is the one-sentence answer. A thin edit is allowed. A break is not a thin edit. Check that section arguments still hold, that word weights still match the brief, and that source types are real titles with gaps named. invent-forbid: nothing in the plan that the research never showed. Use only the year printed in the opened source. Do not add a second year. If anything changes, show the delta and why it comes from the gathered sources, update the tracking note, and Confirm again before stage 5. If the theme or the purpose breaks, Confirm stage 2 and then Confirm stage 3. An essay keeps the thesis. A report has no thesis. Do not silently rewrite the plan into the draft. Stage LLM (no-fast): Basics 5: model grok-4.7, reasoning xhigh, fast off, context 256000; Basics 7: model grok-4.7, reasoning high, fast off, context 256000; Basics 8: model grok-4.7, reasoning high, fast off, context 256000; Basics 9: model grok-4.7, reasoning high, fast off, context 256000. Apply the Basics checklist already on this tool as rules. Follow every line. Apply stage 5 — Write your first draft guidance as rules (stage_settings rules). Follow every line. essay.stage writes tracking/5.md from that guidance. When that draft is stored, essay.stage starts stage 6. There is no Confirm card between stage 5 and stage 6. Apply stage 7 — Ask for feedback guidance as rules (stage_settings rules). Follow every line. essay.stage writes tracking/7.md from that guidance. On confirm, essay.stage saves the final look there and moves to stage 8 — Edit and redraft. Apply stage 8 — Edit and redraft guidance as rules (stage_settings rules). Follow every line. essay.stage writes tracking/8.md from that guidance. On confirm, essay.stage saves the final look there and moves to stage 9 — References and citations. Apply stage 9 — References and citations guidance as rules (stage_settings rules). Follow every line. essay.stage writes tracking/9.md from that guidance. On confirm, essay.stage saves the final look there and moves to stage 10 — Submit the final draft. When the brief is a report, stage 2 locks purpose and scope and stage 3 holds the central theme. A report has no thesis. An essay keeps the thesis. The write seat reads the writing helpers and Harvard Referencing in the server instructions. Those notes are not a source list. Keep the person the brief names. A diary keeps that brief voice and is not forced into third person. An essay or a report is not forced into first person to sound human. Ban AI-glue: do not pad with stock transitions, empty emphasis, or lines that could sit on any assignment. When no lecture, reading, or workplace detail is on the opened files, ask the student once for one real detail and use only that detail. Never invent a lecture, a reading, or a workplace detail. Do not open with a general sentence built only from the topic nouns. Do not close with an automatic In conclusion that only restates the topic. A paragraph closer must not only restate the topic sentence. Make it assignment-specific: a cited finding, a limit, or a figure. Use a connective only when the relation is true. However has to mark a real contrast. More connectives are not more coherence.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "essay_id": "<essay_id>",
      "pack": "<pack>"
    },
    "name": "essay.pack.render_word"
  }
}

Input Schema

NameRequiredDescriptionDefault
packYes
stageNo
essay_idYes
confirmPhaseNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose several important behaviors: the draft call is a no-op, the confirm call writes the file, a bare module code is refused so no file lands at the module output path, and only the named sequence's file is written. What it never states is what happens to an existing .docx, what the response looks like, or what error surfaces on a refused confirm. The signal-to-noise ratio also makes the disclosure hard to extract.

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 first sentences are correctly front-loaded, but the definition then runs on for hundreds of words of stage-by-stage writing guidance, AI-glue bans, connective rules, and model settings that have nothing to do with invoking a render tool. The operative content is a small fraction of the text and is not structured or separated from the essay advice.

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?

Given a write operation with no annotations and no output schema, the definition does cover the essential call mechanics: which phase writes, which stages are legal, the sequence-id requirement, the EQR gate, and the do-not-confirm-a-changed-pack rule. It is thin on failure modes and return values, but for a mutating tool it is unusually explicit about preconditions.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate, and it does partially: essay_id is constrained to a sequence id with bare module codes refused, stage is pinned to 6 or 9, and pack must carry critical_reviews. confirmPhase is only implied by the two-step narrative rather than explained, and the nested, free-form 'pack' object is otherwise undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening lines do state a concrete verb and artifact: a two-step render where 'Draft writes nothing. Confirm writes a .docx only for the same pack after validation confirm.' That is specific enough to identify the operation. However, the purpose is buried under several hundred words of essay-writing pedagogy, and differentiation from siblings is only incidental (a passing mention of essay.stage and reopen) rather than deliberate.

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?

There is real usage context: 'Pass stage 6 for the first Word file or stage 9 for the final Word file. Those paths need an EQR PASS from the reviewer seat' and 'Never confirm a changed pack.' These are genuine preconditions an agent must know. But there is no clean statement of when to pick this tool over essay.pack.validate, essay.stage, or essay.shelf.put, and the guidance is interspersed with unrelated drafting rules.

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