Skip to main content
Glama

create-task-comment

Add comments to Dooray tasks to provide progress updates, respond to discussions, log information, or attach files, keeping task discussions organized and accessible.

Instructions

Add a comment (댓글) to an existing Dooray task.

This tool creates a comment on a task, separate from editing the task body itself. Use this for:

  • Adding progress updates or status notes

  • Responding to questions or discussions

  • Logging information related to the task

  • Attaching files with context

When to Use:

  • create-task-comment: For adding discussion, updates, or notes (댓글)

  • update-task: For modifying the task description, title, or metadata

URL Pattern Recognition: When given a Dooray task URL like "https://nhnent.dooray.com/task/PROJECT_ID/TASK_ID":

  • Extract the first numeric ID after "/task/" as projectId

  • Extract the second numeric ID as taskId

File Attachments:

  • To attach files, first upload them using the file upload API

  • Then provide the returned file IDs in the attachFileIds parameter

  • See: https://helpdesk.dooray.com/share/pages/9wWo-xwiR66BO5LGshgVTg/2939987647631384419

Content Format:

  • Use "text/x-markdown" for markdown formatting (recommended)

  • Use "text/html" for rich HTML content

  • Body format: {"mimeType": "text/x-markdown", "content": "..."}

Examples:

  • Simple comment: { "projectId": "123456", "taskId": "789012", "body": {"mimeType": "text/x-markdown", "content": "Progress update: Completed initial implementation"} }

  • With markdown: { "projectId": "123456", "taskId": "789012", "body": { "mimeType": "text/x-markdown", "content": "## Test Results\n\n- ✅ All unit tests passing\n- ✅ Integration tests passed\n- ⏳ Performance testing in progress" } }

  • With file attachments: { "projectId": "123456", "taskId": "789012", "body": {"mimeType": "text/x-markdown", "content": "See attached screenshots"}, "attachFileIds": ["file123", "file456"] }

Returns: Created comment with ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdYesProject ID where the task belongs
taskIdYesTask ID to add comment to
bodyYesComment content with format
attachFileIdsNoArray of file IDs to attach (optional). Files must be uploaded first using the file upload API.

Implementation Reference

  • The main handler function that executes the tool logic: calls the projects API to create a task comment, returns JSON result or formatted error response.
    export async function createTaskCommentHandler(args: CreateTaskCommentInput) {
      try {
        const result = await projectsApi.createTaskComment({
          projectId: args.projectId,
          taskId: args.taskId,
          body: args.body,
          attachFileIds: args.attachFileIds,
        });
    
        return {
          content: [
            {
              type: 'text',
              text: JSON.stringify(result, null, 2),
            },
          ],
        };
      } catch (error) {
        return {
          content: [
            {
              type: 'text',
              text: `Error: ${formatError(error)}`,
            },
          ],
          isError: true,
        };
      }
    }
  • Zod input schemas (bodySchema and createTaskCommentSchema) for validating tool parameters.
    const bodySchema = z.object({
      mimeType: z.enum(['text/x-markdown', 'text/html']),
      content: z.string(),
    });
    
    export const createTaskCommentSchema = z.object({
      projectId: z.string().describe('Project ID where the task belongs'),
      taskId: z.string().describe('Task ID to add comment to'),
      body: bodySchema.describe('Comment content'),
      attachFileIds: z.array(z.string()).optional().describe('Array of file IDs to attach (optional)'),
    });
    
    export type CreateTaskCommentInput = z.infer<typeof createTaskCommentSchema>;
  • src/index.ts:54-54 (registration)
    Registers the 'create-task-comment' tool by mapping its name to the handler and schema in the MCP server's toolRegistry.
    'create-task-comment': { handler: createTaskCommentHandler, schema: createTaskCommentSchema },
  • Supporting API function that makes the actual HTTP POST request to Dooray's endpoint for creating task comments (/projects/{projectId}/posts/{taskId}/logs).
    export async function createTaskComment(
      params: CreateTaskCommentParams
    ): Promise<CreateTaskCommentResponse> {
      const client = getClient();
    
      const requestBody: Record<string, unknown> = {
        body: {
          content: params.body.content,
          mimeType: params.body.mimeType,
        },
      };
    
      if (params.attachFileIds && params.attachFileIds.length > 0) {
        requestBody.attachFileIds = params.attachFileIds;
      }
    
      return client.post<CreateTaskCommentResponse>(
        `${PROJECTS_BASE}/projects/${params.projectId}/posts/${params.taskId}/logs`,
        requestBody
      );
    }
  • TypeScript interface definitions for CreateTaskCommentParams and CreateTaskCommentResponse used by the API layer.
    export interface CreateTaskCommentParams {
      projectId: string;
      taskId: string;
      body: {
        content: string;
        mimeType: 'text/x-markdown' | 'text/html';
      };
      attachFileIds?: string[];
    }
    
    export interface CreateTaskCommentResponse {
      id: string;
    }
Behavior4/5

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

With no annotations provided, the description carries full burden and delivers substantial behavioral context: it explains the separation from task body editing, provides URL pattern recognition guidance for extracting IDs, details file attachment workflow (upload first then attach), specifies content format options with recommendations, and mentions the return value ('Created comment with ID'). It doesn't cover error conditions or rate limits, but provides comprehensive operational guidance.

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?

Well-structured with clear sections (purpose, use cases, when to use, URL patterns, file attachments, content format, examples, return value). While comprehensive, some sections like the detailed examples could be slightly condensed. Every sentence serves a purpose, but the length approaches the upper bound of appropriate conciseness.

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?

For a creation tool with no annotations and no output schema, the description provides excellent context: clear purpose, usage guidelines, behavioral details, parameter guidance, and examples. The main gap is the lack of output schema documentation (only mentions 'Created comment with ID' without structure), but given the comprehensive input guidance and sibling tool context, this is largely mitigated.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains how to extract projectId and taskId from URLs, provides detailed file attachment workflow with external reference, gives content format recommendations (markdown preferred), and includes multiple concrete examples showing parameter usage in context. This compensates well for the schema-only documentation.

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 specific action ('creates a comment on a task') and resource ('Dooray task'), distinguishing it from sibling tools like 'update-task' (for modifying task description) and 'update-task-comment' (for editing existing comments). The Korean term '댓글' reinforces the purpose as adding discussion content separate from the main task body.

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?

Explicit 'When to Use' section provides clear alternatives: use this tool for adding comments versus 'update-task' for modifying task description or metadata. It also lists specific use cases (progress updates, responding to questions, logging information, attaching files) that help the agent understand appropriate contexts for invocation.

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/jhl8041/dooray-mcp'

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