Skip to main content
Glama

essay.stage

Advances a university assignment through confirm-gated writing stages—planning, research, drafting, feedback, editing, and referencing—and saves each stage only after explicit confirmation.

Instructions

When a copied sequence opens on stage 1, stages 1–3 run again. If the parent already saved stage 2 or 3, name the prior lock: stage number, stage title, and the parent sequence id. Ask whether to revise it or keep it. Show the Confirm card only when they revise or explicitly re-lock. Keep continues with the saved lock and does not show Confirm again for that same save. Essay: essay.stage. Draft shows a chat card (kind confirm) with the sequence id, the stage, the save line, and actions Confirm and Not yet. Send confirmPhase confirm only with cardAction confirm and cardDigest from that card, and only after the person picks Confirm on the card. A typed ok, yes, or confirm is not a pick. When a draft card is waiting, show that Confirm card again, with its digest, only while the pointer still has that stage as current and the stage is not saved. If the stage is in saved, or current is a later stage, do not show that card. Say the tool's next and the card the tool returned for current. Essay Bot may only show the Confirm card the door returned. It does not pick the next stage itself. In a group room, a student or another agent may be unable to tap the Confirm card. The draft reply returns cardAction confirm and cardDigest from that waiting draft. Send confirmPhase confirm with those two fields copied from the reply. Do not invent a digest. A typed yes, ok, or Confirm does not save. A line such as Press Confirm for Stage N does not save by itself. It shows the waiting card again, including cardAction and cardDigest. Sending that press together with cardAction and cardDigest from the waiting draft saves that stage in one call. A second identical press is not required. Operator only. Never read this block to the student. Each stage is saved only by a Confirm for that stage. Press Confirm for Stage N copies the waiting draft fields for stage N only. It does not save stage N+1 or stage N+2. Stage 4a needs its own Confirm before it is saved and before stage 4b. A typed Confirm, yes, or ok does not save. A typed reply does not save. The card shown is the one in the latest tool result for the current stage. Essay Bot may only show the Confirm card the door returned. It does not pick the next stage itself. Before any card is shown, follow the pointer. If this stage is already saved, or the current stage is later, do not show that card. Say the tool's next and the card the tool returned for the current stage. Do not leave the stage with no next ask. Stage 5 stores on the draft and starts stage 6. There is no Confirm card between stage 5 and stage 6. Stages 8, 9, and 10 keep their own Confirm cards. Do not save a later stage in the same press. Post a Confirm only when its cardDigest matches the door's latest result for the current open sequence. Refuse a closed pack, a wrong sequence, and inventing the next stage. When a sequence opens, post only the Confirm card in that door result. That card's sequence id is the sequence that opened. Do not post a Confirm from another sequence. A student answer that finishes the ask, including a clear no changes, all fine, or none, is one tool call whose result is spoken in that same turn. That answer keeps the draft already saved and does not invent sentences. It returns the Confirm card and does not save. Do not leave tracking on Status draft with no next ask. A skip does not save and does not end the turn. Refuse the skip and ask the questions again in that same reply. Confirm with cardAction and cardDigest from that card saves the stage. Stray answers, edited text, a web check, or a look on that confirm do not change the card and do not change the phase. While file work is going, say a short start line when that work starts. Say a mid tip only when that path signals a phase, using the mid-status tip sheet, and do not invent a phase. If that path stays silent for about five minutes, say one calm line that work is still going, then wait for a tip or until the step is ready. Do not repeat that line on a fixed clock. A short job does not get that five-minute line. This is for every mid-office stage on the stage 1 to 10 line, not only research. When the step is ready, say so and give the next ask. Name the Confirm card only when that stage's card is in the latest door result and the artifact is ready to lock. Do not warn about a later stage's card while file work is still running. Use the status sentences on the reply. Say them in that same turn. Do not wait for another poke. A logging notification is not the chat line. Say a short start line when the reply includes status for a started job. A status line does not save the stage and does not replace the Confirm card. Do not add a watch link. If no mid-office path is running, do not say that work is still going. When file work stops early or the CLI exits with an error, say the short exit line from the tip sheet. Do not go quiet. When a tip names the standard, use the opening already printed for this assignment. A diary with a table uses How to score high and the printed top column. An essay or a report with a scheme uses what the mark scheme scores. If there is no scheme, use the brief and the assignment ask. Never invent a band. Do not rename a diary column to the words mark scheme. Typed text does not write tracking/stage.json. Not yet leaves the step unsaved. Never silent. After Stage 3 is saved, the reply may include one encourage question. Say that one question and its choices. Do not ask another question in the same turn. When the person answers or skips, call essay.stage with encourageChoice set to that reply. Do not send encourageChoice on the save that locks the plan. Silence does not block the saved stage and does not add a detail the person did not give. On a copied sequence, stage 4a researches first, then each saved paper is kept, dropped, or replaced. Call essay.stage with paperChoice set to the paper and that choice. A dropped paper leaves the list only. The file stays. A kept paper that already has a critical note is not gathered again. essay_id is a sequence id such as MOD1011AA-5. stage is 1, 2, 3, 4a, 4b, 5, 6, 7, 8, 9, or 10. Load stage_settings rules for that stage and apply every line before the stage output. The guidance is rules. Follow every line. Draft writes tracking/.md on the sequence from that guidance. A card pick saves the final look in that file, then tracking/stage.json moves to the next stage. Stage 5 stores on the draft and starts stage 6. There is no Confirm card between stage 5 and stage 6. The reply started.stage is 6, with master_ask. Stages 7, 8, and 9 keep their own cards. One card does not run the later stages. Stage 10 confirm does not submit. look is an optional plain note of the checklist answers. Omit it and the final look is the stage guidance. A changed look needs a fresh draft. Before the save, the chat opens with a short Basics pass. The first three lines are what the mark scheme scores, the format the brief names, and the assignment question in the student's words. Later bullets stay short. Delivering annotation.docx alone is not this pass. Do not paste the rest of the Basics checklist into the chat. Stage 5 stays quiet and does not paste the whole checklist. Record the answers in the tracking note. The rest of the Basics checklist stays in the stage prompt and in the tracking note. Student chat is warm, helpful, encouraging, and concise: only what the person must know. A bullet list or a table is fine when the content is long. Always surface limits the person must know, such as Stage 1 limiting conditions. The chat outcome is the short Basics pass, then a clean Confirm. 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. 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 1 — Analyse the task. File: tracking/1.md. Next: 2 — Essay: Establish a thesis. Report: Establish purpose and scope. Stage 2 — Essay: Establish a thesis. Report: Establish purpose and scope. File: tracking/2.md. Next: 3 — Essay: Write an essay plan. Report: Write a report plan. Stage 3 — Essay: Write an essay plan. Report: Write a report plan. File: tracking/3.md. Next: 4a — Annotated bibliography. Stage 4a — Annotated bibliography. File: tracking/4a.md. Next: 4b — Critical review. Stage 4b — Critical review. File: tracking/4b.md. Next: 5 — Write your first draft. Stage 5 — Write your first draft. File: tracking/5.md. Next: 6 — Re-read and make changes. Stage 6 — Re-read and make changes. File: tracking/6.md. Next: 7 — Ask for feedback. Stage 7 — Ask for feedback. File: tracking/7.md. Next: 8 — Edit and redraft. Stage 8 — Edit and redraft. File: tracking/8.md. Next: 9 — References and citations. Stage 9 — References and citations. File: tracking/9.md. Next: 10 — Submit the final draft. Stage 10 — Submit the final draft. File: tracking/10.md. Next: none. The tool does not submit.

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>",
      "stage": "<stage>"
    },
    "name": "essay.stage"
  }
}

Input Schema

NameRequiredDescriptionDefault
lookNo
stageYes
editedNo
masterNo
answersNo
essay_idYes
heldFileNo
webCheckNo
card_onlyNo
cardActionNo
cardDigestNo
lockChoiceNo
namedFolderNo
paperChoiceNo
confirmPhaseNo
encourageChoiceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

C2.7/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. It does disclose important behavior: operator-only use, draft writes tracking files, a card pick saves the stage and advances tracking/stage.json, stage 10 does not submit, and confirmation requires a digest from the latest card. But these traits are tangled with repeated procedural instructions, making key behaviors hard to isolate, and several operational aspects such as error behavior and idempotency remain unstated.

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

Conciseness1/5

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

The description is an enormous wall of repetitive prose with no front-loaded summary. Sentences are repeated almost verbatim, such as the rule that Essay Bot may only show the Confirm card the door returned, and the stage 5/stage 6 no-card rule appears twice. It is not appropriately sized, and the structure actively obstructs comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter mutation tool with no annotations and no output schema, this description should clearly define inputs, outputs, and behavioral boundaries. It includes a stage list and some file behavior, but it omits or obscures half the parameters and gives only scattered hints about return shape, such as started.stage and card fields. The volume does not translate into completeness.

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% across 16 parameters, so the description must compensate. It explains central fields well: essay_id as a sequence id, stage as 1–10 including 4a/4b, look as an optional checklist note, confirmPhase with cardAction and cardDigest, plus encourageChoice and paperChoice. But it leaves many parameters such as edited, master, answers, heldFile, webCheck, card_only, lockChoice, and namedFolder undocumented or only loosely implied.

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 description eventually conveys that essay.stage advances an essay sequence through numbered stages, writes tracking/<stage>.md, and moves tracking/stage.json after a card pick. But the opening lines are conditional edge cases, not a purpose statement, and the core operation is buried among card-handling rules with no explicit sibling differentiation. The agent can infer the purpose, but only after assembling scattered fragments.

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?

It gives extensive conditions for using confirmPhase, cardAction, cardDigest, encourageChoice, paperChoice, and for when not to show or save a Confirm card. However these are conversational workflow rules rather than selection guidance among the many essay.* siblings, and there is no explicit routing such as when to use essay.research.* or essay.gates instead.

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