PCD (Portable Context Deck)

Team Work

team_work

Read or advance shared work, publish versioned contributions, and request or respond to exact-version reviews in one permission-checked team destination.

Input Schema

TableJSON Schema

Name	Required	Description
`work`	No	Work item on create_work, or a field patch on update_work/transition_work. what/goal/state/next/blocker are capped at 120/250/600/250/600 chars and rejected over the cap, never truncated; refs holds at most 8 typed pointers. Only the fields you send are checked. Provenance is server-stamped.
`limit`	No	Result cap: read_reviews and list_documents default to 20 with maximum 50; search_documents defaults to 10 with maximum 20.
`query`	No
`title`	No
`action`	Yes	Operation. Call describe before composing an unfamiliar contribution, work write, or document action; describe.document_actions is the action-specific contract.
`offset`	No
`reason`	No
`comment`	No
`content`	No
`summary`	No
`work_id`	No	Stable shared-work UUID for update_work or transition_work.
`category`	No
`contract`	No	Help mode — return the complete contract with no operation performed.
`revision`	No	Immutable document revision to check with check_document; defaults to the current revision. It is not an optimistic write token.
`standing`	No
`record_id`	No	Versioned Team record. Required by record- and document-specific reads and writes; inspect describe.document_actions for each document action.
`work_refs`	No
`feedback_id`	No
`to_revision`	No
`contribution`	No	Structured immutable contribution body. Reviews are accepted only by respond_review and require basis.reviewed_version.
`raw_markdown`	No
`review_scope`	No	read_reviews routing filter; defaults to requests open to the team or assigned to the caller.
`target_group`	No	Required for create_work and transition_work.
`from_revision`	No
`review_status`	No	read_reviews lifecycle filter; defaults to open.
`request_content`	No	Review question or requested checks for request_review.
`source_revision`	No
`expected_revision`	No	Current immutable record revision required for revise_contribution, mark_ready, revise_document, and submit_document.
`review_request_id`	No	Review-request signal UUID for response or resolution.
`reviewed_revision`	No	Exact ready proposal revision pinned by request_review.
`team_container_id`	No	Exact team destination; required for every action except describe.
`assigned_member_id`	No	Optional active owner/editor UUID; omit or null to open the request to the team.
`reviewed_record_id`	No	Contribution record whose exact ready revision is being requested for review.
`expected_work_revision`	No	Required optimistic version for every shared-work write.
`expected_request_revision`	No	Optimistic request version required by resolve_review.
`expected_transition_revision`	No	Current lifecycle transition revision required by contribution and document writes; open_document_round accepts this version but not expected_revision.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / work / description

Previous value: -"Work item on create_work, or a field patch on update_work/transition_work. goal/state/next are capped at 250/600/250 chars and rejected over the cap, never truncated; refs holds at most 8 typed pointers. Only the fields you send are checked. Provenance is server-stamped."New value: +"Work item on create_work, or a field patch on update_work/transition_work. what/goal/state/next/blocker are capped at 120/250/600/250/600 chars and rejected over the cap, never truncated; refs holds at most 8 typed pointers. Only the fields you send are checked. Provenance is server-stamped."

Changed12 schema fields changedSep 25, 2026
- changedInput schema / properties / work / description
```
Previous value: -"Work item on create_work, or a field patch on update_work/transition_work. Provenance is server-stamped."New value: +"Work item on create_work, or a field patch on update_work/transition_work. goal/state/next are capped at 250/600/250 chars and rejected over the cap, never truncated; refs holds at most 8 typed pointers. Only the fields you send are checked. Provenance is server-stamped."
```
- removedInput schema / properties / work / properties / blocker / maxLength
```
Removed value: -1000
```
- removedInput schema / properties / work / properties / blocker / minLength
```
Removed value: -1
```
- removedInput schema / properties / work / properties / goal / maxLength
```
Removed value: -1000
```
- removedInput schema / properties / work / properties / goal / minLength
```
Removed value: -1
```
- removedInput schema / properties / work / properties / next / maxLength
```
Removed value: -1000
```
- removedInput schema / properties / work / properties / next / minLength
```
Removed value: -1
```
- addedInput schema / properties / work / properties / refs
```
Added value: +{
+  "description": "Typed pointers {kind, label?, locator}; sending refs replaces the stored array. See describe.work_item_shape.",
+  "items": {},
+  "type": "array"
+}
```
- removedInput schema / properties / work / properties / state / maxLength
```
Removed value: -2000
```
- removedInput schema / properties / work / properties / state / minLength
```
Removed value: -1
```
- removedInput schema / properties / work / properties / what / maxLength
```
Removed value: -200
```
- removedInput schema / properties / work / properties / what / minLength
```
Removed value: -1
```

Changed6 schema fields changedSep 17, 2026

changedInput schema / properties / action / description

Previous value: -"Operation. Call describe before composing an unfamiliar contribution or work write."New value: +"Operation. Call describe before composing an unfamiliar contribution, work write, or document action; describe.document_actions is the action-specific contract."

changedInput schema / properties / expected_revision / description

Previous value: -"Current proposal revision required for revise_contribution and mark_ready."New value: +"Current immutable record revision required for revise_contribution, mark_ready, revise_document, and submit_document."

changedInput schema / properties / expected_transition_revision / description

Previous value: -"Current transition revision required for revise_contribution and mark_ready."New value: +"Current lifecycle transition revision required by contribution and document writes; open_document_round accepts this version but not expected_revision."

changedInput schema / properties / limit / description

Previous value: -"Maximum review requests returned; defaults to 20."New value: +"Result cap: read_reviews and list_documents default to 20 with maximum 50; search_documents defaults to 10 with maximum 20."

changedInput schema / properties / record_id / description

Previous value: -"Versioned team contribution record for reads, revision, or readiness."New value: +"Versioned Team record. Required by record- and document-specific reads and writes; inspect describe.document_actions for each document action."

addedInput schema / properties / revision / description

Added value: +"Immutable document revision to check with check_document; defaults to the current revision. It is not an optimistic write token."

Changed14 schema fields changedSep 17, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "describe",
-  "read_work",
-  "read_record",
-  "create_work",
-  "update_work",
-  "transition_work",
-  "publish_contribution",
-  "revise_contribution",
-  "mark_ready",
-  "read_reviews",
-  "request_review",
-  "respond_review",
-  "resolve_review"
-]New value: +[
+  "describe",
+  "read_work",
+  "read_record",
+  "create_work",
+  "update_work",
+  "transition_work",
+  "publish_contribution",
+  "revise_contribution",
+  "mark_ready",
+  "read_reviews",
+  "request_review",
+  "respond_review",
+  "resolve_review",
+  "create_document",
+  "revise_document",
+  "open_document_round",
+  "check_document",
+  "give_feedback",
+  "reply_feedback",
+  "treat_feedback",
+  "submit_document",
+  "close_round",
+  "list_documents",
+  "search_documents",
+  "read_document_history",
+  "diff_document"
+]

addedInput schema / properties / category

Added value: +{
+  "enum": [
+    "decision",
+    "reference",
+    "manual",
+    "milestone",
+    "note"
+  ],
+  "type": "string"
+}

addedInput schema / properties / comment

Added value: +{
+  "maxLength": 2000,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / content

Added value: +{
+  "maxLength": 4000,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / feedback_id

Added value: +{
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

addedInput schema / properties / from_revision

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "maximum": 500,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / query

Added value: +{
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / reason

Added value: +{
+  "maxLength": 1000,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / revision

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / source_revision

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / standing

Added value: +{
+  "enum": [
+    "active",
+    "working",
+    "archived",
+    "all"
+  ],
+  "type": "string"
+}

addedInput schema / properties / to_revision

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / work_refs

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "relationship": {
+        "maxLength": 500,
+        "minLength": 1,
+        "type": "string"
+      },
+      "work_id": {
+        "format": "uuid",
+        "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "work_id",
+      "relationship"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

AddedSep 11, 2026

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare destructiveHint=false and openWorldHint=false, and the description's only added behavioral fact is 'permission-checked' plus 'versioned contributions'. It does not disclose the mixed read/write nature of this single tool, that contributions are immutable once published, the optimistic-revision concurrency model, or which actions can alter stored state irreversibly — all of which matter greatly for a 26-action tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The prose itself is tight and front-loaded, but for a tool exposing 26 actions and 36 parameters a single sentence is under-specification rather than conciseness. Nothing is wasted, yet far too little is said relative to the surface area.

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

Completeness2/5

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

This is the most complex tool in the set — 26 actions, deep nested contribution/work objects, no output schema, and revision-based concurrency — yet the description covers only the work/contribution/review slice and omits the entire document workflow, the required describe-before-write protocol, and the optimistic versioning requirements documented in the schema.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 36 parameters and only 58% schema description coverage, the description is expected to compensate, and it does not: action, team_container_id, expected_work_revision, limit, and the various expected_*_revision tokens receive no explanation beyond the words 'versioned' and 'exact-version'. Those two words gesture at the revision-pinning contract but convey no usable semantics for the parameter set.

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

Purpose3/5

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

The sentence names recognizable verb+resource families (read/advance shared work, publish contributions, request/respond to reviews) and scopes them to a 'permission-checked team destination', which distinguishes it from generic write tools. But the action enum contains 26 operations, roughly half of them document-related (create_document, submit_document, diff_document, give_feedback, close_round, etc.), and the description never mentions documents at all, so an agent cannot infer the tool's true remit from the description alone.

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?

There is no when-to-use guidance and no routing away from siblings such as commit, write_knowledge, read_feedback, or write_feedback, all of which plausibly overlap with the review/contribution surface. The most valuable usage instruction ('call describe before composing an unfamiliar contribution, work write, or document action') lives in the action schema, not the description, so the description itself supplies essentially no decision guidance.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?