Skip to main content
Glama
Dsazz

JIRA MCP Server

jira_add_worklog

Log time spent on JIRA issues to track work progress and maintain accurate records for project management and billing.

Instructions

Add a worklog entry to track time spent on an issue

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issueKeyYes
timeSpentYes
commentNo
startedNo
visibilityNo

Implementation Reference

  • AddWorklogHandler class implementing the tool execution logic: validates input, calls use case to add worklog to JIRA issue, handles and enhances errors with user-friendly messages, formats response
    export class AddWorklogHandler extends BaseToolHandler<
      AddWorklogParams,
      string
    > {
      private formatter: WorklogEntryFormatter;
    
      /**
       * Create a new AddWorklogHandler with use case and validator
       *
       * @param addWorklogUseCase - Use case for adding worklog entries
       * @param worklogValidator - Validator for worklog parameters
       */
      constructor(
        private readonly addWorklogUseCase: AddWorklogUseCase,
        private readonly worklogValidator: WorklogValidator,
      ) {
        super("JIRA", "Add Worklog");
        this.formatter = new WorklogEntryFormatter();
      }
    
      /**
       * Execute the handler logic
       * Adds a worklog entry and formats the result
       *
       * @param params - Parameters for worklog addition
       */
      protected async execute(params: AddWorklogParams): Promise<string> {
        try {
          // Step 1: Validate parameters
          const validatedParams =
            this.worklogValidator.validateAddWorklogParams(params);
          this.logger.info(`Adding worklog to issue: ${validatedParams.issueKey}`, {
            timeSpent: validatedParams.timeSpent,
          });
    
          // Step 2: Add worklog using use case
          const response = await this.addWorklogUseCase.execute({
            issueKey: validatedParams.issueKey,
            timeSpent: validatedParams.timeSpent,
            comment: validatedParams.comment,
            started: validatedParams.started,
          });
    
          // Step 3: Format worklog using the formatter
          return this.formatter.format(response.worklog);
        } catch (error) {
          this.logger.error(`Failed to add worklog: ${error}`);
          throw this.enhanceError(error, params);
        }
      }
    
      /**
       * Enhance error messages for better user guidance
       */
      private enhanceError(error: unknown, params?: AddWorklogParams): Error {
        const issueContext = params?.issueKey
          ? ` for issue ${params.issueKey}`
          : "";
    
        if (error instanceof JiraNotFoundError) {
          return new Error(
            `❌ **Issue Not Found**\n\nNo issue found${issueContext}.\n\n**Solutions:**\n- Verify the issue key is correct\n- Check if the issue exists\n- Verify you have permission to view the issue\n\n**Example:** \`jira_add_worklog issueKey="PROJ-123" timeSpent="2h"\``,
          );
        }
    
        if (error instanceof JiraPermissionError) {
          return new Error(
            `❌ **Permission Denied**\n\nYou don't have permission to add worklog entries${issueContext}.\n\n**Solutions:**\n- Check your JIRA permissions\n- Contact your JIRA administrator\n- Verify you have work on issues permission\n\n**Required Permissions:** Work on Issues`,
          );
        }
    
        if (error instanceof JiraApiError) {
          return new Error(
            `❌ **JIRA API Error**\n\n${error.message}\n\n**Solutions:**\n- Verify the time format (e.g., "2h", "30m", "1d")\n- Check the issue key is valid (format: PROJ-123)\n- Verify the started date is in ISO format\n\n**Example:** \`jira_add_worklog issueKey="PROJ-123" timeSpent="2h" comment="Fixed bug"\``,
          );
        }
    
        if (error instanceof Error) {
          return new Error(
            `❌ **Worklog Addition Failed**\n\n${error.message}${issueContext}\n\n**Solutions:**\n- Check your parameters are valid\n- Verify your JIRA connection\n- Ensure time format is correct (e.g., "2h", "30m")\n\n**Example:** \`jira_add_worklog issueKey="PROJ-123" timeSpent="2h"\``,
          );
        }
    
        return new Error(
          `❌ **Unknown Error**\n\nAn unknown error occurred during worklog addition${issueContext}.\n\nPlease check your parameters and try again.`,
        );
      }
    }
  • Zod schema defining the input parameters for the jira_add_worklog tool including issueKey, timeSpent (required with format validation), optional comment, started datetime, and visibility
    export const addWorklogParamsSchema = z.object({
      issueKey: issueKeySchema,
    
      // Required fields
      timeSpent: z
        .string()
        .min(1, "Time spent is required")
        .regex(
          /^\d+[wdhm]$/,
          "Time spent must be in format like '2w', '3d', '4h', '30m'",
        ),
    
      // Optional fields
      comment: z
        .string()
        .max(32767, "Comment too long (max 32,767 characters)")
        .optional(),
    
      started: z
        .string()
        .datetime("Started time must be a valid ISO datetime")
        .optional(),
    
      // Visibility settings
      visibility: z
        .object({
          type: z.enum(["group", "role"]),
          value: z.string().min(1),
        })
        .optional(),
    });
  • Tool configuration object registering 'jira_add_worklog' with name, description, params schema, and bound handler function
    {
      name: "jira_add_worklog",
      description: "Add a worklog entry to track time spent on an issue",
      params: addWorklogParamsSchema.shape,
      handler: tools.jira_add_worklog.handle.bind(tools.jira_add_worklog),
    },
  • Factory creation of the jira_add_worklog ToolHandler object, wrapping the AddWorklogHandler.handle method
    jira_add_worklog: {
      handle: async (args: unknown) => addWorklogHandler.handle(args),
    },
  • Registration group configuration including jira_add_worklog tool handler passed to worklog tools config creator, which is then registered with MCP server
    groupName: "worklogs",
    configs: createWorklogToolsConfig({
      jira_add_worklog: tools.jira_add_worklog,
      jira_get_worklogs: tools.jira_get_worklogs,
      jira_update_worklog: tools.jira_update_worklog,
      jira_delete_worklog: tools.jira_delete_worklog,
    }),
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds a worklog but doesn't cover critical aspects like required permissions, whether it's a write operation (implied but not explicit), potential side effects (e.g., updating issue time estimates), error conditions, or response format. This leaves significant gaps for a mutation tool.

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 a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core function, making it easy to parse quickly.

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?

For a mutation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, parameters, usage context, and expected outcomes, leaving too many unknowns for effective tool invocation by an agent.

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?

Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no parameter semantics beyond implying 'issueKey' and 'timeSpent' are involved. It doesn't explain what 'timeSpent' format entails, the purpose of 'comment' or 'visibility', or how 'started' relates to the worklog, failing to compensate for the coverage gap.

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 description clearly states the action ('add a worklog entry') and resource ('to an issue'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'jira_update_worklog' or 'jira_delete_worklog', which would require mentioning creation vs. modification/deletion of worklogs.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing issue), compare to siblings like 'jira_update_worklog' for editing worklogs, or specify scenarios where adding a worklog is appropriate versus other time-tracking methods.

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/Dsazz/mcp-jira'

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