update_need【需要登录】编辑自己发布的需求（仅 OPEN 状态可改）。可改 类型 / 标题 / 详情 / 配图，只传想改的。先用 list_my_needs 拿 needId。
【失败语义】非本人 403 not_your_need；非 OPEN（已取消或历史遗留关单）409 need_closed。被接洽/被承接不改变需求状态，仍是 OPEN、仍可编辑。
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 需求类型：EXPERIENCE（寻找产品/作品） | QA（答疑求助） | RESOURCE（介绍资源） | COLLAB（寻求合作） | FINANCING（融资需求） | CHAT（找人聊聊找灵感） | GIG（兼职招募） | OTHER（其它） | |
| title | No | ||
| detail | No | ||
| images | No | ||
| needId | Yes | 需求 id，从 list_my_needs 拿 |
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?
The description goes well beyond the annotations by disclosing partial-update semantics ('只传想改的'), ownership and status restrictions, exact error codes (403 not_your_need, 409 need_closed), and the fact that being contacted/accepted does not change OPEN status and editability. No contradiction with the annotations exists.
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 tight, well-structured paragraphs with no filler. The first paragraph covers action, prerequisites, editable fields, and partial-update behavior; the second covers failure semantics. Every sentence earns its place.
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 5-parameter mutation tool with no output schema, the description covers authentication, ownership, state gating, partial update behavior, parameter sourcing, and error handling. Field-level constraints are in the schema, so nothing critical is missing for correct invocation.
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 only 40%, so the description compensates by identifying which fields are editable, emphasizing that only provided fields are changed, and clarifying that needId comes from list_my_needs. It does not repeat length/format constraints for title/detail/images, but those are already encoded in the schema.
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 opens with a precise verb-resource pair, '编辑自己发布的需求', and immediately adds the key scope constraint '仅 OPEN 状态可改'. It lists the editable fields (type/title/detail/images) and even names the prerequisite helper list_my_needs, which makes it easy to distinguish from create_need, cancel_need, delete_need, and other need-related siblings.
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?
It clearly states when to use: login required, own need, OPEN status only, and it tells the agent to first call list_my_needs to obtain needId. It also gives implicit when-not guidance through failure semantics (403 for non-own, 409 for non-OPEN), though it does not explicitly name alternative mutation tools like create_need or cancel_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.