Review the shared collaboration board to see participant statuses, file claims, and unread messages before starting work, helping prevent conflicts.
查看公告板全貌：各方状态、文件认领情况、给你的未读消息。开始任务前先调用这个。
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | 当前项目根目录的绝对路径，例如 D:/code/ender-eda | |
| mark_read | No | 是否把显示的未读消息标为已读，默认 true |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It presents itself as a passive "查看" (view) operation, yet the schema's mark_read flag defaults to true, meaning a plain call mutates read state; that side effect is never disclosed in the description. It also says nothing about permissions, result shape, or how stale the aggregated statuses may be.
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?
Two short sentences with the content of the overview front-loaded and the call-to-action last. Nothing is wasted or repeated from the schema.
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 2-parameter, no-output-schema read tool this is nearly sufficient: it tells the agent what data comes back and when to invoke it. The remaining gap is the undisclosed mark_read side effect, which matters for an agent that may call this repeatedly.
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 both project and mark_read are already documented with examples and defaults, establishing the baseline of 3. The description adds no parameter-level detail beyond noting that unread messages are part of the payload.
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?
Names a specific verb (查看/overview) and enumerates exactly what the overview contains: party statuses, file-claim state, and the caller's unread messages. This aggregation of multiple sibling concerns (read_messages, claim_files, update_status) makes it distinguishable, though it never names a sibling explicitly.
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?
"开始任务前先调用这个" gives an explicit trigger condition for using the tool. However, it offers no when-not guidance and does not point to siblings such as read_messages for a narrower read, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.