Skip to main content
Glama

essay.intake

Upload an assignment Word draft or photo, match it to a module, and confirm before it is filed and the module’s writing sequence rolls forward.

Instructions

Essay: essay.intake (Confirm two-step). Say the reply to the user. File work does not own the chat. Call with the file name. A Word draft is matched to one module; say which module and ask the user to say yes, then roll forward onto that module's next sequence. The choice is the module. Do not ask for a sequence. If the file cannot be matched, the reply is the module list with no sequence id. The user picks a module and the upload rolls forward (rollForward true). If the user cannot identify a module, call with create true and the new module code. Say there is no saved research trail, next steps use an upload, a look-up, or a source card from here, research starts only if the user asks, the first draft is done, and the stage is their feedback. A supporting document is filed on the module for every sequence. A changed Word upload leaves the parent sequence in place. An unchanged Word file stays in unassigned/ and nothing is written. A PNG, JPEG, GIF, or WEBP photo is not a Word draft. When the result says needs_reading, look at the image in the tool result and call again with the same file name, the same module, confirmPhase draft, and reading set to only the words visible in the photo, including handwriting. Do not ask the student to copy those words from another program. Show that reading to the student. After an explicit yes, confirm files the photo and those words on the module for every sequence. An empty or unreadable photo is refused and nothing is filed.

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

Input Schema

NameRequiredDescriptionDefault
nameYes
createNo
moduleNo
readingNo
rollForwardNo
confirmPhaseNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

B3.3/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 behavioral burden and does disclose important side effects: unchanged Word files stay in unassigned and nothing is written, changed uploads leave the parent sequence in place, empty/unreadable photos are refused, and confirmation files content to the module. It does not cover permissions, rate limits, or the exact result shape beyond needs_reading, so it is strong but not complete.

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 description is a long, disorganized stream of procedural commands with repeated 'Say...' instructions and no front-loaded summary. It is hard to scan and contains redundancy, so structure and conciseness are weak.

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

Completeness3/5

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

For a complex two-step file intake tool with no annotations and no output schema, it covers the main flows and several edge cases (unmatched files, changed/unchanged Word uploads, photo reading/refusal). It still leaves gaps around return structure, error handling beyond photos, and how the module list is presented, so it is only moderately complete.

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% for six parameters, so the description must compensate; it does mention file name, create true with new module code, module selection, rollForward true, confirmPhase draft, and reading text. However, the mappings are informal and scattered, with no explanation of defaults, null behavior, or valid values beyond 'draft'.

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 identifies the resource (an essay file upload) and a two-step confirm flow, but the opening 'Essay: essay.intake (Confirm two-step)' is largely a restatement and the actual purpose—intaking Word drafts/photos and filing them to a module—must be pieced together from scattered procedural sentences. It is distinguishable from siblings by its file-handling focus but not stated crisply.

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?

It gives many conditional instructions: call with the file name, use create true plus new module code when no module can be identified, rollForward true when the user selects a module, and call again with confirmPhase draft and reading for photos. It also includes prohibitions ('Do not ask for a sequence') but never names alternative sibling tools or explicitly says when not to use this tool.

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