Skip to main content
Glama

Search PingCode Work Items

pingcode_search_work_items

Search across defects and requirements in PingCode using keywords, status, priority, assignee, and time ranges. Supports advanced raw filters, returns deduplicated results with type counts.

Instructions

跨缺陷与需求统一搜索:支持关键字、状态/优先级/负责人(按名称)与更新时间范围;并支持 raw 过滤——项目/类型/父项/负责人/状态/优先级/标签/迭代/看板/入口/泳道/阶段/版本/创建人 ID 列表(≤20,与对应 name 合并去重)、participantId 单值、createdBetween/startBetween/endBetween 秒级时间戳、includeDeleted/includeArchived 布尔。返回按 id 去重的合并结果与各类型总数。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindsNo要搜索的工作项类型,默认同时搜索缺陷和需求。
tagIdsNo标签 ID 列表(raw),≤20。
typeIdsNo工作项类型 ID 列表(raw),与 kind 解析结果合并去重,≤20。
boardIdsNo看板 ID 列表(raw),≤20。
entryIdsNo入口 ID 列表(raw),≤20。
keywordsNo按编号或标题搜索。
pageSizeNo
phaseIdsNo阶段 ID 列表(raw),≤20。
stateIdsNo状态 ID 列表(raw),与 stateNames 解析结果合并去重,≤20。
pageIndexNo
parentIdsNo父工作项 ID 列表(raw),≤20。
projectIdNoPingCode 项目 ID,提供后跳过项目标识查询。
sprintIdsNo迭代 ID 列表(raw),≤20。
endBetweenNo结束时间范围,秒级时间戳 起,止,支持单边,如 1700000000, 或 ,1700000000。
projectIdsNo项目 ID 列表(raw),与项目标识解析结果合并去重,≤20。
stateNamesNo状态名称列表,按各类型分别解析。
versionIdsNo版本 ID 列表(raw),≤20。
assigneeIdsNo负责人 ID 列表(raw),与 assigneeNames 解析结果合并去重,≤20。
priorityIdsNo优先级 ID 列表(raw),与 priorityNames 解析结果合并去重,≤20。
swimlaneIdsNo泳道 ID 列表(raw),≤20。
createdByIdsNo创建人 ID 列表(raw),≤20。
startBetweenNo开始时间范围,秒级时间戳 起,止,支持单边,如 1700000000, 或 ,1700000000。
updatedAfterNo更新时间下界(ISO 或 yyyy-MM-dd),映射为服务端 updated_between 起点。
assigneeNamesNo负责人姓名列表。
participantIdNo参与人 ID(raw,单值)。
priorityNamesNo优先级名称列表。
updatedBeforeNo更新时间上界(ISO 或 yyyy-MM-dd),映射为服务端 updated_between 终点。
createdBetweenNo创建时间范围,秒级时间戳 起,止,支持单边,如 1700000000, 或 ,1700000000。
includeDeletedNo是否包含已删除工作项,默认 false。
includeArchivedNo是否包含已归档工作项,默认 false。
projectIdentifierNoPingCode 项目标识,默认读取 PINGCODE_PROJECT_IDENTIFIER。
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It explains that results are deduped by ID and include per-type counts. But it does not disclose pagination behavior, rate limits, or performance implications, nor does it mention that it is read-only (though it's a search). With zero annotation support, a score of 3 is appropriate.

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 a single dense Chinese sentence that front-loads the purpose. It covers many parameters concisely, though it could be broken into multiple sentences for readability. It is not verbose, but structure could be improved.

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 output schema, the description should explain return format more fully. It mentions 'merged results deduped by ID and totals per type' but lacks details like sorting, order, or field structure. For a search tool with 31 parameters, this is adequate but not complete.

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

Parameters4/5

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

Schema description coverage is 94% (high), so baseline is 3. The description adds value by explaining that raw filters accept lists up to 20, that some filters merge with name-based ones, and the timestamp format. It also clarifies defaults (e.g., kinds default). This exceeds the schema alone.

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 clearly states this tool performs a unified search across defects and requirements ('跨缺陷与需求统一搜索'). It lists supported filters and explains the merged result with dedup and per-type totals. This distinguishes it from sibling tools like pingcode_list_bugs and pingcode_list_requirements which are type-specific.

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?

The description implies usage when a cross-type search is needed ('跨缺陷与需求统一搜索') and when raw filters are required. However, it does not explicitly contrast with siblings or provide when-not-to-use scenarios.

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/frontendRicky/pingcode-mcp'

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