Skip to main content
Glama

ado_create_work_item

Create new work items in Azure DevOps by specifying title, type, description, area path, iteration path, and custom fields to track development tasks and issues.

Instructions

Crea un nuevo Work Item en Azure DevOps. Usa ado_get_work_item_type_fields para ver campos requeridos.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTítulo del Work Item
typeYesTipo de Work Item (User Story, Bug, Task, etc.)
descriptionNoDescripción del Work Item
areaPathNoRuta del área
iterationPathNoRuta del sprint/iteración
assignedToNoUsuario asignado
fieldsNoCampos adicionales como objeto {nombreCampo: valor}. Ej: {'Custom.OKR': 'valor'}

Implementation Reference

  • The handler implementation for the ado_create_work_item tool, which constructs a JSON patch document and calls the Azure DevOps createWorkItem API.
    async ({ title, type, description, areaPath, iterationPath, assignedTo, fields }) => {
      const api = await getWitApi();
    
      const patchDocument: VSSInterfaces.JsonPatchOperation[] = [
        {
          op: VSSInterfaces.Operation.Add,
          path: "/fields/System.Title",
          value: title,
        },
      ];
    
      if (description) {
        patchDocument.push({
          op: VSSInterfaces.Operation.Add,
          path: "/fields/System.Description",
          value: description,
        });
      }
    
      if (areaPath) {
        patchDocument.push({
          op: VSSInterfaces.Operation.Add,
          path: "/fields/System.AreaPath",
          value: areaPath,
        });
      }
    
      if (iterationPath) {
        patchDocument.push({
          op: VSSInterfaces.Operation.Add,
          path: "/fields/System.IterationPath",
          value: iterationPath,
        });
      }
    
      if (assignedTo) {
        patchDocument.push({
          op: VSSInterfaces.Operation.Add,
          path: "/fields/System.AssignedTo",
          value: assignedTo,
        });
      }
    
      // Agregar campos personalizados
      if (fields) {
        for (const [fieldName, value] of Object.entries(fields)) {
          patchDocument.push({
            op: VSSInterfaces.Operation.Add,
            path: `/fields/${fieldName}`,
            value: value,
          });
        }
      }
    
      const workItem = await api.createWorkItem(
        null,
        patchDocument,
        currentProject,
        type
      );
    
      return {
        content: [
          {
            type: "text",
            text: `Work Item creado exitosamente:\n${formatWorkItem(workItem)}`,
          },
        ],
      };
    }
  • src/index.ts:439-455 (registration)
    Tool registration for ado_create_work_item with input schema definition.
    server.tool(
      "ado_create_work_item",
      "Crea un nuevo Work Item en Azure DevOps. Usa ado_get_work_item_type_fields para ver campos requeridos.",
      {
        title: z.string().describe("Título del Work Item"),
        type: z
          .string()
          .describe("Tipo de Work Item (User Story, Bug, Task, etc.)"),
        description: z.string().optional().describe("Descripción del Work Item"),
        areaPath: z.string().optional().describe("Ruta del área"),
        iterationPath: z.string().optional().describe("Ruta del sprint/iteración"),
        assignedTo: z.string().optional().describe("Usuario asignado"),
        fields: z
          .record(z.string(), z.string())
          .optional()
          .describe("Campos adicionales como objeto {nombreCampo: valor}. Ej: {'Custom.OKR': 'valor'}"),
      },
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions creating a new item but lacks details on permissions needed, whether it's idempotent, error handling, or response format. The description adds minimal behavioral context beyond the basic action.

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 two concise sentences in Spanish, front-loaded with the main action and followed by a practical usage tip. Every sentence adds value without redundancy, making it efficient and well-structured.

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

Completeness3/5

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

Given no annotations and no output schema, the description is minimal but covers the essential action and a key prerequisite. It lacks details on behavioral traits, error cases, or return values, leaving gaps for a mutation tool with 7 parameters. It's adequate but incomplete.

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. The description adds no additional parameter semantics beyond referencing another tool for field requirements, which is useful but doesn't enhance individual parameter understanding. Baseline 3 is appropriate.

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 ('Crea un nuevo Work Item') and resource ('en Azure DevOps'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'ado_update_work_item' beyond the creation focus, which is implied but not stated.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear guidance on when to use this tool by referencing 'ado_get_work_item_type_fields' to check required fields, which helps in preparation. However, it doesn't specify when NOT to use it or alternatives like 'ado_update_work_item' for modifications.

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/soulberto/mcp-azure'

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