Skip to main content
Glama
noyacg-mcp

noyacg-mcp

by kwkare

看楼中楼

noy_read_comment_replies
Read-only

Reads all replies under a comment in reverse chronological order, letting you load additional nested replies beyond the few already included in comment details.

Instructions

读取某条评论下的全部回复(楼中楼),按时间倒序。评论详情接口通常已内联前几条,这里用于「加载更多」。root_id 是根评论的 rid,reply_id 指向被回复的那一条。

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>",
      "rid": "<rid>"
    },
    "name": "noy_read_comment_replies"
  }
}

Input Schema

NameRequiredDescriptionDefault
ridYes根评论的 rid
pageNo页码,从 1 开始
adultNo是否请求成人向内容(allow-adult 请求头)。不传则用环境变量 NOY_ALLOW_ADULT,默认 false。注意 /api/home 的服务端默认值是 true(不带就是 R18),本项目会显式传 false。
limitNo
post_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds reverse-chronological ordering and the relationship to the detail endpoint's inlined replies, but it says nothing about pagination end behavior, whether nested sub-replies are flattened, or how 'adult' affects returned content. The 'reply_id' mention implies a parameter that does not exist, which risks misleading the caller.

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?

Three compact clauses, front-loaded with what is read and the sort order, followed by the use case. No wasted text, though the trailing root_id/reply_id sentence could be dropped or rewritten to match the schema.

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?

With no output schema, the description should convey the shape of the result (are replies flat or threaded, does 'limit' bound top-level replies or all entries). It covers purpose, ordering, and the load-more pattern but leaves the return structure and the 'limit'/'post_id' roles undetermined.

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 coverage is 60% — 'rid', 'page', and 'adult' are documented, while 'limit' and 'post_id' have no description at all. The description reinforces that 'rid' is the root comment's id, but it introduces 'root_id'/'reply_id' terminology that does not match the actual parameter names, which costs more clarity than it adds.

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?

The description uses a specific verb+resource ('读取某条评论下的全部回复(楼中楼)') and adds the ordering and the 'load more' framing, which separates it from the detail endpoint that inlines the first replies. It is slightly muddied by referencing 'root_id' and 'reply_id', names that do not appear in the schema (which uses 'rid').

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?

It explicitly states the situation in which this tool is needed ('评论详情接口通常已内联前几条,这里用于「加载更多」'), which is a clear when-to-use condition. It does not name a sibling tool as the alternative, so an agent must infer which call provides the inlined first replies.

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