Skip to main content
Glama
Sign In
codearts-req

codearts-req

by anfang2077-glitch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

list_projects

Lists Huawei Cloud CodeArts requirement projects with optional search, filters, sorting, and pagination, so you can locate and select the project you need.

Instructions

查询华为云 CodeArts 需求项目列表（GET /v4/projects）。返回 projects 数组与 total。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_projects"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNo排序，格式为 字段:方向（如 name:asc），最多 4 组，逗号分隔
limitNo每页数量，选填，默认 10，1-1000
offsetNo偏移量，选填，默认 0，0-10000，且须为 limit 的整数倍
searchNo按项目名称或描述模糊搜索，选填
archiveNo是否归档，选填
query_typeNo查询类型，选填：domain_projects/absent
project_typeNo项目类型，选填：scrum/normal/xboard

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden. It does disclose useful behavior: the GET verb confirms a non-mutating read, and it states the return shape ('返回 projects 数组与 total'), which compensates for the absent output schema. However, it says nothing about authentication requirements, rate limits, or pagination semantics.

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?

Two short sentences with zero filler, front-loading the resource and endpoint before the return shape. Every clause earns its place and nothing is repeated from structured fields other than a compact summary of the response.

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?

For a list tool with 7 fully described optional parameters and no output schema, the definition is nearly sufficient: it identifies the source system, route, and return envelope. What remains missing is any note on pagination behavior or access prerequisites, which the schema does not fully cover (offset multiple-of-limit rule aside).

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?

All 7 parameters are fully documented in the schema at 100% coverage, so the baseline of 3 applies. The description adds no meaning beyond the schema, giving no hint about filters like search, archive, or the sort/paging interaction; it does not need to, but it offers no extra value here either.

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 names a specific verb and resource ('查询华为云 CodeArts 需求项目列表') and pins the exact API route (GET /v4/projects), so an agent knows this is a read/list operation. Its only sibling, create_project, is implicitly distinguished by the list-vs-create framing, though the description never names it explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: the GET endpoint signals a read-only listing, and no explicit when-to-use or when-not-to-use guidance is given. There is no mention of when to prefer this over the sibling create_project or any prerequisite context, leaving the agent to infer intent.

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

Deploy Server

Other Tools