PCD (Portable Context Deck)

Update Deck

update_deck

Revise a container or specialist deck configuration.

Input Schema

TableJSON Schema

Name	Required	Description
`load`	No	Change the deck's load handle (the boot key). Lowercase, hyphens allowed, max 24 chars, must start with letter or number, must not be reserved (meta/console/container-context), must be unique per user. Mirrored onto raw_json.load.
`name`	No	Rename the deck (display name, max 64 chars). Optional — provide to rename. Mirrored onto raw_json.name.
`action`	No	Default 'write'. 'validate': pre-send check across all three write surfaces (content field caps via the same enforceDeckCaps the write runs, content_ops op/field vocabulary, name ≤64, load format) WITHOUT writing; returns { valid, missing_required[], over_cap: [{field, len, cap}], not_checked? }. Deck resolution, merged-content caps, and content_ops application still run at write time. No identifier needed for validate.
`handle`	No	Alternative identifier — deck.load handle. Use when neither deck_id nor container_id is at hand.
`content`	No	Partial content patch. Shape: intent (≤600), description (specialized-context only, ≤300 — container-context rejects it; intent is the container's single what-is-this answer), guidelines (instruction_item[]), out_of_bounds (instruction_item[]), data_refs, file_map. file_map is keyed by stable reference name; every item is { path: string, description?: string }, stays deck-local, and key-merges with existing (null deletes a key). instruction_item is { rule, priority, shared? } — per-item shared governs what flows to specialized loads (guidelines/data_refs opt-in via shared:true; out_of_bounds opt-out via shared:false). data_refs entries take optional declaration-layer knobs: read {projection: 'outline'\|'summary' \| sections: string[]} on medium='kb_record' (grounding grain) and routing 'pcd'\|'direct'\|'auto' on medium='mcp_connection' (broker vs client reach); a data_ref of type 'flow' points at a flow record — medium 'kb_record', never mandatory, no read knob, at most 3 per deck; rejected on other mediums. Most fields REPLACE on provided — prefer content_ops for single-item edits on the three arrays. session_modes retired — sending it rejects. Optional — may be omitted when only patching name/load.
`deck_id`	No	Preferred identifier — deck UUID. Required for specialized-context (since multiple per container).
`contract`	No	Help mode — return the complete contract with no operation performed.
`deck_type`	Yes	User-editable deck type. Platform-managed types (container-meta, user-meta, company-meta) are NOT writable through this tool — they live behind their dedicated tools.
`content_ops`	No	Per-item ops against the CURRENT stored arrays; no whole-array resend. Applied sequentially, first failure rejects the call (no partial application). A field addressed here must not also appear in content. The post-ops array flows through the same caps + knob validation as a whole-array write.
`container_id`	No	Alternative identifier — container UUID. Only valid when deck_type='container-context' (1-per-container).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 29, 2026

changedInput schema / properties / content / description

Previous value: -"Partial content patch. Shape: intent (≤600), description (specialized-context only, ≤300 — container-context rejects it; intent is the container's single what-is-this answer), guidelines (instruction_item[]), out_of_bounds (instruction_item[]), data_refs, file_map. file_map is keyed by stable reference name; every item is { path: string, description?: string }, stays deck-local, and key-merges with existing (null deletes a key). instruction_item is { rule, priority, shared? } — per-item shared governs what flows to specialized loads (guidelines/data_refs opt-in via shared:true; out_of_bounds opt-out via shared:false). data_refs entries take optional declaration-layer knobs: read {projection: 'outline'|'summary' | sections: string[]} on medium='kb_record' (grounding grain) and routing 'pcd'|'direct'|'auto' on medium='mcp_connection' (broker vs client reach); rejected on other mediums. Most fields REPLACE on provided — prefer content_ops for single-item edits on the three arrays. session_modes retired — sending it rejects. Optional — may be omitted when only patching name/load."New value: +"Partial content patch. Shape: intent (≤600), description (specialized-context only, ≤300 — container-context rejects it; intent is the container's single what-is-this answer), guidelines (instruction_item[]), out_of_bounds (instruction_item[]), data_refs, file_map. file_map is keyed by stable reference name; every item is { path: string, description?: string }, stays deck-local, and key-merges with existing (null deletes a key). instruction_item is { rule, priority, shared? } — per-item shared governs what flows to specialized loads (guidelines/data_refs opt-in via shared:true; out_of_bounds opt-out via shared:false). data_refs entries take optional declaration-layer knobs: read {projection: 'outline'|'summary' | sections: string[]} on medium='kb_record' (grounding grain) and routing 'pcd'|'direct'|'auto' on medium='mcp_connection' (broker vs client reach); a data_ref of type 'flow' points at a flow record — medium 'kb_record', never mandatory, no read knob, at most 3 per deck; rejected on other mediums. Most fields REPLACE on provided — prefer content_ops for single-item edits on the three arrays. session_modes retired — sending it rejects. Optional — may be omitted when only patching name/load."

Changed2 schema fields changedSep 7, 2026

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."

First observedSep 7, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, and 'revise' is consistent with a mutation, so there is no contradiction. However, the description adds nothing beyond that: it does not mention the validate/contract help modes, the no-partial-application semantics, or the replace-on-provided behavior, all of which are disclosed only in the schema.

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?

A single front-loaded sentence with zero redundancy, which is good for conciseness. It is arguably too thin for a tool of this complexity, but as a pure sizing/structure judgment there is no wasted text.

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?

This is a high-complexity mutation tool (10 params, nested objects, nested content_ops, dual deck types) with no output schema, so the description carries some burden. The exceptionally rich schema fields compensate substantially for the one-line description, but the description still omits the identity-resolution fallback logic and the help modes needed to call it correctly.

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 already documents all ten parameters in depth (load format, action modes, content shape, content_ops matching). The one-line description adds no parameter meaning at all, making the baseline 3 the correct score.

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 clear verb ('revise') and resource (deck configuration) and names the two deck types it operates on (container/specialist). It does not, however, distinguish itself from nearby siblings like create_deck, update_meta, or patch_topology, so the agent must infer the boundary from the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use, when-not-to-use, or alternative routing information. Critical guidance such as 'platform-managed types live behind dedicated tools' and the validate-vs-write mode selection appears only inside the parameter schema, not in the tool description.

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

All PCD (Portable Context Deck) tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?