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): 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.
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. 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."
  2. 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."
  3. First observed

TDQS

B3/5.0
Behavior1/5

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

The tool definition's op descriptions expose destructive behavior: work_remove deletes an item from any group, done trims oldest-by-closed, and annotation over-cap evicts entries. This contradicts the annotation destructiveHint=false, and the top-level description adds no reconciling context. An agent relying on the annotation could be misled about the tool's safety profile.

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?

The two sentences are tight, front-loaded with purpose, and include a useful pre-flight tip with no filler. It is concise, though the tool's complexity means most of the burden falls on the schema.

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?

For a five-parameter tool with nested payloads, multiple action/op modes, and no output schema, the top-level description is too thin on its own: it does not mention the describe/validate/patch actions, op distinctions, or return expectations. The rich schema compensates for input coverage, but not fully for selection-level and side-effect context.

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%, and the schema already documents every parameter in depth, including op-specific payloads and caps. The top-level description contributes no additional parameter-level meaning, so the baseline of 3 applies.

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?

The description names a concrete action set — updating work, annotations, and recording completions — and clearly positions this as a mutation tool alongside the title. It is specific enough to distinguish from read-oriented siblings like read_topology, though it does not explicitly differentiate it from the many other write/update siblings.

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?

It gives a real pre-flight heuristic: call describe before composing unfamiliar operations. However, it never states when to prefer patch_topology over a sibling write tool, when not to use it, or which action/op combinations are appropriate for which situations; those details are left to the schema.

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