Skip to main content
Glama
Sign In
EMET

EMET

by dreamforgestudiollc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

write_doc_abort

Idempotent

Cancels an open document stage without altering the current document; aborting an already-aborted stage writes nothing and reports that state.

Instructions

Drop an open stage. The current document is unchanged. Aborting a stage that is already aborted reports that abort and writes nothing.

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": {
      "stage_id": "<stage_id>"
    },
    "name": "write_doc_abort"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceNoSource tag. Must match the stage.
exchangeNoThe exchange (turn) this write belongs to, counting from 1. A write for exchange n while exchange n-1 was never appended is refused by the session graph until n-1 is appended.
stage_idYes
session_idNoYour transcript session id from emet_session_open. The session graph reads this session's state before the write and returns `session_graph.next` - the next step. A governed write with no session is refused (open one with emet_session_open and load_id).
updated_byNoAlias of `source`. Prefer `source`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false; the description earns credit by giving the concrete semantics behind those hints — the document is unchanged and a repeat abort reports the existing abort rather than writing. It stops short of explaining whether session state is required for the drop, which the schema alone carries.

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

Conciseness5/5

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

Three short sentences, effect stated first, idempotency second, edge case last — every sentence carries distinct information and nothing is repeated.

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 mutation tool with a rich schema and idempotent/non-destructive annotations, the description covers what changes and what does not. The session-graph precondition and next-step return are only in the schema, but that is acceptable given no output schema and detailed parameter docs.

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 80%, so the schema does most of the work and baseline 3 applies. The description adds no meaning for the required `stage_id` parameter, which is coincidentally the one field left undescribed in the schema.

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?

States a specific verb+resource ('Drop an open stage') and immediately clarifies the effect on the document, which separates it from write_doc_commit. It does not name the sibling tools from the begin/append/commit family it is an alternative to, so differentiation is implicit rather than explicit.

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?

Usage is only implied: an agent must infer that abort is the escape hatch for a staged write instead of commit. The edge case (aborting an already-aborted stage) is covered, but there is no statement of when to prefer this over write_doc_commit or what prerequisites exist.

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

Deploy Server

Other Tools