Skip to main content
Glama

独行录 / opcmenu

by io.github.yzlee
OverviewDiscussionsAdmin

设置我的通知偏好

set_notification_prefs
Idempotent

【需要登录】更新通知开关：只传想改的键，没传的保持原值（传 null 是有意义的值，会写进去）。

【七个推送开关】follows 新增关注 / dms 私信 / activities 活动 / drops 新品播报 / matches 撮合推送 / moments 消息圈互动 / nudge 未读私信的邮件短信触达——nudge 是邮件一键退订的落点，用户没说就别碰它。 【五个破冰治理键】icebreak=false 从此不被官方拉进破冰介绍三人群（选候选阶段就排除，连群都不建）；icebreakSnoozeUntil 传 ISO 时间 = 可恢复的软处理，比直接关更该先试，传 null = 取消；icebreakPace 节奏档；icebreakRole 只作需求方 / 只作提供方 / 都行。⚠ 把 icebreak 设回 true 时服务端会顺手清掉 snooze。 【组合链】只烦某一个群用 set_conversation_muted 或 leave_conversation；只烦某一条需求用 pause_need_icebreak。

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / moments
      Added value: +{
+  "description": "消息圈互动推送：有人评论了我的消息圈 / 回复了我的评论（点赞从不推送）",
+  "type": "boolean"
+}
  2. Changed7 schema fields changed
    • 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"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give the safety profile (idempotent, non-destructive, open-world). The description adds real behavioral context beyond them: login required, patch semantics, that null is a meaningful value that gets written, and a server-side effect (setting icebreak back to true clears snooze).

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?

Front-loaded with the key constraint (patch-only, null meaningful) and organized into labeled sections. It is dense and long, but every block carries distinct information; minor redundancy between description and per-parameter descriptions.

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

Completeness5/5

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

For a 12-param, output-schema-less, idempotent mutation tool, the description covers auth, patch semantics, side effects, and cross-tool routing. Nothing an agent needs to call it correctly is missing.

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 already 100%, so the baseline is 3, but the description adds grouped meaning (seven push switches vs five icebreak-governance keys), calls out nudge as the email-one-click-unsubscribe landing point, and explains icebreakSnoozeUntil null semantics that the schema states only tersely.

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

Purpose5/5

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

Explicit verb+resource: updates notification switches, with a stated scope ('only pass keys you want to change, others keep original value'). It clearly distinguishes itself from get_notification_prefs (read) and from the per-object muting siblings it names.

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?

The 【组合链】 section routes the agent: use set_conversation_muted or leave_conversation for a single noisy group, pause_need_icebreak for a single need. It also warns not to touch nudge unless the user asks. This is explicit when/when-not plus named alternatives.

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

All 独行录 / opcmenu toolsInspect
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