list_my_cooperation_requests登录;合作收发待办，仅标题；全文get_cooperation_request，回应respond_cooperation_request，协商get_cooperation_workspace。counts仅本批，truncated未取完。SHARE_INTEREST非方案邀请，workspace=null未开协商。peerUnavailable隐私裁剪勿补猜；relay按statusText说明，不计待对方回。目标成员邀请get_my_work，交流联系方式list_connection_requests。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 每个方向各取这么多条 | |
| status | No | 省略=不按状态过滤；「谁在等我回」= ["PENDING"] | |
| direction | No | incoming=别人发给我的；outgoing=我发出去的；省略=两边都要 | |
| peerUserId | No | 只看我和这个人之间的合作请求 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, it discloses real behavioral facts: login is required, counts covers only the current batch, truncated means results are incomplete, SHARE_INTEREST is not a proposal invitation, workspace=null means negotiation has not started, peerUnavailable is privacy redaction that must not be guessed, and relay items are not counted as awaiting the peer.
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 login and purpose, and every semicolon-delimited clause carries distinct information with no filler. The extreme telegraphic density comes at some cost to parseability, but nothing is redundant.
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?
With no output schema, the description takes on return-value disclosure and does so for the tricky fields (counts scope, truncated, workspace=null, peerUnavailable, relay). It does not enumerate the per-item fields beyond the title, leaving the full item shape partially implicit for a four-parameter listing tool.
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 coverage is 100%, so the schema already documents limit, status, direction, and peerUserId with examples. The description reinforces the direction semantics (收发 = both) but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.
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 states the resource (cooperation requests inbox, incoming/outgoing) and the key scope limit ('仅标题' — titles only), which lets an agent separate it from get_cooperation_request. The telegraphic phrasing ('合作收发待办') makes the verb implicit rather than stated outright, costing a bit of immediate clarity.
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?
Explicit routing is given to four alternatives with the condition that selects each: get_cooperation_request for full text, respond_cooperation_request to reply, get_cooperation_workspace to negotiate, get_my_work for member invitations, and list_connection_requests for contact exchange. There is also a filter hint for pending items via the status parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.