Skip to main content
Glama
mcp-qzone-safe

mcp-qzone-safe

by hoholi-668

qzone_comment

Add a text comment to a QQ Zone post or reply to an existing comment, with rate limits and duplicate checks helping prevent repeated or excessive posting.

Instructions

评论某条说说,或回复某条评论(楼中楼)。需要 target_uin + tid + content。要回复评论时,额外传 comment_id + comment_uin(从 qzone_comments 拿)。≤120 字,禁止 CQ 码。同一条 24h 内只能评一次,每小时最多 3 条、每天最多 10 条。

Input Schema

NameRequiredDescriptionDefault
tidYes说说 tid
contentYes评论正文,纯文本
reply_uinNo楼中楼里要回复的那个人的 QQ 号(可选)
comment_idNo要回复的一级评论 id(qzone_comments 返回的 commentId)
reply_nameNo楼中楼里要回复的那个人的昵称(可选)
target_uinNo说说归属的 QQ 号;评论自己的说说可以不传
comment_uinNo被回复评论的作者 QQ 号

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses hard rate limits (once per post per 24h, 3/hour, 10/day) and content constraints (≤120 characters, CQ codes forbidden). These are non-obvious operational rules that would otherwise cause silent failures; only auth requirements and return behavior are unstated.

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 core action, then mode requirements, then hard constraints — a sensible ordering with no filler sentences. It is telegraphic and slightly terse (e.g. '需要 target_uin + tid + content' compresses a conditional into an apparent requirement), but every clause carries information.

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 7-parameter mutation tool with no annotations and no output schema, the description covers the two things an agent most needs: which parameters pair with which mode and the quotas that will reject calls. It does not describe the success response or how quota violations surface as errors, which leaves a small gap.

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 baseline is 3, but the description adds real meaning: it groups parameters by mode (target_uin + tid + content vs. the extra comment_id + comment_uin) and tells the agent where to source the comment ids. Minor issue: it lists target_uin as required while the schema marks it optional for one's own posts.

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?

Names a specific verb and resource (评论某条说说) and immediately distinguishes the two modes: commenting on a post vs. replying to a comment (楼中楼). An agent can tell it apart from qzone_like/qzone_publish without opening any schema.

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?

Explicitly states the conditional path: pass only tid + content normally, and add comment_id + comment_uin when replying to a comment. It even names the sibling tool that produces those ids (从 qzone_comments 拿), which is exactly the routing guidance an agent needs.

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