get_need_recommendations【需要登录】对自己发布的某条需求拉个性化推荐：谁最可能满足它（一人一卡，按「对方能提供的 ↔ 我的需求」向量匹配 + 回复率/活跃度加权，含 matchScore / matchReason / authorNeeds）。这是「发完需求主动出击」的工具，不用干等撮合推送。
【组合链】看中某人 → contact_need 对方的需求或 start_conversation 直接开聊。续拉传回 nextCursor，并把已看过的需求 id 放进 seen 软性下沉。
【越权】只能查自己的需求，别人的会被拒（not_your_need）。
| Name | Required | Description | Default |
|---|---|---|---|
| seen | No | 本会话已看过的需求 id，续拉时传入软性下沉 | |
| limit | No | 返回条数，默认 20 | |
| cursor | No | 分页游标 nextCursor，原样回传延续同一副牌 | |
| needId | Yes | 我的需求 id，从 list_my_needs 拿 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With minimal annotations (readOnlyHint:false, etc.), the description carries the full burden and delivers: login required, ownership check, algorithm details, return fields, pagination behavior, and soft down-ranking via seen. No contradiction with annotations.
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?
Structured with clear headers (需要登录/组合链/越权), each sentence earns its place. Purpose is front-loaded, usage and constraints are concise.
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?
No output schema, but description specifies return fields and algorithm. Covers pagination, permissions, follow-up tools, and differentiates from passive matching. Complete for an agent to call correctly.
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 baseline is 3. The description adds value by explaining how seen and cursor work together for continued pagination, and clarifies needId source (list_my_needs). This goes beyond the schema's individual descriptions.
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?
Description states a specific action (拉个性化推荐) for a specific resource (自己发布的某条需求), explains the matching algorithm and output fields (matchScore/matchReason/authorNeeds), and distinguishes itself from passive matching push. It clearly differentiates from siblings like get_my_need_matches.
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?
Explicitly says this is the proactive tool after posting a need, not waiting for push. Provides a follow-up chain (contact_need or start_conversation), explains pagination with cursor and seen, and states the ownership restriction (only own needs, others rejected).
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.