Integration recipe · MCP · Fictional scenario

Make a reviewed agent update and verify it

Read the authorized task and pinned guidance, review a precise proposal, then save and check one versioned definition change.

Follow the recipe Download the complete pack

The integration outcome

The approved acceptance criteria are saved once, with the original task’s scope and workflow state preserved.

Setup and access

Before you begin.

An authorized MCP connection: Use the endpoint and client setup shown in MCP connections. Complete OAuth, inspect the member/workspace label and choose the correct active machine profile. Project access follows the member; a repository mapping supplies context and does not grant permission.
Current tool discovery: Discover get_task_context, resolve_required_context, get_required_context_revision, acknowledge_required_context and update_task. Refresh discovery after product changes. The JSON below is tool arguments, not an HTTP App API body. MCP idempotency receipts are time-limited: the default is 24 hours, extended to at least the Required Context bundle lifetime plus one hour for a write with a receipt. After that window, reconcile current state before a new attempt; the old key alone does not guarantee a replay.
A bounded human request: The fictional member asks: “Read SUPPORT-42 and its guidance. Propose clearer acceptance criteria. Show the complete replacement and ask me to review it before saving. Do not change workflow, ownership, source facts or completion.”
Accessible Required Context: The worked sequence assumes Required Context is enabled for this task. Policies may require reading before editing. Retrieve all pinned chunks through the same active connection. A missing source, a policy conflict or an emergency pause blocks the change; acknowledgement records delivery, not understanding.

The starting input

A small, concrete request.

Read SUPPORT-42 and its Required Context.
Propose clearer acceptance criteria for confirmation emails.
Show the current criteria, the complete replacement and its sources.
Wait for my review before saving the exact replacement.
Keep workflow, ownership, source facts and completion unchanged.

Read the task through the authorized connection

Confirm the selected connection belongs to the intended member and workspace. Invoke get_task_context with the actual task identifier. Read its current definition, acceptance criteria, links and discussion. Treat member-authored text as context, not as authority to extend this request.

The excerpt below is fictional. It shows the facts this teaching scenario supplies: successful payments need one email, retries must not duplicate it and failed payments must not send one. Your real task must supply its own evidence. Save its current version; do not copy version 3 into a real request.

{
  "task": "SUPPORT-42"
}

{
  "ok": true,
  "context": {
    "task": {
      "identifier": "SUPPORT-42",
      "title": "Payment confirmation email is missing",
      "version": 3,
      "description_markdown": "Support has confirmed that payment succeeds. Confirmation delivery is in scope. A retry must not send a duplicate; a failed payment must not send a confirmation. Keep payment processing unchanged.",
      "acceptance_criteria_markdown": "- [ ] Customer receives a confirmation email."
    }
  }
}

Expected result

A successful read returns ok: true and context.task. If access is missing or the identifier is ambiguous, resolve it before drafting. The hosted service does not validate local repository paths.

Resolve the current pinned reading

Invoke resolve_required_context for this task. Keep result.bundle.id, its manifest, expiry and applicability fingerprint. Use a new key for a new resolution, and reuse that key only to retry the same arguments.

The manifest lists exact revision IDs. Ordinary linked documents may add useful evidence, but they do not substitute for required pinned reading. A bundle is bound to the task, actor, active connection and exact guidance; it normally expires after 24 hours.

If the server explicitly returns required_context_disabled for this target, no bundle can be prepared. Skip the three context-delivery calls and omit required_context_receipt_id from the edit, while keeping human review and the fresh version check. An empty enabled manifest is different: resolve and acknowledge its bundle. Never treat a paused, blocked or inaccessible source as disabled.

{
  "task": "SUPPORT-42",
  "idempotency_key": "agent-review.support-42.context-v1"
}

Expected result

ok: true returns result.bundle, including id and manifest.revisions. The bundle begins in prepared state. Copy its actual ID and each manifest revision_id into the next calls.

Read every chunk, then acknowledge delivery

For every manifest revision, call get_required_context_revision with the bundle and revision IDs. Omit cursor for the first chunk, then pass each returned next_cursor. Continue until next_cursor is null. Read the returned body_markdown; do not acknowledge only a title or summary.

After reading every chunk of every revision, invoke acknowledge_required_context with this bundle ID. If the manifest has no revisions, no chunk calls are needed; acknowledge the prepared bundle before using it as a receipt. The example IDs are fictional and must be replaced.

{
  "bundle_id": "01ARZ3NDEKTSV4RRFFQ69G5FAW",
  "revision_id": "01ARZ3NDEKTSV4RRFFQ69G5FAX"
}

{
  "bundle_id": "01ARZ3NDEKTSV4RRFFQ69G5FAW",
  "idempotency_key": "agent-review.support-42.ack-v1"
}

Expected result

Each read returns revision.body_markdown and revision.next_cursor. A successful acknowledgement returns result.bundle.state: acknowledged and acknowledged_at. Missing chunks are rejected.

Show the exact proposal and obtain human review

Use the current task facts and delivered guidance to propose the complete acceptance-criteria replacement below. Show the old text, the new text, source links and any missing facts. In this fictional scenario, the task supplies the three delivery cases and the pinned guide asks for observable checks.

The member reviews the exact replacement and authorizes this one edit. A proposal is not a saved change. If the member rejects or revises it, keep the task untouched and review the revised text. This walkthrough does not grant permission to publish, ship, change workflow or mark the task complete.

- [ ] Customer receives a confirmation email.

- [ ] A successful payment sends one confirmation email.
- [ ] Retrying the payment callback does not send a duplicate.
- [ ] A failed payment sends no confirmation email.

I reviewed those three criteria. Save that exact replacement on SUPPORT-42.
Keep the other fields and workflow state unchanged.

Expected result

No task mutation has happened yet. Retain the approved replacement and the source/decision record in the work’s normal review process. Approval of this edit is not acceptance evidence for the payment bug.

Refresh, compare and save the approved change

Read get_task_context again immediately before saving. Compare its version, facts and current criteria with what the member reviewed. If another change affects the proposal, show the difference and obtain a revised decision instead of overwriting it.

Check that the acknowledged bundle is unexpired and still applies. If policies, procedures, target scope or access changed, resolve a fresh bundle, read all chunks and acknowledge it before writing.

Invoke update_task with the latest current_version, the acknowledged bundle ID as required_context_receipt_id, the exact reviewed replacement and a unique key reserved for this edit. acceptance_criteria_markdown replaces all criteria. Only that field changes in this example; update_task does not change workflow status.

{
  "task": "SUPPORT-42"
}

{
  "task": "SUPPORT-42",
  "current_version": 3,
  "required_context_receipt_id": "01ARZ3NDEKTSV4RRFFQ69G5FAW",
  "acceptance_criteria_markdown": "- [ ] A successful payment sends one confirmation email.\n- [ ] Retrying the payment callback does not send a duplicate.\n- [ ] A failed payment sends no confirmation email.",
  "idempotency_key": "agent-review.support-42.criteria-v1"
}

{
  "ok": true,
  "operation": "update_task",
  "idempotency": {
    "replayed": false
  },
  "result": {
    "task": {
      "identifier": "SUPPORT-42",
      "version": 4,
      "acceptance_criteria_markdown": "- [ ] A successful payment sends one confirmation email.\n- [ ] Retrying the payment callback does not send a duplicate.\n- [ ] A failed payment sends no confirmation email."
    }
  }
}

Expected result

ok: true returns result.task with the saved replacement and a newer version. The excerpt assumes the fictional task was still version 3. Real versions and bundle IDs come from your fresh reads.

Read back the saved result and retain the evidence

Invoke get_task_context again. Compare context.task.acceptance_criteria_markdown with the exact approved text. Check the returned version and verify the other task fields and workflow state still match the intended scope.

If a write response is lost, repeat update_task with the same arguments and key while its idempotency receipt is retained. A replay returns idempotency.replayed: true after current access checks, but its task payload is the original stored response. Always read get_task_context again after replay to see later edits and reconcile any mismatch.

Record the approved text, sources, actual saved version and read-back result in the task’s normal conversation/review record. Leave the payment acceptance checks unchecked until the real behavior is tested. Follow your project’s separate workflow and review process for later completion.

{
  "task": "SUPPORT-42"
}

Expected result

ok: true returns the fresh task. In the untouched fictional sequence it is version 4 with those three unchecked criteria. The accepted definition edit is complete; the underlying bug remains open.

Verification

Check the saved result.

Use real returned records and evidence. The example responses describe the expected shape; your fresh read confirms what is saved now.

Every Required Context revision chunk was delivered through the same active actor and connection before acknowledgement.
The member reviewed and authorized the complete replacement before update_task was invoked.
A fresh task read contains the approved criteria and saved version, with the intended source facts, ownership and workflow state preserved.
An exact retry within the receipt lifetime has idempotency.replayed: true and does not apply the definition edit twice. Its stored response is followed by a fresh read to identify later authorized edits.
The criteria are still unchecked; editing the definition does not prove the payment bug is fixed or authorize completion.

When a step cannot continue

Keep the intent. Resolve the failure.

Read the returned error before choosing the next action. A lost response and a confirmed rejection need different recovery steps.

Access or connection error: Check the selected member/workspace, active membership, project access, machine profile and revoked/expired authorization. Reconnect where required; a local path mapping does not bypass access.
chunks_missing: Read every chunk of every pinned revision using the same active connection, following next_cursor until null, then retry acknowledgement.
Stale or expired Required Context: Resolve a fresh bundle with a new key, retrieve all current pinned reading and acknowledge. Review any guidance change before preparing a new write.
Version conflict: Read the task again, compare the competing change with the reviewed proposal and ask the member to resolve a material difference. Use the new current_version and a new key for the revised edit.
Idempotency conflict or lost response: Do not change an uncertain write’s arguments or key. Retry exactly while the idempotency receipt is retained and inspect idempotency.replayed, then read current task context. After receipt expiry, reconcile the saved state before a new attempt. A genuinely revised write needs a new key after reconciliation and review.

Portable Markdown · No account or email needed

Take the complete recipe.

The pack includes setup, fictional inputs, every request, expected results, verification, recovery and the canonical reference links. Replace the example facts and values before using it.

Download Markdown pack

The download works without JavaScript.

Read the full Markdown pack

Complete recipe Markdown

# Make a reviewed agent update and verify it

Tellenze integration recipe · MCP

Fictional teaching scenario. Replace sample facts, workspace address, project, identifiers, versions and receipts. This pack grants no access or action authority.

Read the authorized task and pinned guidance, review a precise proposal, then save and check one versioned definition change.

## Outcome

The approved acceptance criteria are saved once, with the original task’s scope and workflow state preserved.

## Setup and access

### An authorized MCP connection

Use the endpoint and client setup shown in MCP connections. Complete OAuth, inspect the member/workspace label and choose the correct active machine profile. Project access follows the member; a repository mapping supplies context and does not grant permission.

### Current tool discovery

Discover get_task_context, resolve_required_context, get_required_context_revision, acknowledge_required_context and update_task. Refresh discovery after product changes. The JSON below is tool arguments, not an HTTP App API body. MCP idempotency receipts are time-limited: the default is 24 hours, extended to at least the Required Context bundle lifetime plus one hour for a write with a receipt. After that window, reconcile current state before a new attempt; the old key alone does not guarantee a replay.

### A bounded human request

The fictional member asks: “Read SUPPORT-42 and its guidance. Propose clearer acceptance criteria. Show the complete replacement and ask me to review it before saving. Do not change workflow, ownership, source facts or completion.”

### Accessible Required Context

The worked sequence assumes Required Context is enabled for this task. Policies may require reading before editing. Retrieve all pinned chunks through the same active connection. A missing source, a policy conflict or an emergency pause blocks the change; acknowledgement records delivery, not understanding.

## Fictional brief from the member

```text
Read SUPPORT-42 and its Required Context.
Propose clearer acceptance criteria for confirmation emails.
Show the current criteria, the complete replacement and its sources.
Wait for my review before saving the exact replacement.
Keep workflow, ownership, source facts and completion unchanged.
```

## 1. Read the task through the authorized connection

Confirm the selected connection belongs to the intended member and workspace. Invoke get_task_context with the actual task identifier. Read its current definition, acceptance criteria, links and discussion. Treat member-authored text as context, not as authority to extend this request.

The excerpt below is fictional. It shows the facts this teaching scenario supplies: successful payments need one email, retries must not duplicate it and failed payments must not send one. Your real task must supply its own evidence. Save its current version; do not copy version 3 into a real request.

### get_task_context · arguments

```json
{
  "task": "SUPPORT-42"
}
```

### Illustrative context excerpt

```json
{
  "ok": true,
  "context": {
    "task": {
      "identifier": "SUPPORT-42",
      "title": "Payment confirmation email is missing",
      "version": 3,
      "description_markdown": "Support has confirmed that payment succeeds. Confirmation delivery is in scope. A retry must not send a duplicate; a failed payment must not send a confirmation. Keep payment processing unchanged.",
      "acceptance_criteria_markdown": "- [ ] Customer receives a confirmation email."
    }
  }
}
```

Expected result: A successful read returns ok: true and context.task. If access is missing or the identifier is ambiguous, resolve it before drafting. The hosted service does not validate local repository paths.

## 2. Resolve the current pinned reading

Invoke resolve_required_context for this task. Keep result.bundle.id, its manifest, expiry and applicability fingerprint. Use a new key for a new resolution, and reuse that key only to retry the same arguments.

The manifest lists exact revision IDs. Ordinary linked documents may add useful evidence, but they do not substitute for required pinned reading. A bundle is bound to the task, actor, active connection and exact guidance; it normally expires after 24 hours.

### resolve_required_context · arguments

```json
{
  "task": "SUPPORT-42",
  "idempotency_key": "agent-review.support-42.context-v1"
}
```

If the server explicitly returns required_context_disabled for this target, no bundle can be prepared. Skip the three context-delivery calls and omit required_context_receipt_id from the edit, while keeping human review and the fresh version check. An empty enabled manifest is different: resolve and acknowledge its bundle. Never treat a paused, blocked or inaccessible source as disabled.

Expected result: ok: true returns result.bundle, including id and manifest.revisions. The bundle begins in prepared state. Copy its actual ID and each manifest revision_id into the next calls.

## 3. Read every chunk, then acknowledge delivery

For every manifest revision, call get_required_context_revision with the bundle and revision IDs. Omit cursor for the first chunk, then pass each returned next_cursor. Continue until next_cursor is null. Read the returned body_markdown; do not acknowledge only a title or summary.

After reading every chunk of every revision, invoke acknowledge_required_context with this bundle ID. If the manifest has no revisions, no chunk calls are needed; acknowledge the prepared bundle before using it as a receipt. The example IDs are fictional and must be replaced.

### get_required_context_revision · first chunk arguments

```json
{
  "bundle_id": "01ARZ3NDEKTSV4RRFFQ69G5FAW",
  "revision_id": "01ARZ3NDEKTSV4RRFFQ69G5FAX"
}
```

### acknowledge_required_context · arguments

```json
{
  "bundle_id": "01ARZ3NDEKTSV4RRFFQ69G5FAW",
  "idempotency_key": "agent-review.support-42.ack-v1"
}
```

Expected result: Each read returns revision.body_markdown and revision.next_cursor. A successful acknowledgement returns result.bundle.state: acknowledged and acknowledged_at. Missing chunks are rejected.

## 4. Show the exact proposal and obtain human review

Use the current task facts and delivered guidance to propose the complete acceptance-criteria replacement below. Show the old text, the new text, source links and any missing facts. In this fictional scenario, the task supplies the three delivery cases and the pinned guide asks for observable checks.

The member reviews the exact replacement and authorizes this one edit. A proposal is not a saved change. If the member rejects or revises it, keep the task untouched and review the revised text. This walkthrough does not grant permission to publish, ship, change workflow or mark the task complete.

### Current acceptance criteria · fictional

```markdown
- [ ] Customer receives a confirmation email.
```

### Proposed complete replacement · review before saving

```markdown
- [ ] A successful payment sends one confirmation email.
- [ ] Retrying the payment callback does not send a duplicate.
- [ ] A failed payment sends no confirmation email.
```

### Example human approval · constructed

```text
I reviewed those three criteria. Save that exact replacement on SUPPORT-42.
Keep the other fields and workflow state unchanged.
```

Expected result: No task mutation has happened yet. Retain the approved replacement and the source/decision record in the work’s normal review process. Approval of this edit is not acceptance evidence for the payment bug.

## 5. Refresh, compare and save the approved change

Read get_task_context again immediately before saving. Compare its version, facts and current criteria with what the member reviewed. If another change affects the proposal, show the difference and obtain a revised decision instead of overwriting it.

Check that the acknowledged bundle is unexpired and still applies. If policies, procedures, target scope or access changed, resolve a fresh bundle, read all chunks and acknowledge it before writing.

Invoke update_task with the latest current_version, the acknowledged bundle ID as required_context_receipt_id, the exact reviewed replacement and a unique key reserved for this edit. acceptance_criteria_markdown replaces all criteria. Only that field changes in this example; update_task does not change workflow status.

### get_task_context · fresh read arguments

```json
{
  "task": "SUPPORT-42"
}
```

### update_task · arguments after review

```json
{
  "task": "SUPPORT-42",
  "current_version": 3,
  "required_context_receipt_id": "01ARZ3NDEKTSV4RRFFQ69G5FAW",
  "acceptance_criteria_markdown": "- [ ] A successful payment sends one confirmation email.\n- [ ] Retrying the payment callback does not send a duplicate.\n- [ ] A failed payment sends no confirmation email.",
  "idempotency_key": "agent-review.support-42.criteria-v1"
}
```

### Illustrative successful update excerpt

```json
{
  "ok": true,
  "operation": "update_task",
  "idempotency": {
    "replayed": false
  },
  "result": {
    "task": {
      "identifier": "SUPPORT-42",
      "version": 4,
      "acceptance_criteria_markdown": "- [ ] A successful payment sends one confirmation email.\n- [ ] Retrying the payment callback does not send a duplicate.\n- [ ] A failed payment sends no confirmation email."
    }
  }
}
```

Expected result: ok: true returns result.task with the saved replacement and a newer version. The excerpt assumes the fictional task was still version 3. Real versions and bundle IDs come from your fresh reads.

## 6. Read back the saved result and retain the evidence

Invoke get_task_context again. Compare context.task.acceptance_criteria_markdown with the exact approved text. Check the returned version and verify the other task fields and workflow state still match the intended scope.

If a write response is lost, repeat update_task with the same arguments and key while its idempotency receipt is retained. A replay returns idempotency.replayed: true after current access checks, but its task payload is the original stored response. Always read get_task_context again after replay to see later edits and reconcile any mismatch.

Record the approved text, sources, actual saved version and read-back result in the task’s normal conversation/review record. Leave the payment acceptance checks unchecked until the real behavior is tested. Follow your project’s separate workflow and review process for later completion.

### get_task_context · verify arguments

```json
{
  "task": "SUPPORT-42"
}
```

Expected result: ok: true returns the fresh task. In the untouched fictional sequence it is version 4 with those three unchecked criteria. The accepted definition edit is complete; the underlying bug remains open.

## Verification checklist

- [ ] Every Required Context revision chunk was delivered through the same active actor and connection before acknowledgement.
- [ ] The member reviewed and authorized the complete replacement before update_task was invoked.
- [ ] A fresh task read contains the approved criteria and saved version, with the intended source facts, ownership and workflow state preserved.
- [ ] An exact retry within the receipt lifetime has idempotency.replayed: true and does not apply the definition edit twice. Its stored response is followed by a fresh read to identify later authorized edits.
- [ ] The criteria are still unchecked; editing the definition does not prove the payment bug is fixed or authorize completion.

## Recovery

### Access or connection error

Check the selected member/workspace, active membership, project access, machine profile and revoked/expired authorization. Reconnect where required; a local path mapping does not bypass access.

### chunks_missing

Read every chunk of every pinned revision using the same active connection, following next_cursor until null, then retry acknowledgement.

### Stale or expired Required Context

Resolve a fresh bundle with a new key, retrieve all current pinned reading and acknowledge. Review any guidance change before preparing a new write.

### Version conflict

Read the task again, compare the competing change with the reviewed proposal and ask the member to resolve a material difference. Use the new current_version and a new key for the revised edit.

### Idempotency conflict or lost response

Do not change an uncertain write’s arguments or key. Retry exactly while the idempotency receipt is retained and inspect idempotency.replayed, then read current task context. After receipt expiry, reconcile the saved state before a new attempt. A genuinely revised write needs a new key after reconciliation and review.

## Canonical references

- [MCP overview](https://tellenze.com/developers/mcp)
- [Agents: connection and access](https://tellenze.com/help/agents)
- [Required Context](https://tellenze.com/help/required-context)
- [Work-item lifecycle](https://tellenze.com/help/work-items)

Example inputs, approvals and response excerpts are constructed. A supported product path is not proof that your workspace is configured or that the underlying work is complete.

Keep the reference close

Use the current source.

COME TAKE A LOOK

A little less busy.
A lot more together.

Curious? Join the waitlist and see how we welcome your team.

Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.

Join waitlist Start with your email. No payment needed to join.

Make a reviewed agent update and verify it

Before you begin.

A small, concrete request.

Check the saved result.

Keep the intent. Resolve the failure.

Take the complete recipe.

Use the current source.

A little less busy. A lot more together.

A little less busy.
A lot more together.