Skip to main content
Glama

essay.research.summary

Summarizes gathered sources for a specific essay, then—after confirmation—produces an annotated bibliography, leftover download list, and PDF package without inventing citations.

Instructions

Essay: essay.research.summary (Confirm two-step — draft, show the human, then the same arguments with confirmPhase confirm; never silent). essay_id is a sequence id such as MOD1011AA-5. A bare module code is refused and nothing is written beside sequences/. Say that reply to the user. File work does not own the chat. Choices are stored on that sequence. Uploads stay on the module. Summarises only gathered sources for this essay id. invent-forbid: do not invent authors, titles, years, quotations, pages, DOIs, or journals. Does not call a resolver. Confirm delivers annotation.docx in the chat, download-list.docx as Word (leftovers only — not citation lines already on annotation.docx or PDFs already in the zip), and a zip of real PDFs only. The reply includes a links card with a title and a URL for each source that still needs a PDF. A saved PDF is not on that card. Draft writes none of those files. The files are the same for either mid-office pick. Basics checklist (Basics 4a): Gathered sources only (do not invent sources). Choose sources that answer the question, cover more than one view, and include the key works.; Each annotation is a few full sentences after the citation, written so a student can read them aloud: what the paper did, what it found, and how it helps this assignment. Keep mark-scheme words the brief uses, and gloss each one in plain English the first time. Do not delete those words.; Evidence vs claim: what the source shows versus what you will argue.; Harvard Referencing 4a format: the citation line stays exact, then a few full sentences a student can read aloud. Those sentences say what the paper did, what it found, and how it helps this assignment. Keep mark-scheme words the brief uses, and gloss each one in plain English the first time. Do not delete those words. Do not replace that paragraph with a shortened bibliography or a citation line that has no sentences. Journal: Surname, Initial. (Year) 'Article title', Journal Title, volume(issue), pp. start-end. Available at: doi:10.xxxx/xxxxx. Book: Surname, Initial. (Year) Title. Place: Publisher. Web page: Organisation (Year) Title. Available at: URL (Accessed: date). A missing page, DOI, volume, journal, place, publisher, or access date stays blank. Do not invent it. The full reference pass is stage 9.; download-list.docx is leftovers only: gathered sources not already in the papers zip, plus failed look-up addresses that are not saved PDFs. Do not repeat citation lines from annotation.docx.; When you name other gathered sources or free alternatives already found after this save, speech only. Do not open a new look-up or free-alt download in this step.; After this save is approved, a later download step can fetch leftover free alternatives already found. That step does not open a new look-up and does not invent an address.; The citation year is the year in the PDF page title or header. Do not use the file's modified time as the year.; An abstract-only source stays on download-list.docx until a PDF of that source is opened. It is not an annotated-bibliography entry before that PDF is opened.; A PDF larger than 20MB is read in parts on this machine. Each part stays readable. A part that cannot be read is recorded for the later citation pass. The PDF bytes stay on this machine.; Before a Word file or a zip is handed across, clear the Mac quarantine mark and the provenance mark on the Documents copy. If those marks are absent, leave the file unchanged.; A database the brief names is not a look-up. The file the student holds fills that slot. Do not store a folder path.; Research file work on this computer opens only a path already allowed for this sequence. Allowed: the code checkout, and that checkout is code only, not a student save; Essay-writer// workflow files; uploads// when that is the product path; a path already named on the download list, the annotation, or a known project file for this sequence; local subject notes for this module when the module needs it. Do not search the home folder, whole Documents, or whole Volumes for papers. Do not invent a student folder path. Do not save student work in the code checkout. 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. 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 4a: 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 4a — Annotated bibliography guidance as rules (stage_settings rules). Follow every line. essay.stage writes tracking/4a.md from that guidance. On confirm, essay.stage saves the final look there and moves to stage 4b — Critical review. 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 research seat reads the writing helpers in the server instructions. That note is not a source list.

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>",
      "topic": "<topic>"
    },
    "name": "essay.research.summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
packsNo
topicYes
claimsNo
sourcesNo
essay_idYes
industryNo
host_voiceNo
confirmPhaseNo
exclude_section_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

C2.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose substantial behavior: Confirm writes annotation.docx, download-list.docx as Word, and a zip of real PDFs only, while Draft writes none of those files. It also states invent-forbid constraints, that no resolver is called, that PDFs over 20MB are read in parts locally, and that quarantine/provenance marks are cleared before handing files across. Some claims are confusing ('File work does not own the chat', 'The files are the same for either mid-office pick'), but the side-effect disclosure is unusually rich.

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 a sprawling stage prompt rather than a tool description, with no front-loading of the core operation. It repeats the same annotation guidance verbatim twice ('a few full sentences... what the paper did, what it found, and how it helps this assignment') and includes irrelevant procedural material about model settings, mark schemes, and chat tone. It is not concise and the structure is a semicolon-delimited dump.

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?

This is a complex nine-parameter mutation-capable tool with no output schema and 0% schema description coverage, so the description needed to explain the parameters and return behavior clearly. Instead, most of the text is stage-prompt rule content, and parameters like sources, claims, packs, and host_voice are never defined. The agent knows some file side effects but not enough to call the tool correctly across its full surface.

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 nine parameters, so the description must compensate and largely does not. It explains essay_id format ('MOD1011AA-5', bare module code refused) and references confirmPhase semantics, but packs, claims, sources, industry, host_voice, and exclude_section_ids receive no explanation at all. With most parameters undocumented in both schema and description, the tool is hard to invoke correctly beyond the two required fields.

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 core operation is stated once: 'Summarises only gathered sources for this essay id', and the draft/confirm two-step is named in the opening parenthesis. However, the statement is buried under a wall of stage-prompt rules about Basics passes, Harvard formats, quarantine marks, and model settings, so an agent has to dig to find what the tool actually does. It references essay.stage but does not clearly distinguish itself from essay.research.full or other research siblings.

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?

The description gives usable conditions: draft first with the same arguments, then confirmPhase confirm, never silent; 'A database the brief names is not a look-up'; and no new look-up or free-alt download in this step. It also explains that a later download step handles leftovers. What it lacks is an explicit comparison to sibling tools like essay.research.full, so the agent must infer when this summary tool is preferred over the full research tool.

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