Skip to main content
Glama

essay.pack.validate

Validates an essay pack before Word export, checking essay ID, confirmed research coverage, invent-forbid, Harvard referencing, anonymity, and support for a noted or open conclusion.

Instructions

Essay: essay.pack.validate (Confirm two-step). Checks one essay pack before Word: one essay id, sources covered by confirmed research, invent-forbid, Harvard Referencing, no student name or number, and a human choice of noted or open conclusion. A noted conclusion needs gathered excerpt support; open is allowed when support is thin. The door does not change open into noted. A changed pack needs a fresh draft. 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. 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. 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. 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.validate"
  }
}

Input Schema

NameRequiredDescriptionDefault
packYes
essay_idYes
confirmPhaseNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

C2.6/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses meaningful behavior beyond a bare ``validate'': it is a two-step Confirm gate, it will not convert a noted conclusion into an open one, and a violated check requires a fresh draft. It never states whether the call mutates stored state, what permissions/state it requires, or what a pass versus a fail returns, which is the key behavioral fact for a validation tool.

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 first sentence front-loads the purpose, but it is followed by an enormous body of unrelated material: stage 2/3/4b/5/6 sequencing, LLM model settings (grok-4.7, context 256000), report-vs-essay thesis rules, and paragraph-level prose advice about connectives and AI-glue. Almost none of it belongs in a tool definition and it actively obscures the call contract.

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 validation gate with a nested, undocumented `pack` argument and no output schema, the definition omits the essentials: what the pack must contain, what a successful check returns, and how failures are reported. Instead of filling those gaps it spends its length on workflow and style directives the agent cannot act on when invoking this tool.

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

Parameters2/5

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

Schema description coverage is 0% across three parameters, including a nested open-ended `pack` object, so the description must compensate and largely does not. The single useful hint is "Pass critical_reviews on the pack," which implies one expected key, but the rest of the pack contract and the meaning of `confirmPhase` (beyond an implied two-step confirm) are left to inference.

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 clause does name a specific verb and resource: "Checks one essay pack before Word," followed by a concrete checklist (essay id, source coverage, invent-forbid, Harvard Referencing, no student name/number, noted vs open conclusion). However, this clear statement is immediately buried under a long tail of stage-workflow, plan-revision, and prose-style rules that have nothing to do with what this tool does, so an agent must excavate the purpose. It never cleanly distinguishes itself from the many siblings (essay.stage, essay.gates, essay.pack.render_word).

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 guidance: it is the gate before Word/the stage 5 draft, "A changed pack needs a fresh draft," and "Re-open a source paper only with reopen when that markdown does not cover the gap." But it is tangled with stage 2/3 plan-revisit rules that belong to a different part of the workflow, not to a decision about calling this tool. No explicit statement of when NOT to validate or which sibling to prefer instead.

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