Skip to main content
Glama
wirkspace

wirk-mcp

Official
by wirkspace

wirk_write

Idempotent

Apply or propose atomic batches of item and link changes with revision checks to prevent stale writes and route review-required edits with reasons.

Instructions

Change items and links atomically. In expect put each changed or linked-from item’s rN and the parent work of a contributes_to link; missing revisions get basis_changed. Context changes apply when you may make them; requires_review means propose with a reason.

Input Schema

NameRequiredDescriptionDefault
modeNo
expectNo{"<ID>": <revision you read>}, e.g. {"5c1e7a90": 3}.
formatNo
reasonNoWhy: required to propose and to archive; to complete wirk, the evidence (tests, link, file path or upload ID).
operationsYes1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id? (me or an ID), due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?, uploads?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?, reservation?, attach_uploads?}}; reservation occupied starts; occupied:G guards any edit; vacant:G releases; replace:G takes over (a reviewer, with a reason, when a person asks) · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites, relies_on or works_at (a person record to a company record), from/to may be $ref of a new item; a cites link also takes target_revision, selector, relation and quotation: the exact text, else quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id} · {op:message.send, ref?, data:{body, title?, to?:[principal], reply_to?, uploads?}}; a board post adds link.create related_to from its $ref to the item · {op:message.acknowledge, messages:[ID]}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears. uploads/attach_uploads: upload IDs or absolute local file paths, stored first; if one fails nothing is written.
request_idNoOptional; named in the receipt; set your own when attaching files. After an uncertain result, resend with that ID.
workspace_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.29
    • changedInput schema / properties / operations / description
      Previous value: -"1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id?, due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?, uploads?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?, attach_uploads?}} · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites, relies_on or works_at (a person record to a company record), from/to may be $ref of a new item; a cites quotation must match the cited text exactly, or quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id} · {op:message.send, ref?, data:{body, title?, to?:[principal], reply_to?, uploads?}} · {op:message.acknowledge, messages:[ID]}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears. uploads/attach_uploads: upload IDs or absolute local file paths, stored first; if one fails nothing is written."New value: +"1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id? (me or an ID), due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?, uploads?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?, reservation?, attach_uploads?}}; reservation occupied starts; occupied:G guards any edit; vacant:G releases; replace:G takes over (a reviewer, with a reason, when a person asks) · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites, relies_on or works_at (a person record to a company record), from/to may be $ref of a new item; a cites link also takes target_revision, selector, relation and quotation: the exact text, else quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id} · {op:message.send, ref?, data:{body, title?, to?:[principal], reply_to?, uploads?}}; a board post adds link.create related_to from its $ref to the item · {op:message.acknowledge, messages:[ID]}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears. uploads/attach_uploads: upload IDs or absolute local file paths, stored first; if one fails nothing is written."
  2. Changed2 schema fields changedv0.4.16
    • changedInput schema / properties / operations / description
      Previous value: -"1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id?, due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?}} · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites, relies_on or works_at (a person record to a company record), from/to may be $ref of a new item; a cites quotation must match the cited text exactly, or quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id} · {op:message.send, ref?, data:{body, title?, to?:[principal], reply_to?}} · {op:message.acknowledge, messages:[ID]}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears."New value: +"1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id?, due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?, uploads?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?, attach_uploads?}} · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites, relies_on or works_at (a person record to a company record), from/to may be $ref of a new item; a cites quotation must match the cited text exactly, or quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id} · {op:message.send, ref?, data:{body, title?, to?:[principal], reply_to?, uploads?}} · {op:message.acknowledge, messages:[ID]}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears. uploads/attach_uploads: upload IDs or absolute local file paths, stored first; if one fails nothing is written."
    • changedInput schema / properties / request_id / description
      Previous value: -"Optional; generated and named in the receipt. After an uncertain result, resend with that ID."New value: +"Optional; named in the receipt; set your own when attaching files. After an uncertain result, resend with that ID."
  3. Changed1 schema field changedv0.4.15
    • changedInput schema / properties / operations / description
      Previous value: -"1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id?, due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?}} · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites or relies_on, from/to may be $ref of a new item; a cites quotation must match the cited text exactly, or quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears."New value: +"1-32 of: {op:item.create, ref?, data:{title, body?, work?:{owner_id?, due_at?, criteria?:[{text}]}, context?:{level, state?, steward_id?, open?}, fields?}, allow_duplicate_of?} · {op:item.edit, id, patch:{title?, body?, work?, fields?}} · {op:link.create, data:{type, from, to}}, type related_to, contributes_to, requires, cites, relies_on or works_at (a person record to a company record), from/to may be $ref of a new item; a cites quotation must match the cited text exactly, or quotation_mismatch · {op:link.remove, id} · {op:item.archive, id} · {op:item.restore, id} · {op:message.send, ref?, data:{body, title?, to?:[principal], reply_to?}} · {op:message.acknowledge, messages:[ID]}. work makes an item work, context makes it context (level organization or initiative); fields maps a field to an option, null clears."
  4. First observedv0.4.0

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=true) the description discloses the atomicity contract, optimistic-concurrency behavior via revisions ('missing revisions get basis_changed'), and the review/propose escalation path. It does not say what the receipt looks like or how partial failures are reported, but the safety profile added here is well above annotation coverage.

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

Conciseness3/5

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

The purpose is front-loaded and there is no filler, but the two follow-on sentences are densely packed clauses that trade readability for brevity. For a tool with eight operation types, the compression pushes detail an agent needs out of reach rather than earning tightness.

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

Completeness4/5

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

The heavy per-operation detail correctly lives in the operations schema, so the description need not repeat it, and there is no output schema to explain. What remains missing is the receipt/return shape and the fact that reason is also mandatory for archiving, both of which the schema mentions only in passing.

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 coverage is 57%, and the description adds real meaning for 'expect' (which IDs and revisions to supply, and the contributes_to parent rule) and for 'reason' tied to proposing. It says nothing about 'mode', 'format', 'workspace_id' or 'request_id', and those gaps are only partially covered by the schema's own descriptions, so a baseline 3 fits.

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 first sentence gives a specific verb and resource set ('Change items and links atomically'), which cleanly separates it from the read-oriented siblings wirk_query, wirk_show and wirk_status. The remaining sentences stay on topic but rely on internal vocabulary (rN, basis_changed, contributes_to) that softens the clarity slightly.

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?

'Context changes apply when you may make them; requires_review means propose with a reason' does hint at the apply-vs-propose decision, but only for the review case. It never names a sibling tool or states when to prefer this batch write over, say, wirk_review, and the conditions are phrased as jargon rather than decision rules.

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

Deploy Server

Other Tools