Skip to main content
Glama
aliyun

AlibabaCloud DevOps MCP Server

Official
by aliyun

search_workitems

Find work items by filtering on type, status, assignee, creation/update dates, and more to retrieve matching tasks, requirements, or bugs.

Instructions

[Project Management] Search work items with various filter conditions. Paging is capped: page * perPage must not exceed 10000, otherwise the API returns 400 — narrow the filters to reach more results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoTag ID, multiple values separated by commas
pageNoPage number, starting from 1. Default is 1. Due to the search engine's deep-paging limit, page * perPage must not exceed 10000, otherwise the API returns 400; narrow the query with filters to reach more results
sortNoSort order, default is desc. Possible values: desc (descending), asc (ascending)desc
sprintNoSprint ID, multiple values separated by commas
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)
creatorNoCreator user ID, multiple values separated by commas. Special value 'self' can be used to represent the current user
orderByNoSort field, default is gmtCreate. Possible values: gmtCreate, subject, status, priority, assignedTogmtCreate
perPageNoNumber of items per page, range 0-200. Default is 20. page * perPage must not exceed 10000; use 200 to reduce the number of pages when iterating large result sets
spaceIdYesProject ID or Program ID. Use with spaceType to specify the space type
subjectNoText contained in the title
categoryYesSearch for work item types, such as Req (requirement), Task (task), Bug (defect), etc., multiple values separated by commas
priorityNoPriority ID, multiple values separated by commas
spaceTypeNoSpace type: Project (project) or Program (project set). Default is Project. Use 'Program' when spaceId refers to a program (project set) IDProject
assignedToNoAssignee user ID, multiple values separated by commas. Special value 'self' can be used to represent the current user
statusStageNoStatus stage ID, multiple values separated by commas
createdAfterNoCreated not earlier than, format: YYYY-MM-DD
updatedAfterNoUpdated not earlier than, format: YYYY-MM-DD
workitemTypeNoWork item type ID, multiple values separated by commas
createdBeforeNoCreated not later than, format: YYYY-MM-DD
updatedBeforeNoUpdated not later than, format: YYYY-MM-DD
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
organizationIdYesOrganization ID
finishTimeAfterNoFinish time not earlier than, format: YYYY-MM-DD
finishTimeBeforeNoFinish time not later than, format: YYYY-MM-DD
advancedConditionsNoAdvanced filter conditions, JSON format
subjectDescriptionNoText contained in title or description
updateStatusAtAfterNoStatus update time not earlier than, format: YYYY-MM-DD
updateStatusAtBeforeNoStatus update time not later than, format: YYYY-MM-DD
Install Server

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the transparency burden. It discloses a non-obvious behavioral constraint: page*perPage must not exceed 10000 or the API returns 400, along with the mitigation to narrow filters. This goes beyond the schema by emphasizing the cross-parameter error behavior, even though read-only semantics are only implied by the word 'search'.

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 exactly two sentences: the first states the tool's purpose, the second conveys the critical paging constraint and a corrective strategy. Every sentence earns its place, with no redundant or filler content.

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

Completeness4/5

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

Despite having 28 parameters and no output schema, the description is reasonably complete because it highlights the most important operational caveat (deep-paging limit) and the fully documented schema fills in the parameter details. It could mention the response shape or explicitly contrast with get_work_item, but those are secondary given the schema richness.

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 baseline is 3. The description adds no per-parameter meaning beyond the schema; its mention of 'various filter conditions' and the paging cap simply restate information already present in the page and perPage descriptions. It does not enrich parameter understanding.

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

Purpose5/5

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

The description states 'Search work items with various filter conditions' — a specific verb (search) and resource (work items), clearly distinguishing it from siblings like get_work_item, get_work_item_types, and create_work_item. The purpose is immediately understandable and unambiguous.

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 context that this is the tool for searching/filtering work items, and offers a practical hint to narrow filters when hitting the paging limit. It doesn't explicitly name alternatives like get_work_item or state when not to use this tool, but the use case is well defined and no misleading guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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