拉黑用户
block_user登录;拉黑某用户:双方互不能私信,并自动解除互相关注。处理骚扰时用。幂等:重复拉黑 no-op。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | 要拉黑的用户 id |
block_user登录;拉黑某用户:双方互不能私信,并自动解除互相关注。处理骚扰时用。幂等:重复拉黑 no-op。
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | 要拉黑的用户 id |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, so the '幂等:重复拉黑 no-op' clause earns no credit. The description does add real value by disclosing the unilateral side effect that the annotations do not convey: mutual DM blocking and automatic removal of mutual follows. However it omits reversibility (unblock_user) and what happens to existing conversations, and the hidden follow-removal is in mild tension with destructiveHint=false even if not a direct contradiction.
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?
Very dense and front-loaded: purpose, effects, when-to-use, then idempotency. The semicolon-chained telegraphic style and the bare '登录;' prefix make it slightly harder to parse than it needs to be, and the idempotency clause duplicates the annotation.
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 single-parameter mutation tool with no output schema and partial annotation coverage, the description covers purpose, side effects, use case, and repeat-call behavior — enough to call it correctly. Missing only the reversal path and the auth/permission requirement implied by '登录'.
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?
Only one parameter, and the schema already documents userId at 100% coverage ('要拉黑的用户 id'). The description adds no format, lookup, or self-block/precondition guidance beyond the schema, so baseline 3 applies.
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?
A specific verb + resource ('拉黑某用户') followed by the concrete effects (mutual DM block, auto-unfollow), which lets an agent understand the operation without opening the schema. It does not name or distinguish itself from nearby siblings such as unblock_user, ban_live_user, or list_my_blocks, so it stops short of a 5.
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?
'处理骚扰时用' gives an explicit use context (handling harassment) that an agent can match against a user request. There are no exclusions or alternatives, though — nothing says when to prefer report_content or ban_live_user over blocking, and no mention of unblock_user for reversal.
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.