A
licenseNot graded
qualityD
maintenanceExposes litmedia.ai text-to-image and image-to-video generation tools via MCP, enabling AI agents to generate images and videos directly from prompts.
2
MIT
museav-mcp
by cortexos-dev
A writing-quality gateway: it statically gates AI-flavored prose and generates anti-hallucination content skeletons — and it can tell you which other capability groups exist but aren't installed.
writing_lint— Static scan of Markdown text or a file to mechanically block AI-假人 habits: boilerplate transitions (总的来说/毋庸置疑), mechanical parallelism (不仅…更是…), high-school-essay imagery (犹如一幅画卷), and empty positive endings; returns offending line numbers plus fix suggestions. Zero dependencies.writing_rubric— Pull the pre-publish scoring rubric and fatal anti-patterns for 说说-type posts on 小红书 / Twitter / Reddit / 掘金 (orall); each violation costs 20 points, below 80 = do not publish.writing_compose— Generate a high-signal, zero-AI-flavor prompt constraint or content skeleton from the 5D atomic matrix (persona × platform × scenario × topic, plus tone); requires all four core fields, tone defaults to 粗粝真实.groups_list— Discover the full capability map: which groups are enabled (and how many tools each), which are disabled because their CLI isn't on PATH, and which open-source project + install command each maps to — always available even when other groups aren't registered.
Note: per this schema only the writing group (plus groups_list) is registered; the README's other groups — museav (image/video generation, local post-processing, SkillHub publishing), vlm (local image understanding), contrast, facet, reel, browser, scorecard, wechat — appear only as install hints via groups_list, not as callable tools here.
Provides tools for auditing GitHub projects via scorecard, assessing open-source maturity and brand quality across multiple dimensions.
Provides tools for auditing npm packages via scorecard, assessing open-source maturity and brand quality across multiple dimensions.
Provides tools for reading local WeChat data on macOS via wx-cli, including conversations, contacts, chat messages, and full-text search.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@museav-mcpUpscale /home/user/photo.png and then remove the background."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
⚠️ 别和 cs mcp serve 搞混
系统里有两个都叫「cs 的 MCP」的东西。它们互补，不重合 —— 接错的那个会得到一堆你不需要的工具：
| 本仓 cs-mcp | |
形态 | Go， | TypeScript，单文件二进制（也可从源码跑） |
server 名 |
|
|
管什么 | 系统上下文：规则 / 技能 / 知识搜索 / CLI 台账 / Agent 上下文 | 工具链串联：各开源项目的 CLI 能力 |
真源 |
| 各项目自己的 CLI |
数量 | 11 个只读发现工具 | 55 个工具，9 个能力分组 |
一句话分界：想知道「cs 系统里有什么规矩、有什么技能」用 cs mcp serve；
想「出一张图、把 Markdown 排成 PDF、开个真浏览器、做开源质检、给文案去 AI 味」用 cs-mcp。
顺带一句：Agent 侧其实不需要 MCP。 能跑 Bash 的 Agent 直接调
csCLI 就够， 而且那是主干道（MCP 的通路管不到远端机器）。MCP 的价值只在跑不了 Bash 的客户端上。 见cs rule里cmd/mcp.go的定位说明。
Related MCP server: DreamLayer image tools
🎯 为什么用它，而不是别的
需求 | 逐个手搓命令 | 每个工具各接一遍 SDK | cs-mcp |
一个 Agent 里同时用出图 / 看图 / 门禁 / 排版 | ❌ 四套用法 | ❌ 接四遍协议 | ✅ 一个 server 全给 |
换 Agent 就失效 | ❌ 命令绑定 | ⚠️ 各家 SDK 不同 | ✅ 换谁都认 MCP |
没装的工具白占上下文 | — | ❌ 全量注册 | ✅ 探测式：装了才注册 |
大图 / 长文进上下文 | ❌ 手动处理 | ❌ 自己写 base64 | ✅ 一律走绝对路径 |
加新能力 | 各自记命令 | ❌ 得改 MCP 代码 | ✅ 升级 CLI 就生效（MCP 只做串联） |
分层是硬的：能力在 CLI 里，MCP 只做串联。 这个仓自己零实现 —— 每个工具都是对某个项目 CLI 的一次薄封装。所以 CLI 一升级，MCP 这边立刻就有新能力；MCP 不重写任何逻辑，也就不存在 「两边行为不一致」。
传输方式 stdio。文件以绝对路径传入，处理结果写回磁盘并返回路径 —— 不走 base64。
🧩 能力分组（这张就是版图）
分组 | 层次 | 开源项目 | 工具 | 干什么 | 前置 |
| 云能力 | 17 | 出图 / 出视频、本地后期（抠图·超分·去水印·压缩）、模板与技能清单、素材上传、图生模板、SCULPT 反推、小红书 SkillHub 发布 |
| |
| 本地 | 4 | 本地离线看图：描述、任意提问、封面质检、反推出图 prompt |
| |
| 本地 | 3 | 对比度门禁：静态查色值达不达标、渲染后量实际字号灰阶、存基线与基线对比 |
| |
| 本地 | 2 | Markdown 排版成 PDF / 长图 / 讲稿页（自带多套模板） |
| |
| 本地 | 3 | 素材 + 逐句文案 → 竖版成片（模板 / 转场 / 配乐 / 可选配音） |
| |
| 本地 | 13 | 真实 Chrome：打开/快照/点击/输入/截图/执行 JS + 人类交接协议 + 多 agent 会话隔离 |
| |
| 本地/云 | 3 | 开源项目成熟度与品牌质检：GitHub / npm / 网页 9 维度审计 + GEO 品牌可见度份额 |
| |
| 本地 | 3 | 去 AI 假人味静态门禁扫描、小红书/X/Reddit/掘金说说扣分清单、5D 原子矩阵人设合成 | 零依赖（内置） | |
| 本机 Mac | 6 | 微信会话、联系人、聊天消息、全文搜索；数据库留在这台 Mac |
| |
— | 自带 | 本 MCP | 1 |
| 无 |
九组里只有 museav 是在线服务：要登录、要网络、有余额配额、会花钱；wechat 是这台 Mac 的本地微信数据读取能力（真实聊天内容属于私有数据）。其余七组是本地工具。
这个差别在工具面上直接可读 —— 云能力那 17 个统一带 museav_ 前缀。owner 的口径就一句：
cs 是核心，museav 是云能力。
默认策略是探测式：某个分组的 CLI 在 PATH 上，它的工具才会注册。理由是工具 schema
会随每一次模型请求发出去 —— 聚合 MCP 越串越多，不该让用户为「他机器上根本没装的工具」
付 token。没启用的分组不会消失：groups_list 始终可用，它会告诉你这个 MCP 还能干什么、
该装什么。
想强开或裁剪，用环境变量 CS_MCP_GROUPS：
CS_MCP_GROUPS=all # 全开（缺 CLI 的分组也注册，调用时才报装什么）
CS_MCP_GROUPS=facet,contrast # 只开这几个
CS_MCP_GROUPS=-museav # 默认集里去掉这几个3.0.0 之前的旧名
MUSEAV_MCP_GROUPS仍兼容（新名优先，同时设置且不同时以新名为准并在 stderr 提示）。之所以必须留旧名：变量被忽略不会报错 —— 它会静默回落成探测式， 原来写all的人那些强开的分组会悄悄消失，连告警都没有。
⚡ 30 秒上手
装（一条命令，不需要 Node，也不需要 npm）：
curl -fsSL https://raw.githubusercontent.com/cortexos-dev/cs-mcp/main/install.sh | bash装完会自报版本（cs-mcp --version），并把接法一并打出来：
claude mcp add cs -- ~/.local/bin/cs-mcp为什么不是
npx -y cs-mcp：这个网关底下包着 museav-cli、mlx-vlm-kit、 contrast-guard、facet、reel-kit、lite-browser 一堆东西 —— 用户为了用上全套能力， 已经要付 6 种安装方式的代价（npm / pipx / brew / curl）。如果网关自己还得npm i -g或npx -y，等于在最前面再加一道 Node + npm + registry 网络的门槛， 而它本该是把门槛降到一条命令的那一层。多数用户会卡在起手第一步。 （npm 上的cs-mcp早已撤下、本仓不再发 npm —— 装法只有上面这一条。）
想要哪组能力就装哪个 CLI —— 装了哪个 CLI 就自动长出哪组工具，没装的不会白占上下文：
npm i -g museav-cli # 这一行是出图那组从源码起（改这个仓、或不想下二进制）：
git clone git@github.com:cortexos-dev/cs-mcp && cd cs-mcp
pnpm install && pnpm build
claude mcp add cs -- node "$PWD/dist/index.js"Windows 暂时没有一键脚本，用 WSL 或走「从源码起」那条。
然后在 Agent 里说「用 museav 出一张图」，或者先问一句「这个 MCP 有哪些能力分组」。
工具（43 个）
museav 组 —— MUSE AV 出图中台（17）
工具 | 干什么 | 是否需要登录 |
| 出背景图 / 一般出图 / 出视频（走中台） | ✅ 需要 |
| 抠图去背景（BiRefNet / ISNet / U2Net），输出带 alpha 的 PNG | 免登录，本地跑 |
| 超分放大（Real-ESRGAN + Vulkan GPU），默认 4x | 免登录，本地跑 |
| 去水印（LaMa 修复），自动定位，可传手工掩码 | 免登录，本地跑 |
| 压缩（sharp），可指定最长边 / 质量 / 格式 | 免登录，本地跑 |
| 查可用图片 / 文字模板（挑 | ✅ 需要 |
| 查可用技能（挑 | ✅ 需要 |
| 查可用视频模板（与 | ✅ 需要 |
| 查可用模型； | ✅ 需要 |
| 查上游余额 | ✅ 需要 |
| 查自己的出图工作流（结果 URL、失败原因） | ✅ 需要 |
| 上传素材拿公网直链（垫图要 URL 时用） | ✅ 需要 |
| 图生模板：读图 + 文字层逆向 + 变量化 | ✅ 需要 |
| 读图反推 SCULPT prompt（中台 API）。与 | ✅ 需要 |
| 查小红书 SkillHub 内容标签（发布必带，别硬编码） | ✅ 需要 |
| 查 SkillHub 登录态（脱敏） | ✅ 需要 |
| 把本地 Agent Skill 发到小红书 SkillHub。默认 dry-run， | ✅ 需要 |
本地后期那四个不联网、不消耗中台额度。
vlm 组 —— 本地看图理解（4）
工具 | 干什么 |
| 描述图片主体与色调 |
| 对图片任意提问 |
| 音乐封面语义质检（ |
| 反推出图 prompt，喂回 |
四个都免登录、零成本、不联网（本地 Qwen3-VL）；需要 Apple Silicon。
contrast 组 —— 对比度门禁（3）
工具 | 干什么 |
| 静态查色值达不达标（读项目的 |
| 在项目里生成一份配置模板（第一次用要先跑这个） |
| 渲染后量实际字号 / 灰阶 / 动效，可存基线与基线对比（需要浏览器） |
check 查「对不对」，measure 查「多少」——丑的每一处单看往往都『对』，所以两个都要跑。
不达标时工具会照常把完整报告交回来（CLI 用退出码当判据，不是调用失败）。
facet 组 —— Markdown 排版成成品（2）
工具 | 干什么 |
| 列可用排版模板名（ |
| 把 Markdown 排成 PDF / 长图 / 讲稿页 |
reel 组 —— 竖版短视频合成（3）
工具 | 干什么 |
| 列可用版式模板名（ |
| 列配乐库：别名、时长、风格、授权 |
| 素材图 + 逐句文案 → mp4（模板 / 转场 / 配乐 / 标题 / 可选配音） |
素材与文案按顺序一一对应，数量不等时取较少的一方并明确报出来，不会静默丢弃。
不给 voice 时镜头时长由 perShot 决定（不需要任何模型）；给了才走本地 Qwen3-TTS。
硬依赖系统里的 ffmpeg（不在 npm 包里）。
museav 出的是原料（图、无声片），reel 出的是能发的成品 —— 这两段是一条业务线的前后半截。
browser 组 —— 浏览器操控（13）
工具 | 干什么 |
| 打开网页建立会话 / 用完关闭（ |
| 提取可交互元素并编号（ |
| 点击 / 输入 / 按键 / 滚动 |
| 截图当前视口，返回路径 |
| 在页面里执行 JS —— 读正文/结构化数据只能靠它（snapshot 只给可交互元素） |
| 唯一状态真源：相位、在等谁、下一步做什么 |
| 人类交接协议：阻塞等人登录 → 人完成后恢复 |
| 列出所有 agent 的会话（排查「浏览器被谁占着」） |
人类交接协议是这个组的核心价值：撞到登录墙不是死路，而是一条有契约的路径 ——
status 看它在等什么 → await_human 阻塞等人（退出码 3/4 是状态不是故障，
工具会原样把「需要人类介入 / 等待超时」交回来）→ resume 继续。
身份隔离：lite-browser 的会话按 agent 隔离，而默认身份是 default。本 MCP 每次都
显式传自己的身份（默认 mcp，可用 CS_MCP_BROWSER_AGENT 改；旧名 MUSEAV_MCP_BROWSER_AGENT
仍兼容），不会跟别的 agent
抢会话——这是实测踩出来的（第一次没传，直接开在别人正在用的 default 会话上）。
刻意不暴露（是判断，不是遗漏）：exec -- <命令>（把输入变成任意 shell 命令）、
cdp（裸协议通道）、cookie export / cookie pull-system（导出/解密 Cookie = 直接交出凭据，
与 kyvault 不进公开 MCP 同一条理由）。
发 Skill 之前必读
museav_skillhub_publish 默认只预演（本地打包校验，不上传不提交），把待提交内容返回给你核对。
只有用户明确说「提交 / 确认 / submit」才带 submit=true —— 提交不可逆，Skill ID 是
平台主键、跨版本不可改名。
真提交前会先查登录态。未登录时 MCP 不会挂在那儿等你：二维码要等进程结束才能
返回给用户，硬等就是死锁，所以会直接报错，让你引导用户去终端跑一次
museav skillhub login 扫码。
CLI 自带平台资产护栏：Skill 正文里抄了 MUSE AV 平台公共模板的提示词会被拒绝发布，
只引用模板 slug（museav gen --template xxx）则放行——搬运是重新分发资产，引用是正常集成。
被拒时按提示把正文换成调用方式。
两个「先查再调」
museav_gen_background 的 template / skill 是必填二选一，但 id 和 slug 只能从中台实时拉：
先用 museav_list_templates / museav_list_skills 查真实清单，再传进去。凭印象编一个，中台只会报
「模板不存在」，Agent 分不清是自己拼错了还是真没有。
模板自带哪些占位符看清单里「字段:」那一列，取值用 museav_gen_background 的 fields 传
（JSON 对象字符串）。
facet_build 的 template 同理 —— 先用 facet_templates 拿清单。
前置条件
npm i -g museav-cli # museav 组：出图 / 后期 / 素材 / SkillHub（需要 >= 3.9.0）
pipx install git+https://github.com/webkubor/mlx-vlm-kit.git # vlm 组
npm i -g contrast-guard # contrast 组
npm i -g github:webkubor/facet # facet 组（git 分发，不在 npm 上更新）
npm i -g github:webkubor/reel-kit # reel 组（git 分发；另外要 brew install ffmpeg）
curl -fsSL https://raw.githubusercontent.com/webkubor/lite-browser/main/install.sh | bash # browser 组装哪几个由你决定 —— 没装的组就是不会注册，不会报错。
museav_gen_background 还需要中台 apiKey（按 museav-cli 的说明配置）。
本地工具首次运行会下载对应模型（抠图 ~214MB、超分 ~65MB、去水印 ~200MB、
vlm 的 Qwen3-VL-4B 约 2.9GB）。
可执行文件不在全局 PATH 时，用环境变量指定绝对路径：
MUSEAV_BIN、MLX_VLM_BIN、CONTRAST_GUARD_BIN、FACET_BIN。
接到 Agent 上
下面三段的
command都是装好的那个二进制（cs-mcp）。如果它不在 PATH 里， 就写绝对路径 —— 装完cs-mcp --version会告诉你装在哪。
Claude Code 一行：
claude mcp add cs -- cs-mcpDSH 在 profile 的 cordis.patch.yml 里加一行：
- id: mcp-cs
name: '@deepseek-ai/dsh-mcp-client'
config:
serverName: cs
transport: stdio
command: cs-mcp
args: []
serverName决定客户端里的工具命名空间：cs让工具叫mcp__cs__museav_gen_background。 3.0.0 之前是museav，于是加了museav_前缀后会变成mcp__museav__museav_gen_background这种双重前缀 —— 所以这次一并改成了cs。 DSH 与 WorkBuddy 是 GUI 工具、不是 Agent（见cs rule agent_governance的 gui-not-agent 红线）， 这份配置是修工具本身，不是给它派活。
或手写配置（任意支持 MCP 的客户端）：
{
"mcpServers": {
"cs": {
"command": "cs-mcp",
"args": []
}
}
}想让某个没装 CLI 的分组也出现在工具列表里（调用时才报装什么），加上 env：
{
"mcpServers": {
"cs": {
"command": "cs-mcp",
"args": [],
"env": { "CS_MCP_GROUPS": "all" }
}
}
}本机微信读取：wechat（Mac 专用）
本组包装 wx-cli 的六个本地命令：wechat_status、
wechat_decrypt、wechat_sessions、wechat_contacts、wechat_messages、wechat_search。
把 wx-cli 安装在运行 cs-mcp 的那台 Mac 的 PATH 上，分组就会自动出现。
Agent 只读到同一台 Mac 的微信库，跨机器的 MCP 客户端如果在各自机器启动 cs-mcp，
读到的也是各自机器的库；不会把 owner 的微信数据从 Mac 传到服务器。
首次使用先调用 wechat_status。CLI 需要数据库密钥；上游的 wx-cli key extract
要求关闭 macOS SIP 并重启微信，这是 owner 本人的系统设置选择，本 MCP 不提供该操作。
有密钥后调用 wechat_decrypt 生成本地缓存，再用其他四个工具查。所有查询结果
都是真实私人聊天内容；wechat_search 不套用 wx-cli 的联系人隐藏规则，
可能搜到隐藏联系人，使用时要留意。
本机 Hermes 也可直接挂同一份 cs-mcp，~/.hermes/config.yaml 的 mcp_servers 下增加：
cs:
command: node
args:
- /绝对路径/cs-mcp/dist/index.js配置改完后重启 Hermes 会话，再用 groups_list / wechat_status 验证。
本地开发（改这个仓库时）
pnpm install && pnpm build # 产物在 dist/，package.json 的 bin 指向它配置里把 command 换成 node、args 指向 /绝对路径/cs-mcp/dist/index.js 即可。
还没进来的项目（以及为什么）
这张版图是逐步长出来的，不是一次列全。没进来分三种情况，都不是「忘了」：
项目 | 为什么还没进 |
密钥库， | |
工具面很清晰，但环境门槛高（本地 TTS 模型约 2.9GB），适合作为可选重型组后续加入 | |
能力好，目前以仓内脚本 / Agent Skill 为主，待发布独立 CLI 包后接入 | |
| 纯库，没有独立的命令行工具面 —— 要进得先给它们写一个 CLI |
想加一组？ 三步：给那个项目确认 CLI 能装、在 src/clis.ts 加一份 CliSpec、
在 src/groups/ 加一个分组文件并挂到 src/registry.ts 的 GROUPS。
MCP 侧不写任何业务逻辑。
验证
node test-mcp.mjs # 起 server 跑 initialize + tools/list
# 断言：55 个工具；每个名字以所属分组 id 开头；旧变量名仍生效CS_MCP_GROUPS=all 是测试用的启动方式 —— CI 机器上什么 CLI 都没装，
走默认的探测策略会一组都不启用，那就测不到工具集本身了。旧名 MUSEAV_MCP_GROUPS
会被再起一次 server 验证，确认与新名等价（改名的静默降级只在这条路上暴露）。
说明
museav_gen_background 的 prompt / skill / template 三者必须且只能提供一个：prompt 是直接给提示词，skill 和 template 是让中台在服务端展开提示词（配合 input 传一句业务描述）。
四个本地后期工具的 out 已存在时，CLI 会拒绝覆盖 —— 这是防手滑的语义，MCP 保留它：
要覆盖就显式传 overwrite: true，否则报错原文会回到 Agent 手里。
museav_list_templates / museav_list_skills 取的是 CLI 的人类可读表格（stderr），因为 stdout 只有裸 id；
museav_list_jobs 取 stdout 的完整 JSON（含 cdn_url / status / error）。清单超过 8000 字会截断，
并附一句「输出已截断」——不附的话 Agent 会把截断处当成清单结尾。
本地工具的超时上限是 10 分钟 —— 超分和 LaMa 修复在大图上确实会慢。
License
MIT
Available Tools
4 toolsgroups_listA
列出这个 MCP 的全部能力分组：哪些已启用（各几个工具）、哪些因为没装 CLI 而没启用、以及每个分组对应哪个开源项目和怎么装。工具列表里没有的能力，先查这里再让用户装。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/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 full burden. It discloses the returned categories (enabled/disabled groups, tool counts, project mapping, installation instructions) and clarifies that it reports rather than installs ('再让用户装'), but it does not explicitly state read-only/no-side-effect behavior or exact output format.
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 and front-loaded with the primary action '列出这个 MCP 的全部能力分组'. Every clause adds useful scope or action guidance, with no redundant restatement of the tool name.
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 zero-parameter discovery tool with no output schema, the description explains what information is returned and how to act on missing capabilities. It does not specify exact output structure, but it is sufficiently complete for an agent to select and invoke it correctly.
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 tool has zero parameters, so the baseline is 4. The schema is empty and fully described, and the description appropriately does not invent parameter semantics.
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 uses a specific verb ('列出') and resource ('能力分组') and details the exact scope: enabled groups with tool counts, disabled groups due to missing CLI, corresponding open-source projects, and installation guidance. It is clearly distinct from the writing-focused sibling tools and serves as a meta-discovery tool when capabilities are absent.
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 tells the agent when to use it: '工具列表里没有的能力，先查这里再让用户装', which is a clear context trigger. It does not explicitly state when not to use it, such as preferring direct sibling tools when a capability is already available, so it falls 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.
writing_composeB
基于 5D 原子表达组合矩阵（谁×在哪×为什么说×口吻），生成高信噪比、零 AI 假人味的提示词约束或内容骨架。
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | 口吻调性：粗粝真实(T1) / 克制留白(T2) / 热烈唠嗑(T3) / 严谨平视(T4)，默认粗粝真实 | |
| topic | Yes | 要表达的核心事实、成果或问题背景 | |
| persona | Yes | 角色原型：极客开发者(P1) / 生活观察者(P2) / 美学创作者(P3) / 开源协作者(P4) / 服务接待人(P5) / 架构师(P6) | |
| platform | Yes | 发布场域：网易云(M1) / 小红书(M2) / Twitter(M3) / GitHub(M4) / 公众号(M5) / Reddit(M6) / 掘金(M7) | |
| scenario | Yes | 场景意图：新工具发布(S1) / 客诉承接(S2) / 日常琐碎(S3) / 技术复盘(S4) / 事故通报(S6) / 架构RFC(S7) / 对上汇报(S8) |
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. It mentions the internal matrix method and a quality goal (“高信噪比、零 AI 假人味”), but it does not describe the output format, determinism, side effects, or any operational constraints.
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 definition is a single dense sentence with no wasted text. It is compact, though the method is front-loaded before the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves key gaps: return shape, output format, and when to choose this tool over siblings are all missing. It names output types but does not make the tool fully callable from context alone.
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 100%, and the description adds conceptual meaning by mapping persona/platform/scenario/tone to “谁×在哪×为什么说×口吻”. It does not explain the required topic parameter, but it still adds useful semantic framing beyond the schema.
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 states a specific verb (“生成”) and resource (“提示词约束或内容骨架”) and names the 5D matrix method. It is clear enough to distinguish from a lint or rubric tool, but it does not explicitly contrast itself with the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no explicit guidance on when to use this tool versus writing_lint, writing_rubric, or groups_list. The usage context must be inferred from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing_lintA
静态扫描 Markdown 文本或文件，机械拦截假人过渡词（总的来说/毋庸置疑）、机械排比（不仅...更是...）、高中作文腔（犹如一幅画卷/宛如晨曦）与空洞正能量结尾。返回违规行号与修改建议。零外部依赖。
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | 要检查的本地 Markdown 文件绝对路径（text 与 path 二选一） | |
| text | No | 要检查的 Markdown 文本内容（text 与 path 二选一） |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that scanning is static, returns violation line numbers and suggestions, and has zero external dependencies, but it does not explicitly confirm read-only behavior, file-access requirements, or error handling.
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 and front-loaded: it states the scan target, lists concrete pattern examples, then gives return behavior and dependency note. Every sentence adds useful signal without repetition.
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 two-parameter, no-output-schema tool, the description is largely complete: it covers purpose, checks, return values, and dependency posture. It could be stronger with explicit read-only confirmation and sibling differentiation, but the core calling information is present.
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 schema already explains that path and text are mutually exclusive alternatives. The description echoes 'Markdown text or file' but adds no syntax, format, or conflict-resolution detail beyond the schema.
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/resource: statically scan Markdown text or files for defined stylistic anti-patterns. It is highly clear about what the tool catches, but it does not explicitly differentiate itself from siblings like writing_rubric or writing_compose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The checks listed imply the use case—linting draft prose for clichés—but the description gives no explicit when-to-use guidance, prerequisites, or alternatives. The agent can infer usage from the pattern list, but routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing_rubricA
获取指定平台（小红书 / Twitter / Reddit / 掘金）的说说型发帖扣分清单（Rubric）与致命反模式。发布前逐条对照，每项扣 20 分，低于 80 分不得发布。
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | 目标平台：xiaohongshu(小红书) | twitter(X) | reddit | juejin(掘金) | all(全部平台) |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses what is returned (rubric plus fatal anti-patterns) and how scoring works (each issue deducts 20 points, below 80 means do not publish), which is useful decision context, though it does not state read-only status or authorization requirements.
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 concise sentences, front-loaded with the retrieval purpose and followed by the operational rule. There is no unnecessary wording.
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 simple one-parameter tool with no output schema, the description sufficiently explains what is returned and the scoring threshold. It could be slightly more explicit about response structure, but an agent has enough to select and invoke it correctly.
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% and the single enum parameter is fully documented in the schema. The description lists most platforms but adds no syntax or selection meaning beyond the schema, so baseline 3 is appropriate.
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 states a specific verb and resource: retrieve the writing rubric (扣分清单) and fatal anti-patterns for a specified platform. It is clearly a rubric-fetching tool, not a linter or composer, though it does not explicitly name sibling tools.
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 a clear usage context: check item by item before publishing, and do not publish if the score is below 80. It does not explicitly mention alternatives such as writing_lint, but the pre-publication context is concrete.
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.
9 tool updates
v3.2.0- Removed
compress_image - Removed
gen_background - Added
groups_list - Removed
remove_bg - Removed
remove_watermark - Removed
upscale_image - Added
writing_compose - Added
writing_lint - Added
writing_rubric
5 tool updates
v1.0.0- First observed
compress_image - First observed
gen_background - First observed
remove_bg - First observed
remove_watermark - First observed
upscale_image
TDQS
A3.6/5.0
Scored across 4 tools
Disambiguation4/5
The three writing tools split along a clear workflow: lint detects mechanical violations, rubric is a static reference of platform scoring rules, and compose generates prompt constraints. Lint vs. rubric could be momentarily confused since both are 'check my text against rules', but the descriptions frame one as automated scanning with line numbers and the other as a manual checklist. groups_list is unmistakably a meta/introspection tool.
Naming Consistency4/5
All lowercase snake_case with an action-oriented second token, so naming is readable and predictable. The three writing_* tools share a clean domain prefix, while groups_list is a noun_verb outlier that breaks the domain_action pattern.
Tool Count4/5
Four tools is lean but defensible for a focused writing-quality server: one generates, one checks, one provides reference criteria, plus a discovery tool. Nothing is redundant, though the surface is thin enough that the single meta tool feels like it belongs to a larger, uninstalled product.
Completeness3/5
The compose → lint → rubric loop is covered, but rubric is a passive reference with no tool to actually score a draft against it, and there is no update/fix operation to apply the lint suggestions. The presence of groups_list implies additional capability groups exist outside this server, so the visible surface is intentionally partial.
Maintenance
ActivityActive
ResponsivenessSyncing
Related MCP Connectors
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Generate AI images and videos from any compatible MCP client.
Create images & video from any MCP agent — 17 models, spend limits, one URL.
Create and manage AI image and video generations through Quriov's fixed public MCP tools.
Related MCP Servers
- AlicenseAqualityBmaintenanceImage tools for coding agents: generate from text, edit one reference image, remove backgrounds, upscale 2x, and create reference-based sprite animations. The MCP server, CLI and REST API share one key, credit balance and request history. Needs a DreamLayer API key and paid credits; sprite sheets are beta.777 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables MCP-capable agents to generate and edit images through Gemini or OpenAI, returning an absolute file path instead of image bytes to keep context windows clean.1MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to generate and edit images via Gemini, OpenAI, or BytePlus Seedream, with automatic prompt optimization and quality presets, saving outputs to disk and returning them as MCP resources.2,138 npmMIT