Skip to main content
Glama
thsrite

mcp-quiver

by thsrite
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

mcp-quiver

自建 MCP 服务集合。Quiver 是箭袋——里面插着各种趁手的工具，需要哪支抽哪支。

服务

说明

传输

hotcontent

爆款内容雷达：全网热榜（85 榜）、公众号爆款文章（含全文正文）、小红书爆款笔记

http / stdio

docx-comments

Word 批注：提取批注文本、把批注内联进正文

stdio / http

安装

python3 -m venv .venv
.venv/bin/pip install -e .

装一次两个服务都可用，分别由 mcp-hotcontent 和 mcp-docx-comments 启动。

Related MCP server: wecom-doc-mcp

鉴权（HTTP 传输）

默认无鉴权——谁能访问端口谁就能调。设 MCP_AUTH_TOKEN 即启用 Bearer 校验：

# 生成一个令牌
openssl rand -hex 24

# 本地
MCP_AUTH_TOKEN=<令牌> mcp-hotcontent

# Docker
docker run -d -p 8931:8931 -e MCP_AUTH_TOKEN=<令牌> <user>/mcp-quiver

# 令牌放文件里，不出现在命令行和 ps 输出中
echo "MCP_AUTH_TOKEN=<令牌>" > mcp.env
docker run -d -p 8931:8931 --env-file mcp.env <user>/mcp-quiver

客户端带 header：

{
  "transport": "http",
  "url": "http://127.0.0.1:8931/mcp",
  "headers": { "Authorization": "Bearer <令牌>" }
}

实测行为：

未设 MCP_AUTH_TOKEN

设了

不带 header

放行

401

错误令牌

放行

401

正确令牌

放行

放行

只对 HTTP 传输有意义；stdio 走本地进程管道，由操作系统权限保护，不经过这层。 把服务暴露到局域网或公网时务必设置。

hotcontent — 爆款内容雷达

把三个零凭据数据源暴露成 MCP 工具，供 AI 助理查询后交给模型做选题对标、热点追踪和内容分析。无需 API key，无需登录。

运行

# HTTP（默认，监听 0.0.0.0:8931）
mcp-hotcontent

# 换端口
PORT=9000 mcp-hotcontent

# stdio
MCP_TRANSPORT=stdio mcp-hotcontent

Docker：

docker build -t hotcontent-mcp .
docker run -d -p 8931:8931 hotcontent-mcp

客户端配置

HTTP：

{ "transport": "http", "url": "http://127.0.0.1:8931/mcp" }

stdio：

{
  "command": "/path/to/.venv/bin/mcp-hotcontent",
  "env": { "MCP_TRANSPORT": "stdio" }
}

工具

工具

参数

说明

search_hot_topics

platform keyword limit max_boards

全网 85 榜实时热点

list_hot_boards

—

列出所有可用榜单

search_wechat_articles

keyword days limit original_only content_len

公众号爆款，唯一带全文正文

search_xiaohongshu_notes

keyword days limit

小红书爆款，带赞藏评转

返回统一带 granularity 字段，助理据此判断能谈什么：

  • topic（全网热榜）— 只有标题、排名、热度值，没有互动数。回答「什么话题在火」

  • content（公众号、小红书）— 完整互动数据 + 作者粉丝数。回答「哪条内容爆了、为什么爆」

覆盖范围

全网热榜 85 个（实时）：微博 · 知乎 · 微信 · 百度 · B站 · 抖音 · 快手 · 贴吧 · 虎扑 · 36氪 · 少数派 · 掘金 · 机器之心 · 量子位 · GitHub Trending · Product Hunt · App Store · 雪球 · 华尔街见闻 · 豆瓣 · 猫眼 · IMDb · QQ音乐 · 懂球帝 · 站酷 · Behance · 汽车之家 · FreeBuf 等

公众号（快照）：低粉爆款 / 10万阅读 / 1万阅读 / 原创榜

小红书（快照）：点赞Top500 / 低粉爆款 / 7日飙升 / 单日飙升

已知边界

这些是数据源本身的限制，不是 bug——SKILL.md 里也写明了，让助理如实告知用户而不是粉饰：

  • 全网热榜不含小红书，也不含推特 / YouTube 等境外平台

  • 不同平台的「热度」口径不同（微博万级、B站播放量、抖音播放次数），不能跨平台比大小

  • 公众号、小红书是入库快照，通常滞后 1–2 天；热榜是实时的

  • 小红书接口不返回笔记正文；link 缺 xsec_token，未登录浏览器点开会跳 404

  • 公众号 read 字段的 "10w+" 是平台封顶显示，非精确值；排序更该看分享和在看

给助理的技能说明

src/hotcontent_mcp/SKILL.md 是配套的技能指令，写明工具选择、粒度区分、诚实边界和输出规范（数字只用原值、条数不足如实说、禁止凑数）。支持技能库的客户端可以导入它，与 MCP 配合使用。

实现说明

  • 抓取逻辑在 src/hotcontent_mcp/fetchers/，三个模块也能脱离 MCP 单独当 CLI 跑：

    python3 -m hotcontent_mcp.fetchers.tophub --list

  • 全程标准 TLS 证书校验；本机 DNS 被分流工具劫持成 198.18.0.0/15 fake-ip 时，回退 DoH 解析真实 IP 直连，证书校验保持开启

  • 结果缓存 5 分钟；单次返回上限 50 条，正文默认截断 600 字，避免撑爆助理上下文

docx-comments — Word 批注处理

把 .docx 里的批注读出来，或内联进正文——让模型能一次看到「原文 + 审阅意见」的对应关系，而不是丢失批注。

运行

mcp-docx-comments                        # stdio（默认）
MCP_TRANSPORT=http PORT=8932 mcp-docx-comments   # HTTP

客户端配置

{
  "command": "/path/to/.venv/bin/mcp-docx-comments"
}

工具

工具

参数

说明

extract_comments

file_path 或 file_base64

提取全部批注文本

inline_comments_file

input_path output_path

读文件，批注以 【批注：…】 插入正文后另存

inline_comments_base64

file_base64 filename

同上，收发都走 base64

内联后的批注是红色加粗的 run，紧跟被批注内容之后。

两个服务统一使用 fastmcp v3。docx-comments 早期基于官方 mcp SDK 的 FastMCP， 迁移后结构化返回不再包一层 result：原先 {"result": "..."}，现在直接是字符串。 按 MCP 标准读 content 文本的客户端不受影响。

Available Tools

4 tools
list_hot_boardsA

列出全网热榜里所有可用的榜单（平台名 + 榜单名 + 条目数），供 search_hot_topics 的 platform 参数使用。

当用户问"能查哪些网站/平台"，或你不确定某平台在不在覆盖范围内时，先调这个。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses that the tool enumerates all available boards and that the result is meant to seed search_hot_topics' platform parameter. It does not explicitly state side-effect or rate-limit behavior, but an empty-parameter listing tool is clearly read-oriented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler; the core purpose and output shape come first, followed by when-to-use guidance. Every sentence earns its place.

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?

For a zero-parameter listing tool with an output schema, the description fully covers what the tool returns, how it relates to search_hot_topics, and when to invoke it. Nothing essential 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?

The input schema has zero parameters, so there is no schema burden and the baseline is 4. The description adds useful cross-tool context by linking the returned boards to search_hot_topics' platform parameter, though it does not need to explain any local parameters.

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 action (列出) on a concrete resource (全网热榜里所有可用的榜单) and specifies the output fields: platform name, board name, and entry count. It also positions the tool as the source for search_hot_topics' platform parameter, making it easy to distinguish from the searching siblings.

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

Usage Guidelines5/5

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

Gives explicit triggers: call it when the user asks which sites/platforms are queryable or when coverage is uncertain. This directly tells the agent when to use list_hot_boards instead of guessing or calling search_hot_topics.

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

search_hot_topicsA

查全网实时热榜（85 个榜单），覆盖微博/知乎/微信/百度/B站/抖音/快手/贴吧/虎扑/36氪/GitHub 等。

这是话题级数据：只有标题、排名、热度值，没有点赞收藏等互动数。 回答"现在什么在火"用它；回答"哪条内容爆了、怎么爆的"要用另两个工具。

数据实时（不同于公众号/小红书的快照）。注意：本数据源不含小红书榜。

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo每个榜单最多取几条，默认 12，上限 50
keywordNo按条目标题过滤，可跨所有榜单找某主题在全网的热度
platformNo平台/榜单名筛选，逗号分隔，子串匹配，如「微博,知乎,抖音」。留空=全部 85 个榜单。先调 list_hot_boards 看有哪些
max_boardsNo最多返回几个榜单，默认 8，防止一次拉回太多撑爆上下文

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the safety/behavior burden and does a good job: it discloses real-time freshness, topic-level granularity, absence of interaction counts, and the lack of Xiaohongshu data. It does not mention rate limits or auth, but this is a read-oriented search tool and the stated caveats are the most decision-relevant behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loads the scope, and uses formatting/bold to highlight the key distinction. Every sentence earns its place: coverage, data granularity, usage routing, freshness, and an exclusion caveat.

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?

Given an output schema exists and all four parameters are optional and documented in the schema, the description completes the picture: what the tool returns, when to use it versus alternatives, freshness, and an important data-source exclusion. No critical calling information is missing.

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 100%, so the schema already documents limit, keyword, platform, and max_boards fully. The description adds useful context ('85 boards', no Xiaohongshu, topic-level data) but does not materially change parameter semantics beyond the schema descriptions.

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?

The description opens with a specific verb and resource: '查全网实时热榜（85 个榜单）' and enumerates the covered platforms. It also differentiates itself from the content-search siblings by stating this is topic-level data (titles, ranks, heat values only) and that answering 'which content exploded' requires the other tools.

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

Usage Guidelines5/5

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

Explicitly prescribes when to use this tool: answer 'what is trending now'; for content-level explosion questions it points to the two sibling search tools. It also gives a negative boundary ('本数据源不含小红书榜') and points to list_hot_boards in the schema for valid platform names.

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

search_wechat_articlesA

查公众号爆款文章。三个数据源里唯一带全文正文的，最适合做选题对标和写作风格分析。

榜单：低粉爆款 / 10万阅读 / 1万阅读 / 原创榜。 返回每篇的标题、摘要、正文、阅读/点赞/在看/分享/评论、作者粉丝数、是否原创、原文链接。 数据为入库快照（非实时），通常滞后 1-2 天。

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo时间窗口天数 1-30，默认 7。本数据源该参数真实生效
limitNo返回条数，默认 12，上限 50
keywordNo赛道/细分关键词，留空=全站热门。细分词（如「职场沟通」）比大类词（如「职场」）结果更准
content_lenNo每篇正文截断长度，默认 600，0=不截断（谨慎，正文最长可达 2.6 万字）
original_onlyNo只要原创文章

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden. It explicitly discloses the data is an in-house snapshot (not real-time) with typical 1-2 day lag, and lists the returned fields, giving agents a clear expectation of behavior and output context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with clean line breaks, front-loading the core purpose and unique value before supporting details. No filler or redundancy.

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?

The rich 5-parameter schema and presence of an output schema mean the description doesn't need to restate parameters or return structure. It adds the essential use case, ranking lists, and data freshness caveat. It could have explicitly named sibling tools to strengthen routing, but the context is sufficient.

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 the baseline is 3. The description itself adds no parameter-specific meaning; the schema already documents defaults, ranges, and caveats like '本数据源该参数真实生效' for days.

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?

The description opens with a clear verb+resource pair: '查公众号爆款文章' (search WeChat viral articles). It also claims to be the only data source with full text, distinguishing it from sibling tools like search_xiaohongshu_notes.

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 states the tool is best for topic benchmarking and writing style analysis, and notes the data is a non-real-time snapshot with 1-2 day lag, implying not to use it for real-time needs. It doesn't explicitly name alternatives, so it stops short of a 5.

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

search_xiaohongshu_notesA

查小红书爆款笔记。有完整互动数据但没有笔记正文（接口不提供）。

榜单：点赞Top500 / 低粉爆款 / 7日飙升 / 单日飙升。 返回标题、话题标签、作者粉丝数、点赞/收藏/评论/分享、封面图。

两个已知限制，回答用户时要如实说明：

  • desc 字段常为空：源数据的 desc 就是「标题+话题标签串」，去标签后 44% 完全为空，不是抓取失败

  • link 打不开：笔记链接缺 xsec_token，未登录浏览器会跳 404，只能当唯一标识用

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo时间窗口天数 1-30。注意：实测该参数对本数据源基本不生效，保留仅为兼容
limitNo返回条数，默认 12，上限 50
keywordNo赛道/细分关键词，留空=全站热门。冷门词可能无数据，建议用热门赛道词

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure burden and does so excellently. It explicitly states known limitations: no note body, desc field often empty (44%) and why, and links lacking xsec_token causing 404s, plus the caveat that days is effectively non-functional. This is far beyond typical transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core purpose, then structured into return fields and known limitations. Every sentence adds value, and the known-limitations section is clearly separated for agent consumption.

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?

Given the output schema exists and the description covers purpose, return fields, ranking types, parameter caveats, and known data-quality issues, it is complete enough for an agent to invoke the tool correctly and set user expectations appropriately.

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 100%, so the schema already documents days, limit, and keyword including the days ineffectiveness and cold-keyword caveats. The description adds context about returned data and link limitations, but it does not materially enrich parameter semantics beyond what the schema provides.

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?

Description opens with '查小红书爆款笔记', a specific verb, resource, and platform, and further specifies ranking categories and returned fields. This clearly distinguishes the tool from siblings like search_wechat_articles and list_hot_boards by platform and content type.

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?

Provides clear operational context: which rankings are available, what data is returned, and actionable keyword advice (cold words may return nothing, prefer popular track words). It does not explicitly contrast against sibling tools, but the platform and content-type focus make the appropriate usage obvious.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv0.2.0
    • First observedlist_hot_boards
    • First observedsearch_hot_topics
    • First observedsearch_wechat_articles
    • First observedsearch_xiaohongshu_notes
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct role: listing available boards, querying real-time hot topics, searching WeChat articles, and searching Xiaohongshu notes. The descriptions explicitly separate topic-level data from content-level data, so an agent should not confuse them.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_object pattern: list_* for enumeration and search_* for content/topic lookup. Platform-specific tools are named uniformly as search_<platform>_<content_type>, making the set predictable.

Tool Count5/5

Four tools is well-scoped for this server's purpose: one metadata/discovery tool, one cross-platform topic tool, and two platform-specific content tools. Each tool earns its place with no redundancy.

Completeness5/5

The tool surface covers the core hot-content workflow: discovering available boards, checking real-time topics, and retrieving detailed content from both WeChat and Xiaohongshu. Documented limitations are inherent to the data sources rather than missing tool capabilities, so there are no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Weixin MCP

    Bwkyd
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables reading and extracting content from WeChat public account articles using browser automation, allowing AI models to analyze and summarize WeChat articles through natural language requests.
    447
    MIT

  • xhs-comment-analyzer

    nideaon
    A
    license
    A
    quality
    C
    maintenance
    Enables AI clients to search Xiaohongshu notes by brand and category, batch extract comments, and perform keyword/sentiment/heat analysis, with results exported as Excel and JSON reports.
    4
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thsrite/mcp-quiver'

If you have feedback or need assistance with the MCP directory API, please join our Discord server