Skip to main content
Glama
LXHeart

webfetch

by LXHeart
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

hok-skin-extraction-mcp

一个基于 Model Context Protocol (MCP) 的 Node.js / TypeScript 服务器，主要提供两类能力：

  1. 通用网页抓取与内容解析（使用 webfetch MCP 服务器）

  2. 王者荣耀（pvp.qq.com）英雄皮肤大图封面查询

本项目主要用于配合 Claude Code / Claude MCP 客户端，通过 MCP 工具来抓取网页、解析正文、按 CSS 选择器抽取内容，以及根据英雄中文名获取皮肤大图封面链接（*.jpg）。

图片地址 https://pvp.qq.com/web201605/herolist.shtml

功能概览

1. 通用 Web 抓取工具

MCP 服务器名称：webfetch

注册的 MCP 工具（在 src/mcp/server.ts 中）：

  • fetch_html

    • 功能：抓取指定 URL 的原始 HTML 内容。

    • 入参：{ url: string }。

    • 返回：页面 HTML 字符串。

  • extract_readable

    • 功能：抓取页面并抽取可读正文与标题（基于 Readability）。

    • 入参：{ url: string }。

    • 返回：一段文本，格式大致为：

      标题: <title>

<contentText>

  • query_selector

    • 功能：抓取页面并按 CSS 选择器提取内容。

    • 入参：

      {
  url: string;
  selector: string;
  attribute?: string;   // 可选，要提取的属性（如 href）
  mode?: "text" | "html"; // 可选，返回文本还是 HTML
  maxResults?: number;  // 可选，最大结果条数
}

    • 返回：JSON 字符串：

      {
  "url": "...",
  "selector": "...",
  "attribute": "...",
  "values": ["..."]
}

2. 王者荣耀皮肤封面工具

  • 工具：pvp_get_skin_covers_by_name

    • 功能：根据王者荣耀英雄中文名，返回该英雄的所有皮肤名称及对应的大图封面链接（*.jpg）。

    • 数据来源：官方公开 JSON https://pvp.qq.com/zlkdatasys/heroskinlist.json。

    • 返回：Markdown 列表，每个皮肤一条：

      - **皮肤名**
  https://...

此外，项目下还定义了一个 Claude Code 技能（供你在聊天里直接使用）：

  • 技能名：get-pvp-skin-covers-by-name

  • 作用：在 Claude Code 里输入 /get-pvp-skin-covers-by-name 英雄名，就会通过 MCP 调用上面的工具，返回皮肤名称与图片 URL 列表。

Related MCP server: Fetch MCP Server

使用方式

假设你已经安装并在使用 Claude Code（CLI 或编辑器插件），并将本项目作为 MCP 服务器配置好。

1. 本地开发 / 运行 MCP 服务器

在项目根目录（hok-skin-extraction-mcp）中：

# 安装依赖
npm install

# 开发模式（使用 ts-node 跑 src/index.ts）
npm run dev

# 构建 TypeScript 到 dist/
npm run build

# 运行测试（如有）
npm test

正常情况下你不需要手动启动 MCP 服务器，Claude Code 会根据 .mcp.json 自动以 node dist/index.js 的方式启动它。npm run dev 主要用于本地调试。

2. 在 Claude Code 中使用 MCP 工具

在启用本 MCP 服务器（webfetch）之后，你可以在对话中直接让 Claude 使用这些工具，例如：

  • 抓取原始 HTML：

    “用 webfetch.fetch_html 抓取这个 URL 的 HTML：https://example.com。”

  • 抽取页面正文：

    “用 webfetch.extract_readable 帮我提取这篇文章的标题和正文：https://example.com/article。”

  • CSS 选择器提取：

    “用 webfetch.query_selector 在这个页面上选出所有文章标题链接，选择器用 .post-title a，属性取 href。”

具体参数和返回格式可以参考上面的“功能概览”。

3. 查询王者荣耀英雄皮肤封面

在 Claude Code 中启用本项目后，你有两种常用方式：

方式一：直接调用 MCP 工具

告诉 Claude 使用 MCP 工具：

“调用 webfetch.pvp_get_skin_covers_by_name，参数 heroName 为 露娜。”

Claude 会返回类似：

- **紫霞仙子**
  https://...
- **一生所爱**
  https://...
...

方式二：使用自定义技能（推荐）

在对话输入：

/get-pvp-skin-covers-by-name 露娜

Claude Code 会自动调用对应 MCP 工具，并以 Markdown 列表形式返回所有皮肤名称和大图封面 URL。

配置说明

项目根目录有一个 .mcp.json，示例：

{
  "mcpServers": {
    "webfetch": {
      "command": "node",
      "args": ["dist/index.js"],
      "cwd": "/Users/LXH/claude/websearch_mcp"
    }
  }
}

你在自己的环境中使用时，只需要把 cwd 改成你实际的项目路径即可，其余保持不变，然后在 Claude Code 的设置中启用这个 MCP 服务器。

English Overview

hok-skin-extraction-mcp is a Node.js / TypeScript implementation of a Model Context Protocol (MCP) server. It is designed to be used together with Claude Code or any MCP-capable client, and provides two main capabilities:

  1. General-purpose web fetching and content extraction (webfetch MCP server).

  2. Skins metadata and large cover images for Honor of Kings heroes (from the official pvp.qq.com data source).

This project is not a public web service. It is meant to be run as a local MCP server process that the client (e.g. Claude Code) spawns via .mcp.json.

Features

1. Web fetching tools (webfetch)

Registered MCP tools (see src/mcp/server.ts):

  • fetch_html

    • Fetches the raw HTML of a given URL.

    • Input: { url: string }.

    • Output: HTML string.

  • extract_readable

    • Fetches the page and extracts a readable article (title + main text) using Readability.

    • Input: { url: string }.

    • Output: a text block like:

      标题: <title>

<contentText>

  • query_selector

    • Fetches the page and runs a CSS selector to extract content.

    • Input:

      {
  url: string;
  selector: string;
  attribute?: string;      // optional, e.g. "href"
  mode?: "text" | "html"; // optional, text or raw HTML
  maxResults?: number;     // optional, max number of results
}

    • Output: JSON string:

      {
  "url": "...",
  "selector": "...",
  "attribute": "...",
  "values": ["..."]
}

2. Honor of Kings skins tool

  • Tool: pvp_get_skin_covers_by_name

    • Looks up all skins for a given hero (Chinese name) and returns the skin name plus large cover image URLs (*.jpg).

    • Data source: official public JSON https://pvp.qq.com/zlkdatasys/heroskinlist.json.

    • Output: Markdown list, one bullet per skin:

      - **Skin name**
  https://...

There is also a convenience skill defined for Claude Code:

  • Skill name: get-pvp-skin-covers-by-name

  • Usage: in a Claude Code chat, type /get-pvp-skin-covers-by-name 英雄名 to get a Markdown list of skin names and image URLs via the MCP tool above.

How to run locally

From the project root:

# Install dependencies
npm install

# Development (run src/index.ts via ts-node)
npm run dev

# Build TypeScript to dist/
npm run build

# Run tests (if any)
npm test

In normal usage you do not start the MCP server manually; Claude Code will spawn it based on .mcp.json using node dist/index.js. The dev script is mainly for debugging.

MCP configuration

At the project root there is an .mcp.json similar to:

{
  "mcpServers": {
    "webfetch": {
      "command": "node",
      "args": ["dist/index.js"],
      "cwd": "/Users/LXH/claude/websearch_mcp"
    }
  }
}

When using this project in your own environment, change cwd to your actual project path, then enable the webfetch MCP server in your Claude Code settings.

Using the tools from Claude Code

Once the MCP server is enabled:

  • Fetch raw HTML

    • “Use webfetch.fetch_html on https://example.com.”

  • Extract article content

    • “Use webfetch.extract_readable on https://example.com/article to get the title and main text.”

  • Extract with CSS selectors

    • “Use webfetch.query_selector on this page with selector .post-title a and attribute href to list all article links.”

For Honor of Kings skins:

  • Call the MCP tool directly:

    • “Call webfetch.pvp_get_skin_covers_by_name with heroName = 露娜.”

  • Or use the custom skill (recommended):

    • /get-pvp-skin-covers-by-name 露娜

Notes

  • Do not put private cookies or tokens directly into MCP tool parameters. This project does not log sensitive headers, but you should still treat credentials carefully.

  • For login-protected or intranet pages, the fetcher may fail (e.g. due to redirects). In that case, consider exporting the HTML and letting Claude analyze the file instead.

  • The Honor of Kings skin parser depends on the public JSON structure; if the upstream format changes, the parsing logic in this project may need to be updated.

Available Tools

4 tools
extract_readableB

抓取页面并抽取可读正文与标题

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes要抓取的 http(s) URL

TDQS

B3.4/5.0
Behavior2/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 of behavioral disclosure. It only restates the core action and output but does not mention behavior for failed fetches, redirects, JavaScript-rendered pages, rate limits, or what happens when no readable content is found.

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 a single compact sentence with the action front-loaded and no filler or repetition. Every word contributes meaning, making it easy to parse quickly.

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 conveys the essential contract: given a URL, return the readable body text and title. It is slightly thin on corner cases like timeout or blocked pages, but given the low complexity, this is adequate for an agent to use it correctly in most situations.

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 single url parameter is already fully documented in the schema. The tool description adds no additional parameter semantics, but the baseline of 3 applies because the schema handles the load.

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 clearly states the action ('抓取页面并抽取') and the specific output ('可读正文与标题'), distinguishing it from the sibling tool fetch_html, which would return raw page structure, and query_selector, which extracts arbitrary elements. Even without naming siblings, the purpose is unambiguous and specific.

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?

The description gives no guidance on when to use this tool versus the related tools fetch_html or query_selector. An agent must infer that this is the right choice for clean article text, but no explicit 'use this when...' or exclusion criteria are provided.

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

fetch_htmlA

抓取指定 URL 的原始 HTML 内容

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes要抓取的 http(s) URL

TDQS

A3.8/5.0
Behavior3/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 does communicate that the output is the raw HTML content, which is useful, but it does not mention potential network errors, encoding, redirects, rate limits, or whether the fetch is read-only. These are gaps, though the operation is a simple read-oriented fetch.

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 a single, focused sentence with no redundant words. It front-loads the essential action and result, making it easy for an agent to parse quickly.

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 one-parameter tool with no output schema, the description is nearly complete: it identifies the input and the returned content. It could be slightly stronger with explicit guidance on choosing this tool over extract_readable, but the current wording already conveys the main distinction through 'raw HTML'.

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%, as the single 'url' parameter has a clear description. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly states the action ('抓取'/fetch), the target (specified URL), and the result (raw HTML content). This distinguishes it from siblings like extract_readable, which would produce processed/readable content rather than raw HTML.

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 word '原始' (raw) implies this tool is for obtaining unprocessed HTML source rather than parsed or extracted content, but the description does not explicitly mention alternatives or specify when to choose this tool over extract_readable or query_selector. Usage context is only implied, not stated.

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

pvp_get_skin_covers_by_nameA

根据王者荣耀英雄中文名获取该英雄的皮肤大图封面链接（custom_wzry_A1/*.jpg），包括原始皮肤在内，并以 Markdown 格式展示皮肤名称和图片 URL

ParametersJSON Schema
NameRequiredDescriptionDefault
heroNameYes英雄中文名称，例如 孙权、张良

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add genuine value by revealing the output format (Markdown), the content scope (includes the original skin), and the storage path pattern (custom_wzry_A1/*.jpg). It does not, however, describe edge-case behavior such as misspelled or unknown hero names, empty results, or any error conditions, so the behavioral picture is incomplete but not misleading.

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?

A single, dense sentence that front-loads the purpose and packs in the input, the output, the scope qualifier (original skin included), and the display format. Every clause earns its place; there is zero filler or redundant restating 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 simple one-parameter tool with no output schema and no annotations, the description covers the essential calling contract: what to pass (hero Chinese name), what comes back (skin covers as Markdown with names and URLs), and a distinguishing detail (path pattern, original skin included). The only notable gap is error/not-found behavior, which is minor for a read-style lookup tool but would round it out.

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% — the heroName parameter is already documented in the schema with its type, requirement, and examples (孙权、张良). The description's phrase '根据...英雄中文名' merely reinforces that the name must be Chinese, adding no new semantic information beyond the schema. Baseline 3 applies because the schema already does the heavy lifting.

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 states a specific verb (获取/get), a precise resource (skin cover images for a named Honor of Kings hero), and the output form (Markdown list of skin names and URLs). It also names the scope explicitly — 'including the original skin' — and the URL pattern, which clearly distinguishes it from the generic HTML-utility siblings (fetch_html, extract_readable, query_selector).

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?

Usage is implied rather than stated: an agent can infer 'call this when you have a hero's Chinese name and need their skin cover links' from the description's verb and resource. However, there is no explicit when-to-use vs. when-not-to-use guidance, no stated preconditions, and no mention of what to do if the hero name is unknown.

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

query_selectorB

抓取页面并按 CSS 选择器提取内容

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
modeNotext
selectorYes
attributeNo可选：要提取的属性（如 href）
maxResultsNo最大返回条数

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says it fetches and extracts. It does not mention output format, pagination/truncation, error behavior, JavaScript rendering, or authentication needs.

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?

A single, front-loaded Chinese sentence with no filler. Every word contributes to the core meaning of fetching and selector-based extraction.

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?

Given five parameters, no output schema, and no annotations, this description is too thin for reliable invocation. An agent cannot infer return shape, how maxResults applies, or whether it returns matching HTML or text.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40%, and the description adds little beyond restating the CSS-selector concept. It does not clarify url, mode, attribute, or maxResults beyond what the schema already 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?

The description states a clear operation: fetch a page and extract content by CSS selector. This distinctive mechanism separates it from the sibling tools fetch_html and extract_readable, making the tool's role evident.

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 description implies usage when a specific page element needs to be extracted via a CSS selector, but it gives no explicit conditions, exclusions, or guidance on choosing between this and the sibling tools.

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.

  1. 4 tool updatesv0.1.0
    • First observedextract_readable
    • First observedfetch_html
    • First observedpvp_get_skin_covers_by_name
    • First observedquery_selector
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation4/5

The three fetching tools are clearly differentiated by their outputs: raw HTML, readable text, and CSS-selected content. The pvp skin tool is unrelated and therefore not easily confused with the other tools.

Naming Consistency3/5

Most tools follow a concise verb_noun pattern like fetch_html and extract_readable, but pvp_get_skin_covers_by_name introduces a domain prefix and a much longer, qualifier-heavy name. This breaks the otherwise consistent naming style.

Tool Count3/5

Four tools is a reasonable number for a small utility server, but the pvp skin tool does not fit the webfetch domain. The count is not excessive, yet the set is not well-scoped because one tool feels out of place.

Completeness3/5

The webfetch tools cover the main web extraction needs: raw HTML, readable content, and CSS-selected extraction. However, the unrelated pvp tool is an isolated feature with no supporting operations, and common web utilities like screenshots or header inspection are absent.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Fetch MCP Server

    phpmac
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides functionality to fetch and transform web content in various formats (HTML, JSON, plain text, and Markdown) through simple API calls.
    73,147 npm
    1
    MIT

  • Fetch MCP Server

    SolonaBot
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables fetching and converting web content into various formats including HTML, JSON, plain text, and Markdown. It supports custom request headers and provides specialized tools for on-demand web data retrieval and transformation.
    73,147 npm
    MIT