Skip to main content
Glama
Dsazz

JIRA MCP Server

jira_delete_worklog

Remove a worklog entry from a JIRA issue to correct time tracking errors or delete incorrect entries.

Instructions

Delete a worklog entry from an issue

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issueKeyYes
worklogIdYes

Implementation Reference

  • DeleteWorklogHandler class: core implementation of the jira_delete_worklog tool handler, including validation, use case execution, and enhanced error handling.
    export class DeleteWorklogHandler extends BaseToolHandler<
      DeleteWorklogParams,
      string
    > {
      /**
       * Create a new DeleteWorklogHandler with use case and validator
       *
       * @param deleteWorklogUseCase - Use case for deleting worklog entries
       * @param worklogValidator - Validator for worklog parameters
       */
      constructor(
        private readonly deleteWorklogUseCase: DeleteWorklogUseCase,
        private readonly worklogValidator: WorklogValidator,
      ) {
        super("JIRA", "Delete Worklog");
      }
    
      /**
       * Execute the handler logic
       * Deletes a worklog entry and returns a success message
       *
       * @param params - Parameters for worklog deletion
       */
      protected async execute(params: DeleteWorklogParams): Promise<string> {
        try {
          // Step 1: Validate parameters
          const validatedParams =
            this.worklogValidator.validateDeleteWorklogParams(params);
          this.logger.info(
            `Deleting worklog ${validatedParams.worklogId} from issue: ${validatedParams.issueKey}`,
          );
    
          // Step 2: Delete worklog using use case
          const response = await this.deleteWorklogUseCase.execute({
            issueKey: validatedParams.issueKey,
            worklogId: validatedParams.worklogId,
          });
    
          // Step 3: Return success message
          return `✅ **Worklog Deleted Successfully**\n\n${response.message}`;
        } catch (error) {
          this.logger.error(`Failed to delete worklog: ${error}`);
          throw this.enhanceError(error, params);
        }
      }
    
      /**
       * Enhance error messages for better user guidance
       */
      private enhanceError(error: unknown, params?: DeleteWorklogParams): Error {
        const issueContext = params?.issueKey
          ? ` for issue ${params.issueKey}`
          : "";
        const worklogContext = params?.worklogId
          ? ` (worklog ${params.worklogId})`
          : "";
    
        if (error instanceof JiraNotFoundError) {
          return new Error(
            `❌ **Issue or Worklog Not Found**\n\nNo issue or worklog found${issueContext}${worklogContext}.\n\n**Solutions:**\n- Verify the issue key is correct\n- Verify the worklog ID exists\n- Check if you have permission to view the issue\n\n**Example:** \`jira_delete_worklog issueKey="PROJ-123" worklogId="12345"\``,
          );
        }
    
        if (error instanceof JiraPermissionError) {
          return new Error(
            `❌ **Permission Denied**\n\nYou don't have permission to delete 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- Ensure you can delete this specific worklog\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- Check the issue key is valid (format: PROJ-123)\n- Verify the worklog ID exists\n- Verify your JIRA connection\n\n**Example:** \`jira_delete_worklog issueKey="PROJ-123" worklogId="12345"\``,
          );
        }
    
        if (error instanceof Error) {
          return new Error(
            `❌ **Worklog Deletion Failed**\n\n${error.message}${issueContext}${worklogContext}\n\n**Solutions:**\n- Check your parameters are valid\n- Verify your JIRA connection\n- Verify the worklog ID exists\n\n**Example:** \`jira_delete_worklog issueKey="PROJ-123" worklogId="12345"\``,
          );
        }
    
        return new Error(
          `❌ **Unknown Error**\n\nAn unknown error occurred during worklog deletion${issueContext}${worklogContext}.\n\nPlease check your parameters and try again.`,
        );
      }
    }
  • Zod schema defining input parameters for jira_delete_worklog: issueKey and worklogId.
    export const deleteWorklogParamsSchema = z.object({
      issueKey: issueKeySchema,
      worklogId: z.string().min(1, "Worklog ID is required"),
    });
    
    /**
     * Type for delete worklog parameters
     */
    export type DeleteWorklogParams = z.infer<typeof deleteWorklogParamsSchema>;
  • ToolConfig object for jira_delete_worklog in worklog-tools.config.ts, defining name, description, params schema, and handler binding.
    {
      name: "jira_delete_worklog",
      description: "Delete a worklog entry from an issue",
      params: deleteWorklogParamsSchema.shape,
      handler: tools.jira_delete_worklog.handle.bind(tools.jira_delete_worklog),
    },
  • Creation of the jira_delete_worklog tool handler object in tool.factory.ts, wrapping DeleteWorklogHandler.handle.
    jira_delete_worklog: {
      handle: async (args: unknown) => deleteWorklogHandler.handle(args),
    },
  • Inclusion of jira_delete_worklog in worklogs tool group configuration for MCP server registration.
    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 full burden for behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this requires special permissions, if deletions are permanent/reversible, what happens to associated data, or any rate limits/constraints. For a destructive operation with zero annotation coverage, this represents a significant transparency gap.

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, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a simple operation and front-loads the essential information, making it easy for an agent 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 destructive mutation tool with no annotations, 2 required parameters (0% schema coverage), and no output schema, the description is inadequate. It should explain parameter meanings, permissions required, consequences of deletion, and what to expect upon success/failure. The current description leaves too many critical questions unanswered for safe and effective tool invocation.

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%, meaning neither parameter has documentation in the schema. The description provides no information about what 'issueKey' or 'worklogId' represent, their format requirements, or where to obtain these values. For a tool with 2 required parameters and no schema documentation, the description fails to compensate for this 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 ('Delete') and target resource ('a worklog entry from an issue'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'jira_update_worklog' or 'jira_get_worklogs', which would require more specific language about the destructive nature of this operation versus those alternatives.

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 like 'jira_update_worklog' for modifying worklogs or 'jira_get_worklogs' for viewing them. There's no mention of prerequisites, permissions required, or scenarios where deletion is appropriate versus modification, leaving the agent with insufficient context for proper tool selection.

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