Skip to main content
Glama
aliyun

AlibabaCloud DevOps MCP Server

Official
by aliyun

search_workitems

Search for work items in Alibaba Cloud DevOps projects using filters like status, type, creator, date ranges, and tags to find specific requirements, tasks, or bugs.

Instructions

[Project Management] Search work items with various filter conditions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationIdYesOrganization ID
categoryYesSearch for work item types, such as Req (requirement), Task (task), Bug (defect), etc., multiple values separated by commas
spaceIdYesProject ID, project unique identifier
subjectNoText contained in the title
statusNoStatus ID, multiple separated by commas. Status names and their IDs: Pending Confirmation (28), Pending Processing (100005), Reopened (30), Deferred Fix (34), Confirmed (32), Selected (625489), In Analysis (154395), Analysis Complete (165115), In Progress (100010), In Design (156603), Design Complete (307012), In Development (142838), Development Complete (100011), In Testing (100012)
createdAfterNoCreated not earlier than, format: YYYY-MM-DD
createdBeforeNoCreated not later than, format: YYYY-MM-DD
updatedAfterNoUpdated not earlier than, format: YYYY-MM-DD
updatedBeforeNoUpdated not later than, format: YYYY-MM-DD
creatorNoCreator user ID, multiple values separated by commas. Special value 'self' can be used to represent the current user
assignedToNoAssignee user ID, multiple values separated by commas. Special value 'self' can be used to represent the current user
sprintNoSprint ID, multiple values separated by commas
workitemTypeNoWork item type ID, multiple values separated by commas
statusStageNoStatus stage ID, multiple values separated by commas
tagNoTag ID, multiple values separated by commas
priorityNoPriority ID, multiple values separated by commas
subjectDescriptionNoText contained in title or description
finishTimeAfterNoFinish time not earlier than, format: YYYY-MM-DD
finishTimeBeforeNoFinish time not later than, format: YYYY-MM-DD
updateStatusAtAfterNoStatus update time not earlier than, format: YYYY-MM-DD
updateStatusAtBeforeNoStatus update time not later than, format: YYYY-MM-DD
advancedConditionsNoAdvanced filter conditions, JSON format
orderByNoSort field, default is gmtCreate. Possible values: gmtCreate, subject, status, priority, assignedTogmtCreate
includeDetailsNoSet to true when you need work item descriptions/detailed content. This automatically fetches missing descriptions instead of requiring separate get_work_item calls. RECOMMENDED: Use includeDetails=true when user asks for 'detailed content', 'descriptions', or 'full information' of work items. This is more efficient than calling get_work_item multiple times. Default is false

Implementation Reference

  • Tool handler case for 'search_workitems' that parses arguments, calls searchWorkitemsFunc, and returns JSON stringified results.
    case "search_workitems": {
      const args = types.SearchWorkitemsSchema.parse(request.params.arguments);
      const workItems = await workitem.searchWorkitemsFunc(
        args.organizationId,
        args.category,
        args.spaceId,
        args.subject ?? undefined,
        args.status ?? undefined,
        args.createdAfter ?? undefined,
        args.createdBefore ?? undefined,
        args.updatedAfter ?? undefined,
        args.updatedBefore ?? undefined,
        args.creator ?? undefined,
        args.assignedTo ?? undefined,
        args.sprint ?? undefined,
        args.workitemType ?? undefined,
        args.statusStage ?? undefined,
        args.tag ?? undefined,
        args.priority ?? undefined,
        args.subjectDescription ?? undefined,
        args.finishTimeAfter ?? undefined,
        args.finishTimeBefore ?? undefined,
        args.updateStatusAtAfter ?? undefined,
        args.updateStatusAtBefore ?? undefined,
        args.advancedConditions ?? undefined,
        args.orderBy ?? "gmtCreate",
        args.includeDetails ?? false
      );
      return {
        content: [{ type: "text", text: JSON.stringify(workItems, null, 2) }],
      };
    }
  • Zod schema definition for SearchWorkitems input parameters, including all filters and options.
    export const SearchWorkitemsSchema = z.object({
      organizationId: z.string().describe("Organization ID"),
      category: z.string().describe("Search for work item types, such as Req (requirement), Task (task), Bug (defect), etc., multiple values separated by commas"),
      spaceId: z.string().describe("Project ID, project unique identifier"),
    
      // Simplified search parameters
      subject: z.string().nullable().optional().describe("Text contained in the title"),
      status: z.string().nullable().optional().describe("Status ID, multiple separated by commas. Status names and their IDs: Pending Confirmation (28), Pending Processing (100005), Reopened (30), Deferred Fix (34), Confirmed (32), Selected (625489), In Analysis (154395), Analysis Complete (165115), In Progress (100010), In Design (156603), Design Complete (307012), In Development (142838), Development Complete (100011), In Testing (100012)"),
      createdAfter: z.string().nullable().optional().describe("Created not earlier than, format: YYYY-MM-DD"),
      createdBefore: z.string().nullable().optional().describe("Created not later than, format: YYYY-MM-DD"),
      updatedAfter: z.string().nullable().optional().describe("Updated not earlier than, format: YYYY-MM-DD"),
      updatedBefore: z.string().nullable().optional().describe("Updated not later than, format: YYYY-MM-DD"),
      creator: z.string().nullable().optional().describe("Creator user ID, multiple values separated by commas. Special value 'self' can be used to represent the current user"),
      assignedTo: z.string().nullable().optional().describe("Assignee user ID, multiple values separated by commas. Special value 'self' can be used to represent the current user"),
      sprint: z.string().nullable().optional().describe("Sprint ID, multiple values separated by commas"),
      workitemType: z.string().nullable().optional().describe("Work item type ID, multiple values separated by commas"),
      statusStage: z.string().nullable().optional().describe("Status stage ID, multiple values separated by commas"),
      tag: z.string().nullable().optional().describe("Tag ID, multiple values separated by commas"),
      priority: z.string().nullable().optional().describe("Priority ID, multiple values separated by commas"),
      subjectDescription: z.string().nullable().optional().describe("Text contained in title or description"),
      finishTimeAfter: z.string().nullable().optional().describe("Finish time not earlier than, format: YYYY-MM-DD"),
      finishTimeBefore: z.string().nullable().optional().describe("Finish time not later than, format: YYYY-MM-DD"),
      updateStatusAtAfter: z.string().nullable().optional().describe("Status update time not earlier than, format: YYYY-MM-DD"),
      updateStatusAtBefore: z.string().nullable().optional().describe("Status update time not later than, format: YYYY-MM-DD"),
    
      // Advanced parameters
      advancedConditions: z.string().nullable().optional().describe("Advanced filter conditions, JSON format"),
      orderBy: z.string().optional().default("gmtCreate").describe("Sort field, default is gmtCreate. Possible values: gmtCreate, subject, status, priority, assignedTo"),
      includeDetails: z.boolean().optional().describe("Set to true when you need work item descriptions/detailed content. This automatically fetches missing descriptions instead of requiring separate get_work_item calls. RECOMMENDED: Use includeDetails=true when user asks for 'detailed content', 'descriptions', or 'full information' of work items. This is more efficient than calling get_work_item multiple times. Default is false")
    });
  • Tool registration entry defining name, description, and input schema for 'search_workitems'.
    {
      name: "search_workitems",
      description: "[Project Management] Search work items with various filter conditions",
      inputSchema: zodToJsonSchema(types.SearchWorkitemsSchema),
    },
  • Core helper function implementing the search logic: handles 'self', builds conditions, calls API, parses response, optionally fetches details.
    export async function searchWorkitemsFunc(
      organizationId: string,
      category: string,
      spaceId: string,
      subject?: string,
      status?: string,
      createdAfter?: string,
      createdBefore?: string,
      updatedAfter?: string,
      updatedBefore?: string,
      creator?: string,
      assignedTo?: string,
      sprint?: string,
      workitemType?: string,
      statusStage?: string,
      tag?: string,
      priority?: string,
      subjectDescription?: string,
      finishTimeAfter?: string,
      finishTimeBefore?: string,
      updateStatusAtAfter?: string,
      updateStatusAtBefore?: string,
      advancedConditions?: string,
      orderBy: string = "gmtCreate",
      includeDetails: boolean = false // 新增参数:是否自动补充缺失的description等详细信息
    ): Promise<z.infer<typeof WorkItemSchema>[]> {
      // 处理assignedTo为"self"的情况,自动获取当前用户ID
      let finalAssignedTo = assignedTo;
      let finalCreator = creator;
      
      if (assignedTo === "self" || creator === "self") {
        try {
          const currentUser = await getCurrentUserFunc();
          if (currentUser.id) {
            if (assignedTo === "self") {
              finalAssignedTo = currentUser.id;
            }
            if (creator === "self") {
              finalCreator = currentUser.id;
            }
          } else {
            finalAssignedTo = assignedTo;
            finalCreator = creator;
          }
        } catch (error) {
          finalAssignedTo = assignedTo;
          finalCreator = creator;
        }
      }
    
      const url = `/oapi/v1/projex/organizations/${organizationId}/workitems:search`;
    
      const payload: Record<string, any> = {
        category: category,
        spaceId: spaceId,
      };
    
      const conditions = buildWorkitemConditions({
        subject,
        status,
        createdAfter,
        createdBefore,
        updatedAfter,
        updatedBefore,
        creator: finalCreator,
        assignedTo: finalAssignedTo,
        sprint,
        workitemType,
        statusStage,
        tag,
        priority,
        subjectDescription,
        finishTimeAfter,
        finishTimeBefore,
        updateStatusAtAfter,
        updateStatusAtBefore,
        advancedConditions
      });
      
      if (conditions) {
        payload.conditions = conditions;
      }
    
      payload.orderBy = orderBy;
    
      const response = await yunxiaoRequest(url, {
        method: "POST",
        body: payload,
      });
    
      if (!Array.isArray(response)) {
        return [];
      }
    
      const workItems = response.map(workitem => WorkItemSchema.parse(workitem));
    
      // 如果需要补充详细信息,使用分批并发方式获取
      if (includeDetails) {
        const itemsNeedingDetails = workItems.filter(item => 
          item.id.length > 0 &&
          (item.description === null || item.description === undefined || item.description === "")
        );
    
        if (itemsNeedingDetails.length > 0) {
          // 分批并发获取详情
          const descriptionMap = await batchGetWorkItemDetails(organizationId, itemsNeedingDetails);
    
          // 更新workItems中的description
          return workItems.map(item => {
            if (descriptionMap.has(item.id)) {
              return {
                ...item,
                description: descriptionMap.get(item.id) || item.description
              };
            }
            return item;
          });
        }
      }
    
      return workItems;
    }
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 'search' but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what happens with no results. The 'includeDetails' parameter description hints at efficiency (avoiding multiple calls), but the main description lacks context on performance, data scope, or error handling for a complex 24-parameter 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?

Extremely concise and front-loaded: a single sentence that directly states the tool's purpose. No wasted words or redundant information. The bracketed '[Project Management]' adds context efficiently. Every part of the description earns its place.

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?

Incomplete for a complex search tool with 24 parameters and no annotations or output schema. The description lacks crucial context: it doesn't explain the return format (e.g., list of work items with fields), pagination, error cases, or how filters combine. Without annotations, it fails to address behavioral aspects like read-only nature or performance implications, leaving significant gaps for agent 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?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds minimal value beyond the schema—it implies filtering capabilities but doesn't explain parameter interactions, default behaviors, or provide examples. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with additional insights.

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 verb ('Search') and resource ('work items'), and specifies the scope ('with various filter conditions'). It distinguishes from siblings like 'get_work_item' (singular fetch) and 'list_work_item_types' (metadata listing), but doesn't explicitly differentiate from other search tools like 'search_projects' or 'search_organization_members'.

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 explicit guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., required parameters), compare to 'list_work_item_comments' or 'get_work_item', or specify scenarios where this search is preferred over simpler listing tools. The only implied usage is for filtered searches, but no exclusions or alternatives are stated.

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/aliyun/alibabacloud-devops-mcp-server'

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