set_link_visibility【需要登录】把当前用户某条链接（按 url 匹配，可加 type 限定）的可见范围改成 public/friends/private。
【例】「把我的手机号改成仅自己可见」。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 目标链接 url | |
| type | No | 可选，进一步限定类型 | |
| visibility | Yes | public/friends/private |
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?
注解已声明非只读、非破坏性且幂等；描述在此基础上补充了登录要求、按 URL 匹配以及可见范围的可选值。不过未提及重复 URL 可能匹配多条链接等边界行为，因此没有给到满分。
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?
对于只有 3 个参数、无输出 schema 的简单修改操作，描述已覆盖登录前提、匹配规则、取值范围和典型示例，配合注解足够调用。但未说明 URL 匹配不到或重复匹配时的行为，略显不完整。
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 已 100% 覆盖三个参数，所以基线为 3。描述额外说明了 url 是匹配键、type 是进一步限定条件，并用示例直接演示了 visibility 的实际用法，增加了 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?
描述明确了具体操作（修改可见范围）、资源范围（当前用户的链接）、匹配方式（按 url，可加 type）和目标值（public/friends/private）。这与 add_profile_link、remove_profile_link 等兄弟工具明显区分，且附带示例进一步澄清意图。
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?
描述给出了明确的使用语境：需要登录、只能操作用户自己的链接，并附有「把我的手机号改成仅自己可见」的示例。虽然没有显式说明何时不应使用或与其他工具对比，但上下文已经足够清晰。
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.