Skip to main content
Glama
yuandeshoulian

mcp-local-fetch

MCP Local Fetch

一个功能强大的 MCP (Model Context Protocol) 服务器,提供不受 robots.txt 限制的网页抓取功能。

功能特性

  • 支持所有标准 HTTP 方法(GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)

  • 自定义请求头

  • 请求体支持

  • 重定向控制

  • 超时设置

  • 不遵循 robots.txt 限制

  • 返回完整的响应信息(状态码、响应头、响应体)

Related MCP server: MCP Server Fetch Python

快速开始

方式一:使用 npx(推荐)

无需安装,直接在 Claude Desktop 配置文件中使用:

Windows - 编辑 %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "local-fetch": {
      "command": "npx",
      "args": ["-y", "mcp-local-fetch"]
    }
  }
}

macOS - 编辑 ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "local-fetch": {
      "command": "npx",
      "args": ["-y", "mcp-local-fetch"]
    }
  }
}

Linux - 编辑 ~/.config/claude/claude_desktop_config.json:

{
  "mcpServers": {
    "local-fetch": {
      "command": "npx",
      "args": ["-y", "mcp-local-fetch"]
    }
  }
}

方式二:本地开发

如果你想修改源码或本地开发:

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

然后在配置文件中指向本地路径:

{
  "mcpServers": {
    "local-fetch": {
      "command": "node",
      "args": ["path/to/mcp-local-fetch/dist/index.js"]
    }
  }
}

使用方法

服务器提供一个 fetch 工具,支持以下参数:

参数

  • url (必需): 要抓取的 URL

  • method (可选): HTTP 方法,默认 "GET"

    • 可选值: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS

  • headers (可选): 自定义请求头对象

  • body (可选): 请求体(字符串格式)

  • follow_redirects (可选): 是否跟随重定向,默认 true

  • max_redirects (可选): 最大重定向次数,默认 20

  • timeout (可选): 请求超时时间(毫秒),默认 30000

示例

简单 GET 请求

{
  "url": "https://example.com"
}

POST 请求带自定义头和请求体

{
  "url": "https://api.example.com/data",
  "method": "POST",
  "headers": {
    "Content-Type": "application/json",
    "Authorization": "Bearer token123"
  },
  "body": "{\"key\": \"value\"}"
}

禁用重定向

{
  "url": "https://example.com",
  "follow_redirects": false
}

设置超时

{
  "url": "https://example.com",
  "timeout": 5000
}

响应格式

工具返回 JSON 格式的响应:

{
  "status": 200,
  "statusText": "OK",
  "headers": {
    "content-type": "text/html",
    "content-length": "1234"
  },
  "body": "响应内容...",
  "url": "https://example.com"
}

开发

构建

npm run build

开发模式(自动重新编译)

npm run dev

安全说明

此工具不遵循 robots.txt 限制,请负责任地使用:

  • 遵守目标网站的服务条款

  • 避免过于频繁的请求

  • 尊重网站的隐私政策

  • 仅用于合法目的

许可证

MIT

配合其他 MCP 使用

处理需要 JavaScript 渲染的网站

此 MCP 专注于简单快速的 HTTP 请求。对于需要 JavaScript 渲染的网站(如客户端渲染的 SPA),建议配合使用 Playwright MCP

{
  "mcpServers": {
    "local-fetch": {
      "command": "node",
      "args": ["E:\\workspace\\jasion\\jq-mcp\\mcp-local-fetch\\dist\\index.js"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-playwright"]
    }
  }
}

使用场景:

  • mcp-local-fetch: 快速抓取静态 HTML、API 接口、简单网页

  • Playwright MCP: 抓取需要 JavaScript 渲染的网站(如魔搭社区、现代 SPA 应用)

注意事项

  • 默认使用浏览器 User-Agent 以提高兼容性

  • 自动处理超时和错误

  • 支持 HTTPS

  • 响应体始终以文本形式返回

  • 轻量级设计,启动快速,资源占用少

Available Tools

1 tool
fetchB

Fetch content from a URL without following robots.txt restrictions. Returns the response body as text.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to fetch
bodyNoOptional request body (for POST, PUT, PATCH requests)
methodNoHTTP method (GET, POST, PUT, DELETE, etc.)GET
headersNoOptional HTTP headers to include in the request
timeoutNoRequest timeout in milliseconds (default: 30000)
max_redirectsNoMaximum number of redirects to follow (default: 20)
follow_redirectsNoWhether to follow redirects (default: true)

TDQS

B3.3/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 reveal two non-obvious behaviors: robots.txt restrictions are not followed, and the response body is returned as text. However, it says nothing about error handling, authentication needs, rate limits, or consequences of bypassing robots.txt, so the behavioral picture is incomplete.

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 only two sentences long, with the most decision-relevant fact (robots.txt bypass) front-loaded. There is no filler, and every clause adds useful information about what the tool does or returns.

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 7-parameter network tool with no annotations and no output schema, the description provides the return type but omits broader usage context such as error behavior, handling of non-2xx responses, and when the robots.txt bypass is appropriate. The fully described schema makes the tool callable, but the description alone is not complete enough to fully guide an agent through edge cases.

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 documents all seven parameters and their meanings. The description adds no additional parameter-level context, but that is acceptable given the full schema coverage.

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 clearly states the tool's action and resource: fetch content from a URL, with the notable qualifier that it ignores robots.txt restrictions. It also specifies the return format as the response body as text. However, there are no sibling tools to differentiate from, so it stops short of the top score that requires sibling differentiation.

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 explicit guidance on when to use this tool or what alternatives might exist. The robots.txt bypass implies a specific use case, but that is left for the agent to infer rather than stated directly.

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 updatev1.0.2
    • First observedfetch

TDQS

A3.7/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusion or overlap. The tool's purpose is clearly distinct by virtue of being the only one.

Naming Consistency5/5

The single tool name 'fetch' follows a simple, common verb-only convention. With only one tool, there is no pattern inconsistency to evaluate.

Tool Count3/5

The server has only one tool, which feels thin for a typical MCP server. However, the narrow purpose—fetching URL content—makes a single tool plausible, though it borders on under-scoped.

Completeness5/5

For the stated domain of fetching URL content, the tool fully covers the core operation. There are no obvious missing actions like update or delete because the domain is inherently a single read-only operation.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers