独行录 / opcmenu

设置我的通知偏好

set_notification_prefs

Idempotent

【需要登录】确认后patch，未传不变，无要求勿动SMS/邮件。icebreak=false停自动拉群；snoozeUntil=null解除暂停，恢复true清暂停。单群静音/退群及单需求暂停另调；避人/方向set_my_match_preference。先get_notification_prefs。

Input Schema

TableJSON Schema

Name	Required	Description
`dms`	No	私信推送
`drops`	No	新品播报
`nudge`	No	未读私信的邮件/短信触达提醒（邮件一键退订落这里；用户没提就别动它）
`recall`	No	召回提醒：有人在关注你 / 有匹配的需求找你（独立于 matches）
`follows`	No	新增关注通知
`matches`	No	撮合推送：新需求与我价值匹配时
`moments`	No	消息圈互动推送：有人评论了我的消息圈 / 回复了我的评论（点赞从不推送）
`icebreak`	No	破冰介绍：false = 从此不被官方拉进破冰介绍三人群（选候选阶段就排除，连群都不建）
`activities`	No	活动通知
`icebreakPace`	No	破冰节奏档：less 周 1 / normal 周 3 / more 周 5
`icebreakRole`	No	只作需求方 seeker_only / 只作提供方 helper_only / 都行 both
`icebreakSnoozeUntil`	No	破冰先停一阵：ISO 8601 含时区；传 null = 取消停一阵（服务层不校验格式，格式闸只有这一层）

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / moments

Added value: +{
+  "description": "消息圈互动推送：有人评论了我的消息圈 / 回复了我的评论（点赞从不推送）",
+  "type": "boolean"
+}

Changed7 schema fields changedSep 21, 2026

addedInput schema / properties / icebreak

Added value: +{
+  "description": "破冰介绍：false = 从此不被官方拉进破冰介绍三人群（选候选阶段就排除，连群都不建）",
+  "type": "boolean"
+}

addedInput schema / properties / icebreakPace

Added value: +{
+  "description": "破冰节奏档：less 周 1 / normal 周 3 / more 周 5",
+  "enum": [
+    "less",
+    "normal",
+    "more"
+  ],
+  "type": "string"
+}

addedInput schema / properties / icebreakRole

Added value: +{
+  "description": "只作需求方 seeker_only / 只作提供方 helper_only / 都行 both",
+  "enum": [
+    "both",
+    "seeker_only",
+    "helper_only"
+  ],
+  "type": "string"
+}

addedInput schema / properties / icebreakSnoozeUntil

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "破冰先停一阵：ISO 8601 含时区；传 null = 取消停一阵（服务层不校验格式，格式闸只有这一层）"
+}

changedInput schema / properties / matches / description

Previous value: -"新需求与我价值匹配时的撮合推送"New value: +"撮合推送：新需求与我价值匹配时"

changedInput schema / properties / nudge / description

Previous value: -"未读私信的邮件/短信触达提醒"New value: +"未读私信的邮件/短信触达提醒（邮件一键退订落这里；用户没提就别动它）"

addedInput schema / properties / recall

Added value: +{
+  "description": "召回提醒：有人在关注你 / 有匹配的需求找你（独立于 matches）",
+  "type": "boolean"
+}

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true), and the description goes further with patch semantics (unspecified fields unchanged), login requirement, and value-specific side effects (icebreak=false stops auto-group-pulling; snoozeUntil=null lifts the pause; restore=true clears it). No contradiction with the mutation/destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: login requirement and patch contract come first, then key value semantics, then sibling routing. Every clause carries an instruction, and there is no filler, though the telegraphic style packs several distinct concerns into run-on clauses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation tool with no output schema, the description covers the login prerequisite, patch contract, important edge-case values, and routing to related tools. It is close to sufficient, with only minor gaps around what the operation returns or how conflicts are handled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: icebreak=false's downstream effect and the interaction between snoozeUntil=null and restoring behavior. That is genuine value beyond the per-field schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The name plus title (设置我的通知偏好) make the verb+resource unambiguous, and the description reinforces it with patch semantics and sibling routing. It does not explicitly restate 'set notification preferences', but combined with the scoping details the purpose is clear and distinguishable from siblings like get_notification_prefs and set_my_match_preference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when/when-not/alternatives: it excludes single-group mute/leave-group and single-need pause as separate calls, routes avoid-people/direction work to set_my_match_preference, warns not to touch SMS/email unasked, and instructs to call get_notification_prefs first. This is about as complete a routing guide as possible.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All 独行录 / opcmenu tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?