Click on "Install 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., "@FishClaw MCP Search for used mechanical keyboards on Xianyu and summarize the prices."
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.
有兴趣可以看一下Agno智能体调用FishClaw工具链接
警告：本项目仅供学习交流使用，请勿用于任何商业或非法用途，否则后果自负。
本项目仅供学习交流使用，请勿用于任何商业或非法用途。任何违反法律法规、侵犯他人合法权益的行为，均与本项目及其开发者无关，后果由用户自行承担。
下载、保存或使用本项目源代码，即表示您已阅读并同意本声明的全部内容。
Related MCP server: Xiaohongshu MCP Python
工具 | 说明 | 注意 |
| 检查登录状态；未登录则弹出浏览器等待扫码 | |
| 关键词搜索闲鱼商品，采集标题、价格、链接 | |
| 填写商品草稿（图片/描述/分类/价格）并截图 | |
| 点击发布按钮完成商品发布 | ⚠️ 不可撤销 |
| 获取所有在售商品列表 | |
| 对指定商品执行下架或永久删除 | ⚠️ 不可撤销 |
| 读取当前浏览器页面可见文字 | |
| 模拟真人随机浏览养号 | 需 |
| 调用 DashScope 生成商品封面图 | |
| 根据技术主题生成科技感英文生图提示词 | |
| 根据技术主题生成闲鱼商品描述文案 |
git clone https://github.com/your-username/fishclaw-mcp.git
cd fishclaw-mcp# 推荐使用 uv
uv sync
# 或使用 pip
pip install -e .playwright install chromiumcp .env.example .env编辑 .env，至少填写 AGENT_LLM_API_KEY：
# 必填：用于 LLM 推理和文案生成
AGENT_LLM_API_KEY=your-dashscope-api-key
# 可选：用于生成商品封面图（不填则使用内置默认图片）
IMAGE_API_KEY=your-dashscope-api-keypython server.py看到 Starting MCP server 字样即表示启动成功，Ctrl+C 退出。
找到配置文件（macOS: ~/Library/Application Support/Claude/claude_desktop_config.json，Windows: %APPDATA%\Claude\claude_desktop_config.json），添加以下内容：
推荐方式：python 直接运行
{
"mcpServers": {
"fishclaw": {
"command": "python",
"args": ["D:/acode/py/study/FishClaw_MCP/server.py"],
"env": {
"AGENT_LLM_API_KEY": "your-dashscope-api-key"
}
}
}
}或使用 uv
{
"mcpServers": {
"fishclaw": {
"command": "uv",
"args": ["--directory", "/your/path/to/fishclaw-mcp", "run", "server.py"]
}
}
}将路径替换为本项目的实际绝对路径。环境变量也可以在
.env文件中配置。
在 ~/.cursor/mcp.json（或项目级 .cursor/mcp.json）中添加同上的配置。
接入后，在对话中直接用自然语言操作即可：
帮我发布一个 Python 爬虫技术服务，价格 99 元
→ 自动生成封面图 → 生成文案 → 填写表单 → 截图确认 → 发布
查看我现在在售的商品
→ 跳转个人中心，列出所有在售商品
把第二个商品下架
→ 进入商品详情，点击下架并确认
搜索 Python 教程，看看竞品定价
→ 采集前 20 条结果的标题和价格fishclaw-mcp/
├── server.py # MCP 服务器入口（使用 FastMCP）
├── pyproject.toml # 项目依赖
├── .env.example # 环境变量模板
├── assets/
│ └── default_agent.png # 生图 API 不可用时的兜底图片
└── tools/
├── xianyu_tools.py # 闲鱼 Playwright 自动化（纯 Python 类）
├── generate_image_tools.py # DashScope 图像生成（纯 Python 类）
├── prompt_tools.py # LLM 提示词与文案生成（纯 Python 类）
└── xconfig.py # 日志配置变量 | 必填 | 默认值 | 说明 |
| 是 | — | 阿里云 DashScope API Key |
| 否 |
| 推理模型名称 |
| 否 | DashScope 兼容地址 | LLM 接口地址 |
| 否 |
| 推理温度 |
| 否 | — | 图像生成 API Key（不填用默认图片） |
| 否 |
| 是否无头模式（建议保持 false 降低风控） |
| 否 | — | 代理地址，如 |
| 否 |
| Cookie 持久化路径 |
| 否 |
| 闲鱼首页地址 |
| 否 |
| 设为 |
层次 | 技术 |
MCP 协议 | MCP Python SDK — FastMCP |
浏览器自动化 | Playwright + playwright-stealth |
工具实现 | 纯 Python 类，不依赖任何 Agent 框架 |
LLM / 图像生成 | 阿里云 DashScope（ |
在闲鱼发布页面填写商品草稿（图片、描述、分类、价格），填写完成后自动截图。 返回文本中包含截图路径，确认无误后调用 publish_item 正式发布。
Args: image: 商品图片，支持本地绝对路径或网络 URL（http/https）。 description: 商品描述文字。 price: 商品售价（元），默认 100.0。
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| description | Yes | ||
| price | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes write operations (creating a draft and taking a screenshot) while the annotation readOnlyHint is true, creating a direct contradiction. This significantly undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded, but the mixed language (Chinese and English) and lack of strict formatting slightly reduce clarity. Nonetheless, it conveys essential information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description covers the return value (screenshot path) well. It explains the auto-screenshot behavior, which is key. Minor gaps include lack of error handling details, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides valuable semantics for all three parameters: image (local path or URL), description (text), and price (default 100). This goes beyond the schema's bare fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fills a draft on Xianyu with fields including image, description, and price, and then takes a screenshot. It also references the sibling publish_item for formal release, distinguishing its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to confirm the draft and then call publish_item for formal release, providing clear usage context. However, it does not mention scenarios where drafting is inappropriate or alternatives like manage_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据文本提示词调用阿里云 DashScope 生成图像，图像缓存到本地后返回路径。 未配置 IMAGE_API_KEY 时自动回退到项目内置的默认图片。
Args: prompt: 图像生成的文本描述（支持中英文混合）。 size: 图像尺寸，格式为"宽高"，如"11201440"，默认"1024*1024"。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| size | No | 1024*1024 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the use of DashScope, local caching, path return, and fallback to a default image, providing decent behavioral context. However, it omits error handling, exact return format, and authentication details beyond API key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences for behavior and a clear args section. Every sentence adds value, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown), the description covers parameters, caching, and fallback. It lacks error handling or rate limits but is largely complete for a straightforward image generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains 'prompt' supports mixed Chinese/English, and 'size' provides format, example, and default. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates images from text prompts via Alibaba Cloud DashScope, caches locally, and returns a path. It differentiates from the sibling 'generate_image_prompt' by focusing on image generation rather than prompt creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions fallback behavior when API key is missing, implying a condition for use, but does not explicitly compare to alternative tools or state when to prefer this over siblings like 'generate_image_prompt'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据技术主题生成适合图像生成模型的英文提示词（赛博朋克/科技感风格）。 生成结果可直接传入 generate_image 工具使用。
Args: topic: 技术主题，如"AIGC"、"Python爬虫"、"区块链"等。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds that output is ready for generate_image, indicating non-destructive generation. No contradictions. Adds useful style and compatibility context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first explains purpose and output usage, second explains parameter. No wasted words, well-organized, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one param. Description covers purpose, parameter, and output usage. Output schema exists, so return format need not be detailed. Adequate for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'topic' has 0% schema description coverage. Description compensates by explaining topic as technical subject and providing examples (AIGC, Python爬虫, etc.), adding significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates English image prompts for tech topics in cyberpunk/tech style, and specifies output can be directly used with sibling generate_image tool. Differentiates from generate_image (image generation) and other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating prompts to feed into generate_image, but lacks explicit when-not-to-use or mention of alternatives. Clear enough for typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据技术主题生成闲鱼商品描述文案（自我介绍 + 服务分类 + 技术关键词三段式）。 生成结果可直接传入 draft_item 的 description 参数。
Args: topic: 技术主题或服务内容，如"AIGC绘画"、"Python爬虫"等。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates no side effects. The description adds that the tool generates text output but does not disclose behavioral traits like error handling, rate limits, or output format beyond the mention of 'three-part format'. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an Args line. It front-loads the purpose and usage. However, it lacks headings or formatted separation, and is provided only in Chinese. Still, no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema exists), the description covers the input meaning and intended next step (draft_item). It does not explain edge cases or full output behavior, but with the output schema available, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides a meaningful explanation for the 'topic' parameter: it specifies it as a 'technical topic or service content' and gives examples like 'AIGC drawing' and 'Python crawler'. This compensates for the schema gap and adds practical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates a Xianyu product description based on a technical topic, and specifies the three-part format (self-introduction, service category, technical keywords). It also indicates the output can be used directly in draft_item's description parameter. While it doesn't explicitly distinguish from sibling tools, the purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before draft_item but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when-not to use, or comparison with siblings like get_selling_items or manage_item. Users must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取当前浏览器页面的可见文字内容（最多 3000 字符），供分析页面状态或提取信息。 可在导航到某个页面后调用，让 AI 感知当前浏览器状态。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the 3000-character limit, offering valuable behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains the action and limit, second provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 tool is simple, the description covers purpose, constraints, and usage scenario completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage, the description need not add parameter details. The baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads visible text content from the current browser page with a 3000-character limit, distinguishing it from sibling tools like restart_browser or search_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests calling after navigation, providing clear context. It lacks explicit exclusions or alternatives, but sibling tools are sufficiently different to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前账号所有在售商品列表（标题、价格、链接）。 内部自动跳转个人中心并滚动加载全部商品，无需手动导航。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond readOnlyHint by disclosing that the tool automatically navigates to the personal center and scrolls to load all items, which is valuable behavioral context. It does not contradict annotations and provides actionable information about side effects like automated scrolling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the core purpose followed by a behavioral note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple read operation, the description is fully complete. It specifies the output fields (title, price, link), indicates it's for the current account, and explains the automatic behavior. The presence of an output schema (not shown) further reduces the need for description details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter information. Baseline score of 4 is appropriate as there is nothing more to clarify about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the list of all currently selling items for the current account, including title, price, and link. It distinguishes itself from sibling tools like 'search_market' or 'manage_item' by focusing on the 'selling items' list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to get selling items) but does not explicitly contrast with alternatives like 'search_market' or give when-not-to-use guidance. It mentions automatic navigation as a convenience, which hints at its purpose but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查闲鱼登录状态。已登录则直接返回；未登录则打开浏览器展示二维码， 等待用户手动扫码，登录成功后自动保存 Cookies。
Args: timeout_seconds: 等待扫码的最大秒数，默认 180。
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description clearly discloses the tool's behavior: checking status, opening browser, waiting for scan, saving cookies. It accurately describes the login process without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for behavior and one line for args. Every sentence adds value, and the structure is clear with a heading-like 'Args:' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is an output schema, the description does not mention return values. However, for a login tool, the behavior is sufficiently described. It could be slightly more complete by stating what the function returns (e.g., success status).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the only parameter (timeout_seconds) with its purpose and default, adding value beyond the schema which only provides type and default. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking login status and initiating login if needed. It mentions opening a browser for QR scanning and auto-saving cookies, which is specific and distinguishes it from sibling tools that handle other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before other tools that require authentication, but it does not explicitly state 'use this first' or provide when-not-to-use conditions. The single mention of a default timeout offers basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对指定商品执行下架或删除操作，内部自动跳转商品详情页并处理确认弹窗。 ⚠️ delete 操作永久删除商品，不可恢复。 请先调用 get_selling_items 获取商品链接，再传入此工具。
Args: item_url: 商品详情页 URL（从 get_selling_items 结果中获取）。 action: delist=下架（转为草稿，可重新上架）；delete=永久删除。
| Name | Required | Description | Default |
|---|---|---|---|
| item_url | Yes | ||
| action | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the destructiveHint annotation: it notes that delete is irreversible while delist is reversible (turns to draft). There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear but slightly verbose with emoji and two languages. The Args section is well-structured, and every sentence adds value, though it could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required params, output schema exists), the description covers prerequisites, action effects, and internal behavior. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains that item_url comes from get_selling_items and defines each action enum value. This adds critical meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool delists or deletes items, specifying the two actions and their effects. It distinguishes itself from sibling tools like draft_item and publish_item by focusing on removal operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call get_selling_items first to obtain the item_url, explains when to use delist vs delete, and warns that delete is permanent. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
点击发布按钮完成商品发布。 ⚠️ 不可撤销操作，请先调用 draft_item 填写草稿并确认截图后再调用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint true; description reinforces this by marking the operation as irreversible and adds the critical context that draft_item must be called first, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description is concise, with a prominent warning and clear instruction, earning its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, destructive behavior annotated, and sibling relationship clarified, the description is fully adequate for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema; baseline score of 4 applies as there is no need for additional parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool completes product release (完成商品发布), distinguishing it from sibling draft_item by specifying the prerequisite workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns that the operation is irreversible and instructs to call draft_item first and confirm screenshots before use, providing clear when-to-use and precondition guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
重新初始化 Playwright 浏览器进程，无需重启 MCP 服务器。 当出现以下情况时调用：
浏览器窗口已被手动关闭
页面长时间无响应或报错
提示"浏览器进程已关闭"等异常 重启后需重新调用 login 验证登录状态，再继续执行后续操作。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 that the browser restarts and session state is lost by requiring login re-validation. It could mention that open tabs or in-progress actions are lost, but the need to re-login implies this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, uses bullet points for clarity, and front-loads the main purpose. Every sentence contributes actionable information with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no annotations, the description fully covers the tool's purpose, usage conditions, and post-invocation steps. It is complete for the tool's complexity and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. The description adds no parameter meaning because there is nothing to add. Following the rubric, 0 parameters yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reinitializes the Playwright browser process without restarting the MCP server, and distinguishes it from sibling tools that manage items, login, etc. The verb 'reinitialize' and resource 'browser process' are specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists three concrete scenarios (browser closed, page unresponsive, error message) and gives clear post-use instruction to re-call login. This provides explicit when-to-use guidance and a necessary follow-up action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在闲鱼搜索指定关键词，采集结果列表（标题、价格、链接），用于竞品调研和定价参考。
Args: keyword: 搜索关键词，不能为空。 max_results: 最多返回结果数量，默认 20。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context (reading from Xianyu, collecting results) which aligns with the readOnlyHint annotation. It does not disclose additional traits like rate limits or result ordering, but the annotation covers the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence stating purpose, followed by parameter definitions. No unnecessary words; each part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description covers purpose, parameters, and use case. Minor details like pagination or sorting are missing but not critical for a basic search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains both parameters: keyword (required, non-empty) and max_results (default 20). This provides necessary semantics beyond the schema, though could include range or units for max_results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: search for keywords on Xianyu and collect results (title, price, link) for competitor research and pricing reference. It uses specific verbs and resources, and is distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usage for competitor research and pricing reference, but does not explicitly state when not to use this tool or compare with alternatives. However, given the sibling tools, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0draft_itemgenerate_imagegenerate_image_promptgenerate_product_descriptionget_page_contentget_selling_itemsloginmanage_itempublish_itemrestart_browsersearch_marketEach tool targets a distinct action or resource: login, item drafting/publishing/managing, search, page reading, image generation, etc. There is no overlap that would confuse an agent.
All tools follow a consistent verb_noun snake_case pattern (e.g., draft_item, generate_image, get_selling_items). Multi-word verbs like generate_image_prompt are uniform.
With 11 tools, the server covers the core workflow of listing items on Xianyu (including image and description generation) without excess or missing critical steps.
The tool set covers the full listing lifecycle: login, draft, publish, manage, search, and list. Minor gaps exist (no update for published items, no order management), but agents can work around them.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
MCP server for Qwen Image 3 AI image generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TnoobT/FishClaw_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
