Skip to main content
Glama

create_issue

Create Jira issues by providing user email, project key, summary, and detailed description to track tasks, bugs, epics, or stories in Jira projects.

Instructions

Creates an issue to the users

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userEmailYesThe email of the user creating the issue.
resourceIdYesThe ID of the resource being used to call to create the issue.
summaryYesThe title of the issue to be created.
descriptionYesThe description of the issue to be created, formatted as an Atlassian Document Format (ADF).
projectKeyYesThe ID or key of the project where the issue will be created.
typeNoThe type of the issue to be created. If not provided, it will default to 'Task'.
priorityNoThe priority of the issue to be created. If not provided, it will default to 'Medium'.

Implementation Reference

  • The main handler function that executes the create_issue tool logic. It validates user authentication via cache, creates a Jira API instance, posts the issue data to Jira's REST API, and returns success/error responses.
    async function handleCreateIssueTool({userEmail, resourceId, summary, description, projectKey, type, priority} : {
        userEmail: string,
        resourceId: string,
        summary: string,
        description: {
            type: "doc"
            version: 1
            content?: any[] | undefined
        },
        projectKey: string,
        type?: 'Task' | 'Bug' | 'Epic' | 'Story',
        priority?: 'Low' | 'Medium' | 'High'}) : Promise<any> {
    
        const cacheData = await getUpdatedCachedData(userEmail);
    
        if(!cacheData) {
            return {
                isError: true,
                content: [
                    {
                        type: "text",
                        text: `Please try again after user confirmed that he authorized the app to access the Jira data.`,
                    },
                ],
            };
        }
    
        const api = getApiInstance(`https://api.atlassian.com/ex/jira/${resourceId}`, cacheData.accessToken);
    
        const response = await api.post(`rest/api/3/issue`, {
            fields: {
                project: {
                    key: projectKey,
                },
                summary,
                description,
                issuetype: {
                    name: type || 'Task'
                },
                priority: {
                    name: priority || 'Medium'
                },
            }
        });
    
        if (response.status !== Constants.CREATED) {
            logger.error('Creating issue failed:', {userEmail, status: response.statusText, data: response.data});
            return {
                isError: true,
                content: [
                    {
                        type: "text",
                        text: `Error creating issue: ${response.statusText}`,
                    },
                ],
            };
        }
    
        logger.info('Issue created successfully:', {summary, description, projectKey, type, priority});
        return {
            content: [
                {
                    type: "text",
                    text: "Issue added successfully!",
                },
            ],
        };
    }
  • Registration function that defines the 'create_issue' tool with the MCP server. Includes the tool name, description, Zod schema for input validation (userEmail, resourceId, summary, description, projectKey, type, priority), and the async handler wrapper with error handling.
    export function createIssueTool(server: McpServer) {
        server.tool(
            'create_issue',
            'Creates an issue to the users',
            {
                userEmail: z.string().email().describe("The email of the user creating the issue."),
                resourceId: z.string().describe("The ID of the resource being used to call to create the issue."),
                summary: z.string().describe("The title of the issue to be created."),
                description: ADFDocumentSchema.describe("The description of the issue to be created, formatted as an Atlassian Document Format (ADF)."),
                projectKey: z.string().describe("The ID or key of the project where the issue will be created."),
                type: z.enum(['Task', 'Bug', 'Epic', 'Story']).optional().describe("The type of the issue to be created. If not provided, it will default to 'Task'."),
                priority: z.enum(['Low', 'Medium', 'High']).optional().describe("The priority of the issue to be created. If not provided, it will default to 'Medium'."),
            },
            async ({userEmail, resourceId, summary, description, projectKey, type, priority}) => {
                try {
                    return await handleCreateIssueTool({userEmail, resourceId, summary, description, projectKey, type, priority});
                }
                catch(err) {
                    logger.error('Error creating issue:', err);
                    return {
                        isError: true,
                        content: [
                            {
                                type: "text",
                                text: `Error creating issue: ${err instanceof Error ? err.message : 'Unknown error'}`,
                            },
                        ],
                    };
                }
            }
        );
    }
  • Input schema definition using Zod for the create_issue tool parameters. Validates userEmail (email format), resourceId, summary, description (ADFDocumentSchema), projectKey, and optional type/priority enums.
    {
        userEmail: z.string().email().describe("The email of the user creating the issue."),
        resourceId: z.string().describe("The ID of the resource being used to call to create the issue."),
        summary: z.string().describe("The title of the issue to be created."),
        description: ADFDocumentSchema.describe("The description of the issue to be created, formatted as an Atlassian Document Format (ADF)."),
        projectKey: z.string().describe("The ID or key of the project where the issue will be created."),
        type: z.enum(['Task', 'Bug', 'Epic', 'Story']).optional().describe("The type of the issue to be created. If not provided, it will default to 'Task'."),
        priority: z.enum(['Low', 'Medium', 'High']).optional().describe("The priority of the issue to be created. If not provided, it will default to 'Medium'."),
    },
  • ADFDocumentSchema definition used for validating the description parameter. Defines the Atlassian Document Format structure with version, type, and content array of block nodes.
    export const ADFDocumentSchema = z.object({
        version: z.literal(1),
        type: z.literal('doc'),
        content: z.array(BlockNodeSchema).optional()
    });
  • Central registration point where all tools are registered with the MCP server. The createIssueTool is imported and called here as part of the registerTools function.
    export function registerTools(server: McpServer) {
        createIssueTool(server);
        getProjectsTool(server);
        getAccessibleResourcesTool(server);
    }
Behavior1/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states 'Creates an issue' without explaining what happens after creation (e.g., issue ID returned, notifications sent), whether this requires specific permissions, rate limits, or error conditions. For a mutation tool with complex parameters, this is completely inadequate.

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

Conciseness2/5

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

While technically concise (three words), this is under-specification rather than effective conciseness. The description fails to convey essential information about the tool's purpose and context. Every word should earn its place, but here the words provide almost no value beyond the tool name.

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

Completeness1/5

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

Given the complexity (7 parameters including nested ADF objects, no annotations, no output schema), the description is completely inadequate. It doesn't explain what an 'issue' is in this context, what system creates it, what the expected outcome is, or how it relates to sibling tools. For a creation tool with rich input schema but no output schema, the description should provide crucial context that's missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly with descriptions, formats, enums, and constraints. The description adds zero parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.

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

Purpose2/5

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

The description 'Creates an issue to the users' is vague and poorly worded. It restates the tool name ('create_issue') without specifying what kind of issue system this is (e.g., Jira, bug tracking), what 'to the users' means, or what resource is being created. It doesn't distinguish this from potential sibling tools beyond the obvious creation vs. retrieval distinction.

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

Usage Guidelines1/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. There are sibling tools (get_accessible_resources, get_projects) that might be prerequisites or related operations, but the description doesn't mention them or explain the workflow. No context about prerequisites, dependencies, or appropriate scenarios is given.

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/razvancanuci/jira-issue-mcp-server'

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