dsh-zcode-bridge

Overview Schema Source Related Servers Discussions Admin

Continue a ZCode task with master feedback

zcode_continue

Resume a completed, failed, or waiting task by sending feedback. It reuses task ID and workspace, increments the attempt, and preserves prior evidence.

Instructions

Continue a finished task with master feedback: reuses the task ID and workspace, increments the attempt, and preserves prior evidence. Allowed from completed, failed, or waiting_for_master. Supply a stable operation_id when retrying after a lost response; the same ID and input will not create another attempt. A decision flagged by ZCode is never auto-approved; the calling host must provide the follow-up instruction. Results describe Bridge/ZCode execution only: status 'completed' means the invocation and report normalization finished, NOT that the calling host accepted the work. the calling host must independently review the workspace diff and checks before deciding PASS.

Input Schema

Name	Required	Description	Default
`task_id`	Yes
`feedback`	Yes
`operation_id`	No
`additional_requirements`	No

Output Schema

Name	Required	Description	Default
`status`	Yes
`task_id`	Yes
`created_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.1Oct 3, 2026
- addedInput schema / properties / operation_id
```
Added value: +{
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}
```
First observedv1.0.0Oct 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full load and does so richly: it discloses idempotency behavior (same operation_id and input creates no new attempt), that flagged decisions are never auto-approved, that the host must supply the follow-up instruction, and that status 'completed' means Bridge/normalization finished — not host acceptance. These are non-obvious behaviors beyond any structured field.

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-loaded with the core action and effect, then constraints. It is dense but nearly every clause adds operative meaning; the repeated 'calling host must...' phrasing is slightly redundant but not wasteful.

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

Completeness5/5

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

For a continuation/mutation tool with no annotations and a 4-param schema, it covers preconditions, idempotency, and post-call interpretation. Since an output schema exists, leaving return-field details to that schema is appropriate, and the description still clarifies the misleading 'completed' status.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 compensate, and it does for the two most semantically loaded parameters: it explains task_id reuse/increment semantics and operation_id idempotency. It is silent on what 'feedback' should contain and on additional_requirements, so coverage is partial.

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

Purpose5/5

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

States a specific verb (continue) and resource (a finished ZCode task) and enumerates the exact effect: reuses task ID/workspace, increments attempt, preserves evidence. This is clearly distinguishable from siblings like zcode_task (create), zcode_status, and zcode_result.

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 explicit preconditions — 'Allowed from completed, failed, or waiting_for_master' — and a conditional instruction for operation_id when retrying after a lost response. It does not name an alternative sibling (e.g., when to start a new task versus continue), so it stops just short of full when/when-not routing.

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

Deploy Server