Skip to main content
Glama
seonmikii

gdc-claude-plugin

by seonmikii

get_task

Fetch a complete task overview with parent, sub-tasks, and related links to create or update work request documents. Returns status, priority, dates, assignee, and more in a single call.

Instructions

태스크 상세를 조회한다(작업 요청 문서 생성·연동용).

task_id는 태스크 id(정수) 또는 제목(문자열) — 제목이면 현재 프로젝트에서 검색해 해석한다(정확 1건이면 채택, 다수면 후보 안내, 0건이면 오류).

제목/내용/상태/우선순위/유형/날짜/진행률/담당자 등 문서 작성에 필요한 필드와 함께 상위 태스크(parent)·하위 태스크(sub_tasks)·연관 태스크(related_tasks) 를 반환한다.

  • sub_tasks: 이 태스크의 하위 태스크 요약 목록(휴지통 제외, 서버 가시성 필터 적용).

  • related_tasks: outgoing/incoming 링크를 방향 유지로 통합({direction, link_type, task}).

  • parent: 직속 상위 태스크 요약(없으면 null).

  • update_task로 쓸 수 있는 값도 함께 읽는다 — actual_start_date/actual_end_date(실제 날짜), customer/customer_name(고객사), weight(비중, WBS 전용), is_pinned(고정), participants(관련자). 수정 전 현재 값 확인과 수정 후 반영 확인에 쓴다.

  • 그 밖에 creator_name(작성자)·tags(태그 이름)·mention_count(댓글 수)·is_archived(숨김)· created_at/updated_at을 함께 반환한다. 상세 API 1회 호출로 모두 받으므로 추가 왕복이 없다(제목 해석 시 검색 1회 추가).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_idYes

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 fully shoulders the transparency burden. It discloses task_id dual-type behavior (integer ID or title string) and title resolution edge cases, sub_tasks exclusion of trash and visibility filters, related_tasks direction preservation, and the single-call/no-round-trip behavior. This is exceptionally rich behavioral context.

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 densely informative yet organized with a purpose sentence, task_id resolution explanation, and bulleted return-field details. Every sentence contributes value, and the structure aids comprehension despite length.

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?

Given the tool's single-parameter but complex output (multiple field groups, parent/subtasks/related tasks, updatable fields, audit fields), the description is remarkably complete. It covers return values, special cases, and integration with update_task, leaving no meaningful gap for the agent.

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?

The input schema only defines task_id as integer or string with no description. The description adds critical semantics: task_id can be an integer ID or a title string, and if a title, it is searched in the current project with exact-match, multiple-candidate, and zero-result behaviors. This fully compensates for the 0% schema coverage.

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 clearly states the tool's core action: '태스크 상세를 조회한다' (retrieve task details), with a specific use case ('작업 요청 문서 생성·연동용'). It distinguishes from sibling list/search tools by emphasizing the detailed single-task nature and including parent, sub_tasks, and related_tasks.

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

Usage Guidelines4/5

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

The description gives explicit use contexts: for work request document creation/linking and for checking current values before/after update_task. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to select it over list/search operations.

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