Skip to main content
Glama

PCD (Portable Context Deck)

Patch Topology

patch_topology

Update work and annotations or record a completion. Describe before composing unfamiliar operations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opNoRequired when action='patch' or 'validate'. Ignored when action='describe'. work_patch: partial merge on an existing item by `what` across all groups — update goal/state/next/assigned_to, append refs — without resending the item (fields per topology 3.0). The primary keep-it-current op: `state` is the thread's current standing (renamed from detail), `next` its own next move — keep both current, they replace the retired session summary. work_upsert: create an item, or fully reshape one (match on `what`) in work.{active|paused|blocked|done}. Items carry goal/state/next/refs[]/annotations[] and assigned_to — advisory deck-handle label naming the owning deck. This is the reshape op the over_shape boot flag points at. work_transition: move an existing item by `what` to a different group. work_remove: remove an item by `what` from any group. work_annotate: append a typed annotation to a work item's annotations[] (renamed from note_append, topology 3.1.0). did_append: record a completion into the did trail (its own table since topology 3.0); append-only, attribution on every entry, optional work_ref to the closed item, nudges if that item is still open. Retired (topology 3.0): summary_set + session_mode_set (slots dissolved) and client op_append (audit is worker-stamped at source). Work items are pointers plus current standing, never documents (topology 3.2): what/goal/state/next/blocker are capped at 120/250/600/250/600 chars (a lookup what is never capped) and refs[] at 8 typed pointers; all three write ops reject over-cap rather than truncating, and check only what you send.
actionYesRequired. describe: returns the contract envelope (op catalogue, per-op payloads, server-side caps, parallel-safe property) — use as a pre-flight before composing a patch. validate: pre-send check — runs required-field + char-cap validation on a candidate op + payload WITHOUT writing; returns { valid, missing_required[], over_cap: [{field, len, cap}], not_checked? } so a long compose is checked in one cheap call instead of paying a rejected write to learn a length. State-dependent checks (item existence, group capacity) still run at write time. patch: applies one op against state. Pre-flight pattern: describe → choose op → (validate when composing long) → patch.
payloadNoRequired when action='patch' or 'validate' (validate takes the same candidate payload the patch would send). Ignored when action='describe'. Op-specific payload. work_patch: {what, patch: {goal?, state?, next?, assigned_to?, refs_append?: [...]}} — partial merge on the item matched by `what` (any group); provided fields update, untouched fields survive; refs_append appends to refs[] (exact duplicates skipped with a warning); empty or unknown-field patches are rejected with the patchable field list (`detail` rejects — renamed to `state`). `state` REPLACES — write the new standing from scratch, never the old text plus a layer; goal/state/next reject over 250/600/250 chars. Each appended ref is {kind, label?, locator}: kinds are knowledge | skill | signal | connection | url | file, the locator is the one its kind needs, and nothing else is accepted; the merged refs[] caps at 8. Stamps item.updated (the freshness clock behind the boot hygiene flags). assigned_to soft-validates like work_upsert. work_upsert: {group: 'active'|'paused'|'blocked'|'done', item: {what, goal?, state?, next?, refs?: [{kind, label?, <locator>}], annotations?, assigned_to?, ...}} — `detail` is rejected (renamed to `state`, topology 3.0); blocked requires `blocker`; done auto-stamps `closed` if missing; item.updated stamps on every upsert. Caps: active/paused 5, blocked 3, done 5 — over-cap on active/paused/blocked is REJECTED with a make-room hint (work items are never silently evicted); done alone trims oldest-by-closed. assigned_to is an advisory deck handle: soft-validated against the container's decks, mismatch warns in the envelope, never rejects. The sent item is checked against the work-item caps and ref shape; knowledge/skill/signal refs must resolve in this container, and a connection ref naming nothing the container declared warns and lands. work_transition: {what, to: 'active'|'paused'|'blocked'|'done', patch?: {...}} — transitioning to blocked requires `blocker` in patch; moving into a full active/paused/blocked group is REJECTED (make room first — the source item stays put), done trims oldest-by-closed. Only the patch you send is checked against the caps and ref shape — the stored item's other fields are left alone, so a bare transition of a legacy over-shape item passes. work_remove: {what}. work_annotate: {what, type, text: string|string[], actor?} — `what` matches the work item's `what` field (the same item key as work_patch/work_transition/work_remove); `type` is open vocabulary (gotchas, choice, observation, shipped, attempt, risk, …); `text` is the annotation content, aligned with did_append. Char caps (150 chars/bullet, 900 total) are REJECTED over-cap with a field+limit message (never truncated) — tighten and resend; the 6-bullet cap drops oldest. Per-item cap 10: an over-cap append succeeds and RETURNS the evicted annotation in evicted_annotations (annotations are memory, never silently destroyed) — graduate it to knowledge or fold it into the item if it still matters. did_append: {text, work_ref?, by?} — record a COMPLETION into the did trail (topology 3.0): `text` ≤250 chars (rejected over-cap); optional `work_ref` (a work item's `what` this completion closes) and `by` (your deck handle). Append-only, retention keep-everything; boot ships a tail of 8, read_topology pages deeper (trail='did'). A work_ref still in active/paused returns a nudge. Use for finished things — in-flight standing stays on the work item's `state` via work_patch.
contractNoHelp mode — return the complete contract with no operation performed.
container_idYesContainer ID — required. Per-container Durable Object isolate serialises writes — parallel patch_topology calls for the same container queue inside the DO; calls for different containers run in independent isolates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / op / description
      Previous value: -"Required when action='patch' or 'validate'. Ignored when action='describe'. work_patch: partial merge on an existing item by `what` across all groups — update goal/state/next/assigned_to, append refs — without resending the item (fields per topology 3.0). The primary keep-it-current op: `state` is the thread's current standing (renamed from detail), `next` its own next move — keep both current, they replace the retired session summary. work_upsert: create an item, or fully reshape one (match on `what`) in work.{active|paused|blocked|done}. Items carry goal/state/next/refs[]/annotations[] and assigned_to — advisory deck-handle label naming the owning deck. This is the reshape op the over_shape boot flag points at. work_transition: move an existing item by `what` to a different group. work_remove: remove an item by `what` from any group. work_annotate: append a typed annotation to a work item's annotations[] (renamed from note_append, topology 3.1.0). did_append: record a completion into the did trail (its own table since topology 3.0); append-only, attribution on every entry, optional work_ref to the closed item, nudges if that item is still open. Retired (topology 3.0): summary_set + session_mode_set (slots dissolved) and client op_append (audit is worker-stamped at source). Work items are pointers plus current standing, never documents (topology 3.2): goal/state/next are capped at 250/600/250 chars and refs[] at 8 typed pointers; all three write ops reject over-cap rather than truncating, and check only what you send."New value: +"Required when action='patch' or 'validate'. Ignored when action='describe'. work_patch: partial merge on an existing item by `what` across all groups — update goal/state/next/assigned_to, append refs — without resending the item (fields per topology 3.0). The primary keep-it-current op: `state` is the thread's current standing (renamed from detail), `next` its own next move — keep both current, they replace the retired session summary. work_upsert: create an item, or fully reshape one (match on `what`) in work.{active|paused|blocked|done}. Items carry goal/state/next/refs[]/annotations[] and assigned_to — advisory deck-handle label naming the owning deck. This is the reshape op the over_shape boot flag points at. work_transition: move an existing item by `what` to a different group. work_remove: remove an item by `what` from any group. work_annotate: append a typed annotation to a work item's annotations[] (renamed from note_append, topology 3.1.0). did_append: record a completion into the did trail (its own table since topology 3.0); append-only, attribution on every entry, optional work_ref to the closed item, nudges if that item is still open. Retired (topology 3.0): summary_set + session_mode_set (slots dissolved) and client op_append (audit is worker-stamped at source). Work items are pointers plus current standing, never documents (topology 3.2): what/goal/state/next/blocker are capped at 120/250/600/250/600 chars (a lookup what is never capped) and refs[] at 8 typed pointers; all three write ops reject over-cap rather than truncating, and check only what you send."
  2. Changed2 schema fields changed
    • changedInput schema / properties / op / description
      Previous value: -"Required when action='patch' or 'validate'. Ignored when action='describe'. work_patch: partial merge on an existing item by `what` across all groups — update goal/state/next/assigned_to, append refs — without resending the item (fields per topology 3.0). The primary keep-it-current op: `state` is the thread's current standing (renamed from detail), `next` its own next move — keep both current, they replace the retired session summary. work_upsert: create an item, or fully reshape one (match on `what`) in work.{active|paused|blocked|done}. Items carry goal/state/next/refs[]/annotations[] and assigned_to — advisory deck-handle label naming the owning deck. work_transition: move an existing item by `what` to a different group. work_remove: remove an item by `what` from any group. work_annotate: append a typed annotation to a work item's annotations[] (renamed from note_append, topology 3.1.0). did_append: record a completion into the did trail (its own table since topology 3.0); append-only, attribution on every entry, optional work_ref to the closed item, nudges if that item is still open. Retired (topology 3.0): summary_set + session_mode_set (slots dissolved) and client op_append (audit is worker-stamped at source)."New value: +"Required when action='patch' or 'validate'. Ignored when action='describe'. work_patch: partial merge on an existing item by `what` across all groups — update goal/state/next/assigned_to, append refs — without resending the item (fields per topology 3.0). The primary keep-it-current op: `state` is the thread's current standing (renamed from detail), `next` its own next move — keep both current, they replace the retired session summary. work_upsert: create an item, or fully reshape one (match on `what`) in work.{active|paused|blocked|done}. Items carry goal/state/next/refs[]/annotations[] and assigned_to — advisory deck-handle label naming the owning deck. This is the reshape op the over_shape boot flag points at. work_transition: move an existing item by `what` to a different group. work_remove: remove an item by `what` from any group. work_annotate: append a typed annotation to a work item's annotations[] (renamed from note_append, topology 3.1.0). did_append: record a completion into the did trail (its own table since topology 3.0); append-only, attribution on every entry, optional work_ref to the closed item, nudges if that item is still open. Retired (topology 3.0): summary_set + session_mode_set (slots dissolved) and client op_append (audit is worker-stamped at source). Work items are pointers plus current standing, never documents (topology 3.2): goal/state/next are capped at 250/600/250 chars and refs[] at 8 typed pointers; all three write ops reject over-cap rather than truncating, and check only what you send."
    • changedInput schema / properties / payload / description
      Previous value: -"Required when action='patch' or 'validate' (validate takes the same candidate payload the patch would send). Ignored when action='describe'. Op-specific payload. work_patch: {what, patch: {goal?, state?, next?, assigned_to?, refs_append?: [...]}} — partial merge on the item matched by `what` (any group); provided fields update, untouched fields survive; refs_append appends to refs[] (exact duplicates skipped with a warning); empty or unknown-field patches are rejected with the patchable field list (`detail` rejects — renamed to `state`). Stamps item.updated (the freshness clock behind the boot hygiene flags). assigned_to soft-validates like work_upsert. work_upsert: {group: 'active'|'paused'|'blocked'|'done', item: {what, goal?, state?, next?, refs?, annotations?, assigned_to?, ...}} — `detail` is rejected (renamed to `state`, topology 3.0); blocked requires `blocker`; done auto-stamps `closed` if missing; item.updated stamps on every upsert. Caps: active/paused 5, blocked 3, done 5 — over-cap on active/paused/blocked is REJECTED with a make-room hint (work items are never silently evicted); done alone trims oldest-by-closed. assigned_to is an advisory deck handle: soft-validated against the container's decks, mismatch warns in the envelope, never rejects. work_transition: {what, to: 'active'|'paused'|'blocked'|'done', patch?: {...}} — transitioning to blocked requires `blocker` in patch; moving into a full active/paused/blocked group is REJECTED (make room first — the source item stays put), done trims oldest-by-closed. work_remove: {what}. work_annotate: {what, type, text: string|string[], actor?} — `what` matches the work item's `what` field (the same item key as work_patch/work_transition/work_remove); `type` is open vocabulary (gotchas, choice, observation, shipped, attempt, risk, …); `text` is the annotation content, aligned with did_append. Char caps (150 chars/bullet, 900 total) are REJECTED over-cap with a field+limit message (never truncated) — tighten and resend; the 6-bullet cap drops oldest. Per-item cap 10: an over-cap append succeeds and RETURNS the evicted annotation in evicted_annotations (annotations are memory, never silently destroyed) — graduate it to knowledge or fold it into the item if it still matters. did_append: {text, work_ref?, by?} — record a COMPLETION into the did trail (topology 3.0): `text` ≤250 chars (rejected over-cap); optional `work_ref` (a work item's `what` this completion closes) and `by` (your deck handle). Append-only, retention keep-everything; boot ships a tail of 8, read_topology pages deeper (trail='did'). A work_ref still in active/paused returns a nudge. Use for finished things — in-flight standing stays on the work item's `state` via work_patch."New value: +"Required when action='patch' or 'validate' (validate takes the same candidate payload the patch would send). Ignored when action='describe'. Op-specific payload. work_patch: {what, patch: {goal?, state?, next?, assigned_to?, refs_append?: [...]}} — partial merge on the item matched by `what` (any group); provided fields update, untouched fields survive; refs_append appends to refs[] (exact duplicates skipped with a warning); empty or unknown-field patches are rejected with the patchable field list (`detail` rejects — renamed to `state`). `state` REPLACES — write the new standing from scratch, never the old text plus a layer; goal/state/next reject over 250/600/250 chars. Each appended ref is {kind, label?, locator}: kinds are knowledge | skill | signal | connection | url | file, the locator is the one its kind needs, and nothing else is accepted; the merged refs[] caps at 8. Stamps item.updated (the freshness clock behind the boot hygiene flags). assigned_to soft-validates like work_upsert. work_upsert: {group: 'active'|'paused'|'blocked'|'done', item: {what, goal?, state?, next?, refs?: [{kind, label?, <locator>}], annotations?, assigned_to?, ...}} — `detail` is rejected (renamed to `state`, topology 3.0); blocked requires `blocker`; done auto-stamps `closed` if missing; item.updated stamps on every upsert. Caps: active/paused 5, blocked 3, done 5 — over-cap on active/paused/blocked is REJECTED with a make-room hint (work items are never silently evicted); done alone trims oldest-by-closed. assigned_to is an advisory deck handle: soft-validated against the container's decks, mismatch warns in the envelope, never rejects. The sent item is checked against the work-item caps and ref shape; knowledge/skill/signal refs must resolve in this container, and a connection ref naming nothing the container declared warns and lands. work_transition: {what, to: 'active'|'paused'|'blocked'|'done', patch?: {...}} — transitioning to blocked requires `blocker` in patch; moving into a full active/paused/blocked group is REJECTED (make room first — the source item stays put), done trims oldest-by-closed. Only the patch you send is checked against the caps and ref shape — the stored item's other fields are left alone, so a bare transition of a legacy over-shape item passes. work_remove: {what}. work_annotate: {what, type, text: string|string[], actor?} — `what` matches the work item's `what` field (the same item key as work_patch/work_transition/work_remove); `type` is open vocabulary (gotchas, choice, observation, shipped, attempt, risk, …); `text` is the annotation content, aligned with did_append. Char caps (150 chars/bullet, 900 total) are REJECTED over-cap with a field+limit message (never truncated) — tighten and resend; the 6-bullet cap drops oldest. Per-item cap 10: an over-cap append succeeds and RETURNS the evicted annotation in evicted_annotations (annotations are memory, never silently destroyed) — graduate it to knowledge or fold it into the item if it still matters. did_append: {text, work_ref?, by?} — record a COMPLETION into the did trail (topology 3.0): `text` ≤250 chars (rejected over-cap); optional `work_ref` (a work item's `what` this completion closes) and `by` (your deck handle). Append-only, retention keep-everything; boot ships a tail of 8, read_topology pages deeper (trail='did'). A work_ref still in active/paused returns a nudge. Use for finished things — in-flight standing stays on the work item's `state` via work_patch."
  3. Changed2 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / contract / description
      Previous value: -"Help mode — pass true to receive this tool's full _meta.contract (all variants) with NO operation performed."New value: +"Help mode — return the complete contract with no operation performed."
  4. First observed

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the lower bar applies. The description nonetheless adds almost no behavioral context of its own — nothing about caps, rejection/truncation behavior, annotation eviction, or soft-validation, all of which live only in schema property text.

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?

Two short sentences with the main purpose front-loaded and a secondary procedural hint following. No wasted words, though it is arguably terse for a five-parameter, nested-payload mutation tool.

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?

The very detailed schema and 100% parameter coverage compensate for the description's brevity, and no output schema exists so return values need not be covered. However, the description leaves the tool's relationship to siblings like read_topology, team_work, and commit unstated, which is a real routing gap for such a complex write tool.

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 100%, so the schema fully documents the five parameters (op, action, payload, contract, container_id) including enum semantics. The description contributes nothing parameter-specific, which is the expected baseline 3 when the schema carries the full load.

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 set — 'Update work and annotations or record a completion' — which is clearer than the name 'patch_topology' alone, since the tool actually performs work-item ops, annotations, and did-trail appends rather than generic topology patching. It does not name the read counterpart (read_topology) or other plausible siblings (team_work, commit), so differentiation is left to inference.

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?

The only guidance is 'Describe before composing unfamiliar operations,' which hints at the describe pre-flight but does not say when to use this tool versus team_work, commit, or write_knowledge. The richer describe → validate → patch pattern lives in the schema, not the description, so routing guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources