complete_need【需要登录】在某个接洽会话里点「完成需求」。双方各确认一次：发起人和承接人都要在同一会话里各调一次本工具，双方都确认后该承接才置 COMPLETED；只有一方调过时处于等待对方确认状态（看返回的 authorDoneAt / claimerDoneAt）。
【前置】conversationId 必须是 contact_need 建立的那个会话。确认是真实状态变更，调用前先向用户确认「事情确实办完了」。
【失败语义】非该需求当事人 403 not_party_to_need；会话没绑这条需求 409 no_claim_for_conversation；已完成 409 need_already_completed；已取消 409 need_closed。
| Name | Required | Description | Default |
|---|---|---|---|
| needId | Yes | 需求 id | |
| conversationId | Yes | 接洽会话 id（contact_need 返回的那个） |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述超越了 annotations 的内容，明确说明这是真实状态变更、非幂等、双方确认后才完成，并解释了等待确认状态（authorDoneAt / claimerDoneAt）以及各类失败语义。与 readOnlyHint=false、idempotentHint=false 一致，无矛盾。
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?
描述按【需要登录】【前置】【失败语义】分段组织，信息密度高且无冗余。前置条件和双人确认逻辑放在前面，错误码放在后面，结构清晰。
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?
该工具是包含双方确认状态机和多种失败场景的变更操作，且无 output schema。描述覆盖了前置条件、状态流转、返回字段提示、错误语义以及人工确认要求，对调用者而言足够完整。
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?
input schema 已对参数有 100% 覆盖，描述进一步补充了 conversationId 必须来自 contact_need 建立的会话，并间接说明 needId 与 conversationId 的绑定关系，增强了参数含义。
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?
明确表述了操作：在接洽会话中确认完成需求，并说明双人确认机制（发起人和承接人各调一次）后置为 COMPLETED。与 cancel_need、delete_need、reopen_need 等兄弟工具语义区分清楚。
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?
给出了明确的使用前提：conversationId 必须是 contact_need 建立的会话，且需要双方各确认一次；还提示调用前先向用户确认事情确实办完。虽然未显式说明与其他工具的对比或排除场景，但语境和前置条件已经足够指导使用。
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.
Each tool has a clearly documented purpose, often with explicit 'when to use' guidance and cross-references, making the vast majority easy to tell apart. A few clusters (get_my_brief, get_my_positioning, get_my_work, get_my_dispatch) and data-overlapping get_my_card vs get_my_profile require careful reading, but descriptions are detailed enough to prevent serious misselection.
The overwhelming majority follow snake_case verb_noun conventions (create_product, update_need, list_my_signups). Minor deviations include noun-only feed names (personalized_feed, random_feed), inconsistency between 'prefs' and 'preferences' in notification tools, and a mix of update_* and set_* for mutations, but the pattern remains predictable overall.
137 tools is an extreme mismatch for any MCP server, far exceeding the 50+ threshold for a score of 1. Even with a broad multi-domain platform, this volume makes tool selection and navigation impractical and heavily burdens the agent's context window.
The surface covers full lifecycles for needs, products, activities/signups, conversations, collaboration goals/tasks, dispatch, profile/onboarding, and supporting resources like companies, parks, policies, and ratings. Deliberate omissions (no user-post creation, no organizer profile editing via agent) are explicitly documented, so core workflows have no obvious dead ends.