noyacg-mcp

发评论 / 回复评论

noy_comment

Posts a comment on a post or replies to an existing comment by rid; supports emoji codes and returns the new comment ID by rereading the list.

Instructions

在帖子下发评论。不带 reply_to_rid 是顶层评论（reply_id=-1）；带 reply_to_rid 是楼中楼回复。正文支持表情包代码。⚠️ 评论没有删除接口，发了就一直在；接口不返回评论 ID，本工具会回读列表找出新 rid。

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": {
      "post_id": "<post_id>",
      "text": "<text>"
    },
    "name": "noy_comment"
  }
}

Input Schema

Name	Required	Description	Default
`text`	Yes	评论正文
`adult`	No	是否请求成人向内容（allow-adult 请求头）。不传则用环境变量 NOY_ALLOW_ADULT，默认 false。注意 /api/home 的服务端默认值是 true（不带就是 R18），本项目会显式传 false。
`post_id`	Yes	帖子 ID
`platform`	No		web
`reply_to_rid`	No	要回复的评论 rid（楼中楼）；不传 = 发顶层评论

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial facts the annotations cannot express: comments cannot be deleted, the post is permanent, the API returns no comment ID, and the tool compensates by re-reading the list to find the new rid. The readback note also explains latency/side effects the agent would otherwise not expect from a non-idempotent write.

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?

Short and front-loaded, with the two-mode rule first and the irreversibility warning marked. The final sentence packs two distinct facts (no ID returned, list re-read) and could be split, but nothing is wasted.

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 non-idempotent write with no output schema, the description covers the essentials: permanent side effect, no returned ID, and the workaround. It does not warn that retries produce duplicate comments (a natural inference from idempotentHint=false), which would be the last missing piece.

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 80%, but the description still adds meaning: reply_id=-1 for top-level, and that text supports emoji/sticker codes (a format fact absent from the schema's plain '评论正文'). The adult and platform parameters remain schema-only, which is acceptable given existing coverage.

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?

States a specific verb+resource (在帖子下发评论) and immediately distinguishes the two modes it supports: top-level comment vs. nested reply via reply_to_rid. This is enough to separate it from siblings like noy_read_comment_replies or noy_create_post without opening the schema.

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 condition that selects each mode is explicit (no reply_to_rid = top-level; with reply_to_rid = nested reply), which is real routing guidance. It stops short of naming alternative tools (e.g., pointing readers at noy_read_comment_replies), so it is clear context without full alternative routing.

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