Essay Writer

Overview Schema Source Related Servers Discussions Admin

essay.project.delete

Remove an essay module or sequence only after a Confirm card, deleting workspace files and specified local Word/zip copies without searching the computer.

Instructions

Essay: essay.project.delete (Confirm two-step). Ask which module, then where: grokbot (this essay workspace only), local (named Word and zip copies on the student's computer only), or both. Leaving where off stays workspace-only and does not remove files on the student's computer. Draft lists every sequence id and the upload, brief, and KB1 files when the workspace is in scope, and each localPaths Word or zip path when local is in scope. Draft writes nothing. This tool does not search the computer for copies. When where is both and localPaths is omitted, a Word or zip path already stored for that sequence is used, or the stored paths across the sequences when the whole module is removed, and the default handoff names when this computer can see the files. Ask for the path only when none are there. A path the caller names is the list. where local still needs each path the student names. Do not search the computer. The draft returns a Confirm card. Confirm deletes only after the person picks Confirm on that card, with cardAction confirm and cardDigest from the card. A typed yes does not remove anything. A local or both confirm must say those files on the student's computer will be removed. Never remove a local file unless where is local or both. A local file is removed only when it is a regular .docx or .zip this computer can already see. Pass sequence as one sequence id, such as MOD1004AA-2, to remove only that sequence after the same draft then confirm. Other sequences, the brief, and uploads stay. Omit sequence to remove the whole module.

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": {
      "module": "<module>"
    },
    "name": "essay.project.delete"
  }
}

Input Schema

Name	Required	Description	Default
`where`	No
`module`	Yes
`sequence`	No
`cardAction`	No
`cardDigest`	No
`localPaths`	No
`confirmPhase`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 4, 2026

TDQS

A3.9/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so: the draft writes nothing, deletion occurs only after the person picks Confirm with cardAction and cardDigest, a typed 'yes' removes nothing, and local files are removed only when 'where' is local or both and only for a regular .docx/.zip the machine can already see. It also scopes what survives a sequence-level delete ('Other sequences, the brief, and uploads stay'), which is precisely the destructive-blast-radius information an agent needs.

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?

Roughly 230 words delivered as a run-on stream of conditions with no paragraph or list structure, and the default-handoff behavior of localPaths is restated three times in slightly different wording. 'Do not search the computer' is repeated verbatim in spirit ('does not search the computer for copies' and 'Do not search the computer'). The important confirm-safety rule is buried mid-paragraph rather than front-loaded.

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 destructive, seven-parameter tool with no annotations and no output schema, the description supplies the two-phase protocol, the Confirm card return, the scope model, and the local-file safety rules — enough to call it correctly. The gaps are the undocumented 'confirmPhase' parameter and the absence of any statement about the 'module' identifier format.

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 explain all seven parameters. It covers 'where' (module/local/both), 'sequence' (with the MOD1004AA-2 format example), 'cardAction' (confirm), 'cardDigest' (from the card), and 'localPaths' (named Word/zip paths, string or list). 'confirmPhase' is never mentioned and 'module' is only implied, so the coverage is materially incomplete.

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

Purpose4/5

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

The description makes clear this removes essay project content at either workspace or local-file scope, and that removal happens in a two-step draft/confirm flow. It distinguishes workspace content from local Word/zip copies, which separates it from sibling read tools like essay.projects. It never states the purpose in one clean sentence — the opening 'Essay: essay.project.delete (Confirm two-step)' is a title echo, and the actual meaning must be assembled from later lines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong conditional routing: it says to ask which module then which location, that omitting 'where' stays workspace-only, that 'sequence' narrows to one id while omitting it removes the whole module, and that paths are only requested when none are stored. It also states an explicit exclusion ('This tool does not search the computer for copies'). It never routes the agent to a sibling alternative such as essay.project.archive for non-destructive removal.

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