Retrieve your own field work orders for the current project using the API key; returns assigned items sorted by start and creation time, or empty if none.
查看本人任务单。本人的现场任务单（项目成员）。items 按 startAt、createdAt 升序；无分配时为空数组。 GET /api/projects/{id}/work-sheet 项目由当前 API 密钥自动确定，无需传 projectId。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds real behavioral detail beyond them: items are ordered ascending by startAt then createdAt, and an empty array is returned when there are no assignments. It also disambiguates the endpoint path and states the project is resolved from the API key rather than a parameter.
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?
Front-loaded with the purpose, then ordering/empty-array semantics, then the endpoint and auth note. Information-dense and short, with only mild overlap between the first two sentences ('view own work sheet' repeated as 'own onsite work sheet').
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?
There is no output schema, so the description compensates by describing the returned items (sort order, empty-array case), and it clarifies the auth model. For a zero-parameter read tool this is nearly complete; it could still name the user_id sibling to fully close the selection gap.
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?
The tool takes zero parameters, so parameter semantics carry no burden and the baseline is 4. The description usefully reinforces this by explaining that projectId must not be passed because the project is derived from the current API key.
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?
States a specific verb and resource ('查看本人任务单' / view one's own work sheet) and scopes it to the '本人' (self) case, which implicitly separates it from the sibling anon_get_work_sheet_user_id. It never explicitly names that sibling, so the differentiation is inferable rather than stated.
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 establishes context (viewing one's own onsite work sheet as a project member, project inferred from the API key) but gives no explicit when-to-use rule or contrast with the user_id variant that appears in the sibling list. The agent must infer which of the two work-sheet tools to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.