Veynod

Write Continuation

write_continuation

Write the task's continuation pack so the next holder starts where you stopped.

tried: [{approach, result: worked|failed|partial, note}]; artifacts: doc refs;
state: up to 16 KB of JSON. The next claim returns it first. handoff=true
also hands the task off (status HANDOFF). Write one before every handoff.
erratum: after your handoff, while the task is in review, append a correction
to your brief (only that; the pack is not rewritten).
This mirrors REST POST /v1/tasks/{task_key}/continuation.

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": {
      "task_key": "<task_key>"
    },
    "name": "write_continuation"
  }
}

Input Schema

Name	Required	Description
`done`	No
`avoid`	No
`brief`	No
`state`	No
`tried`	No
`erratum`	No
`handoff`	No
`task_key`	Yes
`artifacts`	No
`handoff_to`	No
`next_steps`	No
`open_questions`	No
`idempotency_key`	No	Optional. Retries with the same key and arguments within 24 h replay the first result (replayed=true) without a second write; a different body with the same key is idempotency_key_reused.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the annotations (which only say non-read-only, non-destructive), it discloses meaningful behavior: the next claim returns the pack first, handoff=true drives status to HANDOFF, state is capped at 16 KB, and erratum appends only to the brief without rewriting the pack. The idempotency behavior is left to the schema rather than the description, so it stops short of full coverage.

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

Conciseness4/5

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

Front-loads the purpose and then moves compactly through the key fields; every line carries information. The telegraphic 'field: format' style is dense but readable, with only minor compression cost.

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 13-parameter mutation with a separate output schema, it covers the mechanics an agent most needs (handoff trigger, erratum mode, return-on-next-claim, state size limit). The unexplained secondary fields (done, avoid, brief, next_steps, open_questions, handoff_to) and absent REST-mirroring details keep it from being fully 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 only 8%, so the description carries most of the burden. It explains tried (with the worked|failed|partial result values), artifacts (doc refs), state (16 KB JSON), handoff, and erratum, but leaves done, avoid, brief, next_steps, open_questions, and handoff_to entirely undefined in either place.

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 and resource ('Write the task's continuation pack') and frames its purpose ('so the next holder starts where you stopped'). It also discloses the handoff side effect, which separates it from pure note-writing siblings, but it never names an alternative such as agent_handoff_task or update_task explicitly.

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?

Gives clear timing rules: 'Write one before every handoff' and an erratum path used 'after your handoff, while the task is in review'. It does not, however, say when to skip the pack entirely or how it relates to sibling handoff/status tools.

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

All Veynod tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.