Skip to main content
Glama
coolapk-mcp-pro

coolapk-mcp-pro

by yufeng-liang

coolapk_feed_detail

Retrieve complete Coolapk post details and replies, including author follow-ups, keyword-filtered comments, and edit history; falls back automatically when the detail endpoint is risk-controlled.

Instructions

获取酷安帖子的完整详情和回复(详情接口被风控时自动回落)。

工具帖找资料建议用 comments_focus=smart:一次拿到「正文 + 楼主全部补充 + 高赞反馈」,获取方式与答疑多在楼主回复里。

Args: feed_id: 帖子ID with_replies: 是否包含回复列表,默认是 reply_page: 回复页码(all_replies / comment_keyword / comments_focus 非 default 时忽略) all_replies: 拉全部一级评论(自动翻页,含内联楼中楼),适合完整舆情/评论分析 comment_keyword: 按关键词检索评论和楼中楼(自动拉全量;空格分隔多词=任一命中; 命中条目带 comment_match 字段,楼中楼按上下文保留,统计见 comment_search) comments_focus: 评论聚焦模式:default(默认时间序一页)/ smart(楼主全部回复 + 热门评论,找工具帖资料首选)/ author(只看楼主)/ hot(只看热门)/ all(全部一级评论,等同 all_replies) with_history: 附带正文修改历史(作者每次编辑的快照,看版本演进) expand_sub_replies: 深度展开楼中楼(对回复数多的父评论补全子回复, 楼主答疑常在楼中楼深处;会额外发请求,只在需要时开)

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": {
      "feed_id": "<feed_id>"
    },
    "name": "coolapk_feed_detail"
  }
}

Input Schema

NameRequiredDescriptionDefault
feed_idYes
reply_pageNo
all_repliesNo
with_historyNo
with_repliesNo
comments_focusNodefault
comment_keywordNo
expand_sub_repliesNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.6.7
    • addedInput schema / properties / comments_focus
      Added value: +{
      +  "default": "default",
      +  "title": "Comments Focus",
      +  "type": "string"
      +}
    • addedInput schema / properties / expand_sub_replies
      Added value: +{
      +  "default": false,
      +  "title": "Expand Sub Replies",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / with_history
      Added value: +{
      +  "default": false,
      +  "title": "With History",
      +  "type": "boolean"
      +}
  2. First observedv0.6.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it discloses non-obvious behavior: automatic fallback on risk control, reply_page being ignored when all_replies/comment_keyword/comments_focus is non-default, added comment_match fields, and that expand_sub_replies issues extra requests. It omits auth requirements, rate limits, and pagination ceilings.

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?

The fallback note and the smart-mode recommendation are front-loaded, then an Args block covers each parameter in one or two lines without padding. The structure is well suited to an eight-parameter tool, with only light redundancy in restating defaults already present in the schema.

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

Completeness5/5

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

An output schema exists, so return values need no explanation; for an eight-parameter, annotation-free tool the description still covers behavior, parameter interactions, cost warnings, and mode selection. Nothing essential for correct invocation is missing.

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 description coverage is 0%, so the description must compensate, and it largely does: it defines all eight parameters, supplies semantics for the five comments_focus values that the schema lists only as a bare string, gives keyword syntax (space-separated = any match), and documents parameter interactions. Minor gaps remain for feed_id format and the precise meaning of with_replies=false.

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 names a specific verb and resource ('获取酷安帖子的完整详情和回复') and adds a distinctive behavior: automatic fallback when the detail endpoint is risk-controlled. It is clear what the tool returns, though it does not explicitly contrast itself with siblings such as coolapk_get_url or coolapk_author.

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 gives concrete usage advice — use comments_focus=smart when hunting for material in tool posts, because the author's follow-ups live in the replies — and explains when each focus mode applies, including that 'all' equals all_replies. It stops short of saying when to skip this tool in favor of a sibling.

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