Skip to main content
Glama

qzone_comment_feed

Post a comment on a specified QQ Space feed post using the poster's QQ number, the feed ID from the feed list, and the comment text.

Instructions

对指定说说发表评论。需先通过 qzone_get_feed_list 拿到 tid。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "targetUin": "<targetUin>",
      "tid": "<tid>",
      "content": "<content>"
    },
    "name": "qzone_comment_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
tidYes说说 ID
contentYes评论内容
targetUinYes说说发布者 QQ 号

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full disclosure burden. It correctly implies a write/mutation action and reveals the data dependency on qzone_get_feed_list, but says nothing about auth requirements, permission on the target's feed, rate limits, or whether comments can be edited/removed.

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?

Two short sentences; the action is stated first and the prerequisite second. Nothing is redundant, though the phrasing is terse enough to omit useful context.

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

Completeness3/5

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

For a three-parameter mutation with no annotations and no output schema, the definition covers the action and data dependency but leaves auth state, failure behavior, and success response unexplained. Adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (tid, content, targetUin) are already documented in the schema. The description only adds the provenance of tid, not syntax, length limits, or constraints on content.

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?

"对指定说说发表评论" states a specific verb (发表评论, post a comment) plus the target resource (说说/feed), which is unambiguous. It is also linked to a specific sibling for obtaining input, though it does not distinguish itself from a hypothetical reply/like tool.

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

Usage Guidelines4/5

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

The description gives an explicit prerequisite workflow: obtain tid via qzone_get_feed_list before calling. It stops short of stating when NOT to use this tool or whether login must be established first (a sibling qzone_check_login exists).

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