Skip to main content
Glama
deenesjakoruzh
kwp-lab

MCP Fetch With Proxy

by kwp-lab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

MCP 获取

模型上下文协议服务器，用于使用自定义 http 代理获取 Web 内容。这使得 Claude Desktop（或任何 MCP 客户端）能够获取 Web 内容并进行适当的图像处理。

该存储库从@smithery/mcp-fetch分叉并用库node-fetch-native替换了node-fetch实现。

如果已设置http_proxy和https_proxy环境变量，服务器将默认使用这两个变量通过代理服务器路由请求。您也可以设置MCP_HTTP_PROXY环境变量来使用其他代理服务器。

可用工具

  • fetch ：从互联网检索 URL，并将其内容提取为 Markdown 文件。如果找到图像，则其 URL 将包含在响应中。

图像处理规格：

仅从文章内容中提取图像网址，并将其附加到工具结果中：

{
  "params": {
    "url": "https://www.example.com/articles/123"
  },
  "response": {
    "content": [
      {
        "type": "text",
        "text": "Contents of https://www.example.com/articles/123:\nHere is the article content\n\nImages found in article:\n- https://www.example.com/1.jpg.webp\n- https://www.example.com/2.jpg.webp\n- https://www.example.com/3.webp"
      }
    ]
  }
}

Related MCP server: crawl4ai-mcp

快速入门（针对用户）

要将此工具与 Claude Desktop 一起使用，只需将以下内容添加到您的 Claude Desktop 配置（ ~/Library/Application Support/Claude/claude_desktop_config.json ）中：

{
  "tools": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@kwp-lab/mcp-fetch"],
      "env": {
        "MCP_HTTP_PROXY": "https://example.com:10890" // Optional, remove if not needed
      }
    }
  }
}

这将在需要时自动下载并运行该工具的最新版本。

所需设置

  1. 为 Claude 启用辅助功能：

    • 打开系统设置

    • 前往“隐私和安全”>“辅助功能”

    • 点击“+”按钮

    • 从您的应用程序文件夹添加 Claude

    • 为克劳德打开开关

对于开发人员

以下部分适用于那些想要开发或修改该工具的人。

先决条件

安装

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 MCP Fetch：

npx -y @smithery/cli install @kwp-lab/mcp-fetch --client claude

手动安装

git clone https://github.com/kwp-lab/mcp-fetch.git
cd mcp-fetch
npm install
npm run build

配置

  1. 确保 Claude Desktop 已安装并正在运行。

  2. 如果还没有安装 tsx，请全局安装：

    npm install -g tsx
# or
pnpm add -g tsx

  3. 修改位于以下位置的 Claude Desktop 配置：

~/Library/Application Support/Claude/claude_desktop_config.json

您可以通过 Claude Desktop 菜单轻松找到它：

  1. 打开 Claude 桌面

  2. 在 Mac 菜单栏上单击 Claude

  3. 点击“设置”

  4. 点击“开发者”

将以下内容添加到您的 MCP 客户端的配置中：

{
  "tools": {
    "fetch": {
      "args": ["tsx", "/path/to/mcp-fetch/index.ts"]
    }
  }
}

Available Tools

1 tool
fetchA

Retrieves URLs from the Internet and extracts their content as markdown. If images are found, their URLs will be included in the response.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
maxLengthNo
startIndexNo
rawNo

TDQS

A3.7/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. It mentions content extraction and image URL inclusion, but doesn't cover important aspects like error handling (e.g., invalid URLs, network failures), rate limits, authentication needs, privacy implications, or what happens when maxLength is exceeded. The description is insufficient for a tool that interacts with external resources.

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 perfectly concise with two clear sentences that each add value. The first sentence establishes the primary function, and the second adds important behavioral detail about image handling. No wasted words or redundant information.

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

Completeness3/5

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

For a tool with 4 parameters, no annotations, and no output schema, the description provides adequate basic functionality explanation but lacks sufficient detail about behavioral characteristics, error conditions, and output format. The absence of sibling tools reduces complexity, but the description should do more to compensate for the lack of structured metadata.

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 description doesn't mention any parameters directly, but with 0% schema description coverage, it doesn't compensate for the lack of parameter documentation. However, the tool has 4 parameters with clear schema definitions (url, maxLength, startIndex, raw), and the description's focus on the core functionality provides some context. The baseline would be lower if the schema were less informative.

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 tool's purpose with specific verbs ('retrieves', 'extracts') and resources ('URLs from the Internet', 'content as markdown'), and explicitly mentions handling of images. It distinguishes what the tool does without relying on the generic name 'fetch'.

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 for retrieving and converting web content to markdown, but provides no explicit guidance on when to use this tool versus alternatives (though no sibling tools are listed). It lacks information about prerequisites, error conditions, or performance considerations.

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. 1 tool update
    • First observedfetch
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

A3.6/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools, making disambiguation perfect. The single tool has a clear and distinct purpose without any competing alternatives.

Naming Consistency5/5

The single tool name 'fetch' follows a simple verb pattern, and with only one tool, consistency is inherently perfect. There are no other tools to create naming conflicts or inconsistencies.

Tool Count2/5

A single tool is too few for most server purposes, as it limits functionality and flexibility. While it might suffice for basic fetching, it feels thin and under-scoped for a server named 'MCP Fetch With Proxy', which suggests broader capabilities.

Completeness2/5

The tool surface is severely incomplete; it only provides fetching and markdown extraction without supporting operations like configuration, error handling, or advanced proxy management. This leaves obvious gaps for a server with 'Proxy' in its name, such as setting or testing proxy settings.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches