Skip to main content
Glama
seonmikii

gdc-claude-plugin

by seonmikii

update_task

Partially update a task by sending only the fields to change. Modify status, dates, assignee, or description, and clear fields when required.

Instructions

태스크를 부분 수정(PATCH)한다. 전달한 필드만 갱신된다.

[description — 라벨 섹션 템플릿(평문)] 본문을 교체할 때는 평문 한 문단이 아니라 create_task와 동일한 라벨 섹션 템플릿으로 넘긴다: [요약](필수) → 선택·짝인 [AS-IS]/[TO-BE][작업 내용](필수, - 블렛 한 줄씩). 도구가 GDC 리치텍스트(HTML)로 변환한다(이미 태그로 시작하는 HTML이면 그대로 통과). 체크박스([ ]/[x])와 빌드·검증·테스트·커밋·배포·버전 범프 같은 프로세스 메타 단계는 넣지 않는다. ※ 이 도구는 본문을 통째로 교체한다 — 일부 섹션만 고치거나 블렛만 덧붙일 때는 edit_task_description(replace_section/append_work)을 써서 인라인 이미지 유실을 막는다.

사용자가 수정 권한을 가진 모든 편집 필드를 노출한다(읽기전용 id/number/creator 제외). status/priority/task_type은 해당 프로젝트 enum 'name'(get_project_enums로 확인), 날짜는 'YYYY-MM-DD', parent는 ID. 태그는 수정할 수 없다 — 서버가 본문·댓글의 tagMention에서만 태그를 동기화한다(읽기는 get_task). assignee·participant_ids는 user id 또는 멤버 이름(full_name/username)을 넘기면 자동으로 id로 해석한다. customer는 고객사 id 또는 이름 — 이름은 현재 워크스페이스에서 검색해 정확 일치를 자동 채택, 모호하면 후보 목록으로 안내한다. weight(비중 %)는 WBS 프로젝트 전용 — 비WBS 태스크에 전달하면 호출 전 차단. parent 변경 시 서버가 weight를 자동 초기화한다(weight를 함께 전달하면 그 값 적용). 완료 상태(category=='done')로 전환하면 백엔드가 progress=100·actual_end_date를 자동 보정할 수 있다.

필드 해제(비우기): clear_fields에 필드명 리스트를 전달 — 가능: parent, assignee, customer, planned_start_date, planned_end_date, actual_start_date, actual_end_date, weight. 예) 실제 종료일 비우기 → clear_fields=["actual_end_date"], 고객사 해제 → clear_fields=["customer"]. 같은 필드에 값과 해제를 동시에 전달하면 오류. 관련자 전체 해제는 participant_ids=[].

제약(미충족 시 ValueError로 안내·차단): 예상/실제 시작일 ≤ 종료일, 실제 종료일은 미래 불가, 담당자/관련자는 해당 프로젝트 멤버만 지정 가능.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
parentNo
statusNo
weightNo
task_idYes
assigneeNo
customerNo
priorityNo
progressNo
is_pinnedNo
task_typeNo
descriptionNo
clear_fieldsNo
actual_end_dateNo
participant_idsNo
planned_end_dateNo
actual_start_dateNo
planned_start_dateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly: it discloses PATCH semantics, full description replacement with HTML conversion, weight auto-reset on parent change, done-status auto-correction, clear_fields conflict errors, and validation constraints (ValueError).

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

Conciseness5/5

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

The description is front-loaded with a one-sentence purpose, then organized into labeled sections (description template, editable fields, clearing fields, constraints). It is long but every sentence adds operational detail, with examples, and no fluff—justified for an 18-param tool.

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

Completeness5/5

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

For a complex mutation tool with no annotations, this description is remarkably complete: it covers prerequisites, side effects, error behavior, field semantics, and alternatives. The output schema exists, so return values are not required. It leaves no critical operational gaps.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates extensively: it explains date format (YYYY-MM-DD), enum name requirements, id-or-name resolution for assignee/customer, WBS-only weight, clear_fields usage with examples, and date/member constraints. Almost all 18 parameters are semantically enriched beyond the bare schema.

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

Purpose5/5

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

The description opens with '태스크를 부분 수정(PATCH)한다' (partially updates the task with PATCH) and states '전달한 필드만 갱신된다' (only passed fields are updated). This specific verb+resource+semantics clearly distinguishes it from siblings like edit_task_description and create_task.

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

Usage Guidelines5/5

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

Explicitly names edit_task_description as the alternative for partial section edits to avoid inline image loss, and references get_project_enums for enum values and get_task for tag reading. It gives clear when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seonmikii/gdc-claude-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server