Skip to main content
Glama
Tiberriver256

Azure DevOps MCP Server

create_work_item

Create new work items like tasks, bugs, or user stories in Azure DevOps projects by specifying type, title, and optional details such as description, assignee, and priority.

Instructions

Create a new work item

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdNoThe ID or name of the project (Default: MyProject)
organizationIdNoThe ID or name of the organization (Default: mycompany)
workItemTypeYesThe type of work item to create (e.g., "Task", "Bug", "User Story")
titleYesThe title of the work item
descriptionNoWork item description in HTML format. Multi-line text fields (i.e., System.History, AcceptanceCriteria, etc.) must use HTML format. Do not use CDATA tags.
assignedToNoThe email or name of the user to assign the work item to
areaPathNoThe area path for the work item
iterationPathNoThe iteration path for the work item
priorityNoThe priority of the work item
parentIdNoThe ID of the parent work item to create a relationship with
additionalFieldsNoAdditional fields to set on the work item. Multi-line text fields (i.e., System.History, AcceptanceCriteria, etc.) must use HTML format. Do not use CDATA tags.

Implementation Reference

  • Core handler function that implements the logic to create a work item in Azure DevOps using the WorkItemTrackingApi.
    export async function createWorkItem(
      connection: WebApi,
      projectId: string,
      workItemType: string,
      options: CreateWorkItemOptions,
    ): Promise<WorkItem> {
      try {
        if (!options.title) {
          throw new Error('Title is required');
        }
    
        const witApi = await connection.getWorkItemTrackingApi();
    
        // Create the JSON patch document
        const document = [];
    
        // Add required fields
        document.push({
          op: 'add',
          path: '/fields/System.Title',
          value: options.title,
        });
    
        // Add optional fields if provided
        if (options.description) {
          document.push({
            op: 'add',
            path: '/fields/System.Description',
            value: options.description,
          });
        }
    
        if (options.assignedTo) {
          document.push({
            op: 'add',
            path: '/fields/System.AssignedTo',
            value: options.assignedTo,
          });
        }
    
        if (options.areaPath) {
          document.push({
            op: 'add',
            path: '/fields/System.AreaPath',
            value: options.areaPath,
          });
        }
    
        if (options.iterationPath) {
          document.push({
            op: 'add',
            path: '/fields/System.IterationPath',
            value: options.iterationPath,
          });
        }
    
        if (options.priority !== undefined) {
          document.push({
            op: 'add',
            path: '/fields/Microsoft.VSTS.Common.Priority',
            value: options.priority,
          });
        }
    
        // Add parent relationship if parentId is provided
        if (options.parentId) {
          document.push({
            op: 'add',
            path: '/relations/-',
            value: {
              rel: 'System.LinkTypes.Hierarchy-Reverse',
              url: `${connection.serverUrl}/_apis/wit/workItems/${options.parentId}`,
            },
          });
        }
    
        // Add any additional fields
        if (options.additionalFields) {
          for (const [key, value] of Object.entries(options.additionalFields)) {
            document.push({
              op: 'add',
              path: `/fields/${key}`,
              value: value,
            });
          }
        }
    
        // Create the work item
        const workItem = await witApi.createWorkItem(
          null,
          document,
          projectId,
          workItemType,
        );
    
        if (!workItem) {
          throw new Error('Failed to create work item');
        }
    
        return workItem;
      } catch (error) {
        if (error instanceof AzureDevOpsError) {
          throw error;
        }
        throw new Error(
          `Failed to create work item: ${error instanceof Error ? error.message : String(error)}`,
        );
      }
    }
  • MCP tool request handler that validates input with schema, maps arguments, calls the core createWorkItem function, and formats the response.
    case 'create_work_item': {
      const args = CreateWorkItemSchema.parse(request.params.arguments);
      const result = await createWorkItem(
        connection,
        args.projectId ?? defaultProject,
        args.workItemType,
        {
          title: args.title,
          description: args.description,
          assignedTo: args.assignedTo,
          areaPath: args.areaPath,
          iterationPath: args.iterationPath,
          priority: args.priority,
          parentId: args.parentId,
          additionalFields: args.additionalFields,
        },
      );
      return {
        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
      };
  • Zod schema defining the input parameters and validation for the create_work_item tool.
    export const CreateWorkItemSchema = z.object({
      projectId: z
        .string()
        .optional()
        .describe(`The ID or name of the project (Default: ${defaultProject})`),
      organizationId: z
        .string()
        .optional()
        .describe(`The ID or name of the organization (Default: ${defaultOrg})`),
      workItemType: z
        .string()
        .describe(
          'The type of work item to create (e.g., "Task", "Bug", "User Story")',
        ),
      title: z.string().describe('The title of the work item'),
      description: z
        .string()
        .optional()
        .describe(
          'Work item description in HTML format. Multi-line text fields (i.e., System.History, AcceptanceCriteria, etc.) must use HTML format. Do not use CDATA tags.',
        ),
      assignedTo: z
        .string()
        .optional()
        .describe('The email or name of the user to assign the work item to'),
      areaPath: z.string().optional().describe('The area path for the work item'),
      iterationPath: z
        .string()
        .optional()
        .describe('The iteration path for the work item'),
      priority: z.number().optional().describe('The priority of the work item'),
      parentId: z
        .number()
        .optional()
        .describe('The ID of the parent work item to create a relationship with'),
      additionalFields: z
        .record(z.string(), z.any())
        .optional()
        .describe(
          'Additional fields to set on the work item. Multi-line text fields (i.e., System.History, AcceptanceCriteria, etc.) must use HTML format. Do not use CDATA tags.',
        ),
    });
  • Registration of the create_work_item tool in the workItemsTools array, including name, description, and input schema.
    {
      name: 'create_work_item',
      description: 'Create a new work item',
      inputSchema: zodToJsonSchema(CreateWorkItemSchema),
    },
  • TypeScript interface matching the options used by the createWorkItem handler function.
    export interface CreateWorkItemOptions {
      title: string;
      description?: string;
      assignedTo?: string;
      areaPath?: string;
      iterationPath?: string;
      priority?: number;
      parentId?: number;
      additionalFields?: Record<string, string | number | boolean | null>;
    }
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. 'Create a new work item' implies a write/mutation operation, but it doesn't disclose any behavioral traits like required permissions, whether the operation is idempotent, what happens on conflicts, rate limits, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.

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?

The description is extremely concise at just 4 words, which is efficient and front-loaded. However, it's arguably too brief for a complex mutation tool with 11 parameters, bordering on under-specification rather than optimal conciseness.

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 complex mutation tool with 11 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a work item is in this system, what happens after creation, or provide any context about the operation's behavior. The agent would need to rely entirely on the input schema for understanding.

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?

The description provides no parameter information, but schema description coverage is 100% with comprehensive parameter documentation in the input schema. The baseline score of 3 is appropriate since the schema does the heavy lifting, though the description adds no value beyond what's already in the structured data.

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

Purpose3/5

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

The description 'Create a new work item' clearly states the action (create) and resource (work item), but it's quite basic and doesn't differentiate from sibling tools like 'create_branch', 'create_commit', or 'create_pull_request' beyond the resource name. It lacks specificity about what constitutes a work item in this context.

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?

No guidance is provided on when to use this tool versus alternatives like 'update_work_item', 'get_work_item', or 'list_work_items'. The description doesn't mention prerequisites, dependencies, or contextual factors that would help an agent decide when this tool is appropriate.

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/Tiberriver256/mcp-server-azure-devops'

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