Filter enterprise training tasks by status, time window, or base model to review history and manage multiple workloads. Returns only tasks within your isolated enterprise partition.
训练任务列表——按时间/状态/模型过滤（历史复盘与多任务管理；只列本企业分区任务）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回上限（可选——缺省 50） | |
| status | No | 状态过滤（可选） | |
| last_days | No | 时间过滤（可选——最近 N 天） | |
| base_model | No | 基座模型过滤（可选——子串匹配，如 Qwen3） | |
| enterprise_id | Yes | 🔴 企业标识（隔离分区——只列本企业任务） |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses the partition scope ('只列本企业分区任务') and the filtering capabilities, but does not mention pagination, sorting, or return format. As a read-only list tool, the lack of side-effect disclosure is acceptable, but more detail on behavior (e.g., whether it returns all tasks or paged) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose ('训练任务列表') and then adds filters and scope. There is no redundancy or filler. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters and no output schema, the description covers the essential aspects: what it lists, the filters, and the enterprise partition. It does not explain pagination (limit) or return shape, but these are less critical for a read-only list operation. Given the schema fully documents parameters, the description is reasonably complete, though it could mention the response type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 summarizes the filter parameters (time/status/model) but does not add syntax or details beyond what the schema already provides. It adds a high-level grouping but no additional meaning for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists training tasks ('训练任务列表') and specifies filtering by time, status, and model. It also scopes to the enterprise partition ('只列本企业分区任务'), distinguishing it from other train_* tools like train_submit or train_status. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: '历史复盘与多任务管理' (historical review and multi-task management), which tells when to use it. However, it does not explicitly name alternatives or state when not to use it, though the context implies it is for listing rather than submitting or inspecting single tasks. This is clear enough but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.