Skip to main content
Glama
enesjakozh
coucya

mcp-server-requests

by coucya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

中文

mcp 服务器请求

提供 HTTP 请求功能的 MCP 服务器，使 LLM 能够获取和处理 Web 内容。

特征

  • 支持将网页内容转换为Markdown格式

  • 支持过滤对法学硕士 (LLM) 无用的内容

  • 支持自定义 User-Agent 标头

  • 支持随机 User-Agent 标头

  • 支持HTTP请求中的自定义请求头

  • 支持完整的 HTTP 方法（GET、POST、PUT、DELETE、PATCH）

  • LLM 可以访问完整的 HTTP 响应头信息

Related MCP server: cURL MCP Server

安装

git clone https://github.com/coucya/mcp-server-requests.git
cd mcp-server-requests
pip install .

用法

MCP 服务器配置

{
    "mcpServers": {
        "mcp-server-requests": {
            "command": "python",
            "args": [
                "-m",
                "mcp_server_requests"
            ]
        }
    }
}

命令行

0.启动 MCP 服务器

直接启动 MCP 服务器：

python -m mcp_server_requests

选项

  • --user-agent TEXT ：指定自定义 User-Agent 字符串

  • --random-user-agent [browser=xxx;os=xxx] : 使用随机生成的User-Agent

  • --force-user-agent ：强制使用命令行指定的用户代理，忽略 LLM 提供的 UA

  • --list-os-and-browser ：列出可用于随机 User-Agent 生成的浏览器和操作系统

选项详细信息

  • --user-agent和--random-user-agent是互斥的，不能一起使用

  • User-Agent设置方法：

    • 自定义字符串： --user-agent "Mozilla/5.0 (...)"

    • 完全随机： --random-user-agent

    • 条件随机生成：

      • 指定浏览器类型： --random-user-agent browser=chrome

      • 指定操作系统： --random-user-agent os=windows

      • 浏览器和操作系统： --random-user-agent browser=chrome;os=windows

      • 注意：浏览器和操作系统参数不区分大小写

  • 使用--list-os-and-browser查看--random-user-agent可用的浏览器和操作系统。

  • --force-user-agent控制 User-Agent 优先级：

    • 启用后：优先考虑命令行指定的 User-Agent（通过--user-agent或--random-user-agent ），忽略 LLM 提供的 UA

    • 禁用时：

      • 如果 LLM 提供了 User-Agent，请使用该

      • 否则使用命令行指定的 User-Agent

1. fetch - 获取网页内容

fetch 子命令相当于 fetch 工具功能，演示了 fetch 功能。

python -m mcp_server_requests fetch <URL> [--return-content {raw,basic_clean,strict_clean,markdown}]

选项：

  • --return-content ：返回内容类型（默认值：markdown）

    • raw ：返回未处理的原始 HTML 内容

    • basic_clean ：基本清理，删除非显示标签，如脚本、样式

    • strict_clean ：严格清理，删除非显示标签和大多数 HTML 属性

    • markdown ：将 HTML 转换为干净的 Markdown 格式

例子：

python -m mcp_server_requests fetch https://example.com

2. get - 执行 HTTP GET 请求

get子命令相当于http_get工具功能，演示了http_get的功能。

python -m mcp_server_requests get <URL> [--headers HEADERS]

选项：

  • --headers ：自定义请求标头（格式：“key1=value1;key2=value2”）

3. post - 执行 HTTP POST 请求

post 子命令相当于 http_post 工具功能，演示 http_post 功能。

python -m mcp_server_requests post <URL> [--headers HEADERS] [--data TEXT]

选项：

  • --headers ：自定义请求标头

  • --data ：请求主体数据

4. put - 执行 HTTP PUT 请求

put 子命令相当于 http_put 工具功能，演示 http_put 功能。

python -m mcp_server_requests put <URL> [--headers HEADERS] [--data TEXT]

选项：与 POST 方法相同

5. delete - 执行 HTTP DELETE 请求

delete 子命令相当于 http_delete 工具功能，演示了 http_delete 的功能。

python -m mcp_server_requests delete <URL> [--headers HEADERS] [--data TEXT]

选项：与 POST 方法相同

功能

可用工具

  1. **fetch——**获取网页内容

    • 参数：

      • url （必填）：目标 URL

      • return_content （可选）：返回内容类型（'raw'、'basic_clean'、'strict_clean'、'markdown'）

        • raw ：返回原始 HTML 内容

        • basic_clean ：返回已过滤的 HTML 内容，删除非显示标签，如脚本、样式

        • strict_clean ：返回过滤后的 HTML 内容，删除非显示标签和大多数无用的 HTML 属性

        • markdown ：返回转换为 Markdown 的 HTML

  2. **http_get——**执行 HTTP GET 请求

    • 参数：

      • url （必填）：目标 URL

      • query （可选）：查询参数键值对

      • 标头（可选）：自定义请求标头

        • LLM 可以在标题中指定 User-Agent，是否使用它由--force-user-agent控制（同样适用于其他工具）

  3. **http_post——**执行 HTTP POST 请求

    • 参数：

      • url （必填）：目标 URL

      • query （可选）：查询参数键值对

      • 标头（可选）：自定义请求标头

      • 数据（可选）：请求正文数据（文本）

      • json （可选）：请求正文数据（JSON）

      • data和json不能一起使用

  4. http_put - 执行 HTTP PUT 请求

    • 参数：同http_post

  5. http_patch - 执行 HTTP PATCH 请求

    • 参数：同http_post

  6. http_delete - 执行 HTTP DELETE 请求

    • 参数：同http_post

执照

麻省理工学院

Available Tools

3 tools
fetchA

Fetch web page content

Function/Features:

  • Retrieves web page content from any HTTP/HTTPS URL

Args: url (str): The URL to fetch content from. return_content ('raw' | 'basic_clean' | 'strict_clean' | 'markdown', optional): Processing format for HTML content. Defaults to "markdown". - "raw": Returns unmodified HTML content with full response headers - "basic_clean": Removes non-displaying tags (script, style, meta, etc.) while preserving structure - "strict_clean": Removes non-displaying tags and most HTML attributes, keeping only essential structure - "markdown": Converts HTML content to clean, readable Markdown format

Examples: // Returns content as markdown fetch({url: "https://example.com"})

// Returns raw HTML content
fetch({url: "https://api.example.com/data", return_content: "raw"})
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes(require) The URL to fetch content from
return_contentNo(optional, Defaults to "markdown") processing format for HTML contentmarkdown

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/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 clearly describes what the tool does (fetching and processing web content) and includes important details about the different processing formats available. However, it doesn't mention potential behavioral aspects like rate limits, authentication requirements, error handling, timeout behavior, or what happens with non-HTML content.

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 well-structured with clear sections (Function/Features, Args, Examples) and front-loads the core purpose. Every sentence adds value: the opening statement establishes purpose, the features section clarifies scope, the args section provides parameter context, and the examples demonstrate practical usage. There's no wasted text or redundancy.

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?

Given that an output schema exists (so return values don't need explanation in the description), the description provides good coverage of the tool's functionality. It explains what the tool does, documents the parameters meaningfully, and includes helpful examples. The main gap is the lack of behavioral context around error conditions, performance characteristics, or limitations that would be important for a web fetching tool.

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?

With 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds meaningful context by explaining the semantic differences between the four 'return_content' options with clear definitions of what each format does, which goes beyond the enum values listed in the schema. This helps the agent understand when to choose each processing option.

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 specific action ('Fetch web page content') and resource ('from any HTTP/HTTPS URL'), making the purpose immediately apparent. It distinguishes itself from sibling tools like 'fetch_to_file' and 'http_request' by focusing specifically on retrieving and processing web content rather than saving to files or making general HTTP requests.

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?

The description provides clear context about when to use this tool (retrieving web page content from URLs) and includes examples that demonstrate different use cases. However, it doesn't explicitly state when NOT to use this tool or provide direct comparisons with sibling alternatives like 'fetch_to_file' or 'http_request'.

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

fetch_to_fileA

Fetch web content and save it to a file in the workspace

Function/Features:

  • Retrieves web content from any HTTP/HTTPS URL and saves it to a file

  • Automatic directory creation for nested file paths

Notes:

  • Automatically creates parent directories if they don't exist

  • Uses UTF-8 encoding for all saved files

  • parameter file_path must be a absolute path

Args: url (str): The URL to fetch content from. file_path (str): File path where the content will be saved. return_content ('raw' | 'basic_clean' | 'strict_clean' | 'markdown'], optional): Processing format for HTML content. Defaults to "markdown". - "raw": Saves unmodified HTML content - "basic_clean": Saves HTML with non-displaying tags removed (script, style, etc.) while preserving structure - "strict_clean": Saves HTML with non-displaying tags and most HTML attributes removed, keeping only essential structure - "markdown": Converts HTML content to clean, readable Markdown format before saving

Examples: // Save web page as markdown fetch_to_file({url: "https://example.com", file_path: "/home/user/content/example.md"})

// Save raw HTML content
fetch_to_file({url: "https://api.example.com/data", file_path: "C:\data\response.html", return_content: "raw"})

// Save cleaned content
fetch_to_file({url: "https://example.com/docs", file_path: "/tmp/docs/cleaned.html", return_content: "strict_clean"})
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes(require) The URL to fetch content from
file_pathYes(require) Absolute file path where the content will be saved. The path must be absolute and will be validated for security
return_contentNo(optional, Defaults to "markdown") processing format for HTML contentmarkdown

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does so well. It discloses key behavioral traits: automatic directory creation, UTF-8 encoding, absolute path requirement, and content processing options. It doesn't mention error handling, rate limits, or authentication needs, but covers essential operational behavior adequately.

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 description is well-structured with clear sections (Function/Features, Notes, Args, Examples) and front-loaded with the core purpose. It's appropriately sized but could be slightly more concise by integrating some notes into the Args section. Every sentence adds value, though the formatting is slightly verbose.

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

Completeness5/5

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

Given the tool's moderate complexity (3 parameters, file operations), no annotations, but with a rich output schema (implied by 'Has output schema: true'), the description is complete. It covers purpose, usage, parameters, and examples thoroughly. The output schema handles return values, so the description appropriately focuses on input and behavior.

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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the 'return_content' enum options in detail with practical semantics (e.g., 'removes non-displaying tags', 'converts to clean Markdown'), which goes beyond the schema's basic enum listing. It also emphasizes the 'absolute path' requirement for 'file_path'.

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 ('fetch web content', 'save it to a file') and resources ('any HTTP/HTTPS URL', 'workspace'). It distinguishes from sibling tools by emphasizing the file-saving aspect, unlike 'fetch' which might return content directly or 'http_request' which is more general.

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?

The description implies usage context through examples and notes (e.g., 'absolute path', 'automatic directory creation'), but does not explicitly state when to use this tool versus alternatives like 'fetch' or 'http_request'. It provides clear operational guidance but lacks comparative decision-making advice.

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

http_requestA

Execute an HTTP request with the specified method

Function/Features:

  • Sends HTTP requests using any standard method (GET, POST, PUT, PATCH, DELETE)

  • Allows custom HTTP headers

  • Returns complete HTTP response including status, headers, and body

Notes:

  • 'data' and 'json' parameters are mutually exclusive - use only one

  • When using 'json', the Content-Type header is automatically set to 'application/json'

  • When using 'data', you may need to set appropriate Content-Type header manually

  • Query parameters are URL-encoded automatically and appended to the URL

  • The response includes the full HTTP response with status line, all headers, and body

Args: url (str): Target URL for the HTTP request. method ('GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE'], optional): HTTP method to use. Defaults to "GET". query ({ [string]: string | number }, optional): Query parameters to append to the URL. Values are automatically converted to strings. Example: {'key1': 'value1', 'key2': 2}, becomes "key1=value1&key2=2" appended to the URL. headers ({ [string]: string }, optional): Custom HTTP request headers. data (str, optional): Text data to send in the request body. Cannot be used with 'json'. json (Any JSON, optional): Data to serialize as JSON and send in the request body. Cannot be used with 'data'.

Examples: // GET request (default method) http_request({url: "https://api.example.com/data"})

// GET request with query parameters
http_request({url: "https://api.example.com/search", query: {"q": "test", "limit": 10}})

// POST request with JSON data
http_request({url: "https://api.example.com/users", method: "POST", json: {"name": "John", "age": 30}})

// POST request with raw text data
http_request({url: "https://api.example.com/log", method: "POST", data: "This is a log message"})

// PUT request
http_request({url: "https://api.example.com/users/123", method: "PUT", json: {"name": "John Updated", "age": 31}})

// PATCH request
http_request({url: "https://api.example.com/users/123", method: "PATCH", json: {"age": 31, "email": "new@example.com"}})

// DELETE request
http_request({url: "https://api.example.com/users/123", method: "DELETE"})

// Request with custom headers
http_request({url: "https://api.example.com/secure", method: "POST", headers: {"Authorization": "Bearer token"}, json: {"key": "value"}})
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes(require) Target URL for the HTTP request
methodYes(optional, Defaults to "GET") HTTP method to use for the request
queryYes
headersYes
dataYes
jsonYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/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 effectively describes key behaviors: automatic URL-encoding of query parameters, automatic Content-Type setting for JSON, and the structure of the complete HTTP response (status, headers, body). However, it lacks details on error handling, timeouts, or authentication requirements, which are important for a general HTTP tool.

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 description is well-structured with clear sections (Function/Features, Notes, Args, Examples) and front-loads key information. However, it is somewhat lengthy due to extensive examples, which, while helpful, could be more concise. Most sentences earn their place by providing essential guidance, but some redundancy exists in explaining response details.

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 complex tool with 6 parameters, low schema coverage, and no annotations, the description does a strong job of covering usage, parameters, and behaviors. The presence of an output schema means return values don't need explanation, but the description still clarifies response structure. Minor gaps remain in error handling and advanced HTTP features, but overall it's nearly complete for effective use.

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

Parameters5/5

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

Given the low schema description coverage (33%), the description compensates excellently by adding detailed semantics for all parameters. It explains the purpose of 'url', 'method' with default, 'query' with encoding behavior, 'headers', and the critical distinction between 'data' and 'json' with Content-Type implications. The examples further clarify usage, adding significant value beyond the minimal schema descriptions.

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 as 'Execute an HTTP request with the specified method,' which is a specific verb+resource combination. It distinguishes itself from sibling tools 'fetch' and 'fetch_to_file' by emphasizing its general-purpose nature supporting multiple HTTP methods, custom headers, and complete response handling, unlike more specialized fetch tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use specific parameters, such as the mutual exclusivity of 'data' and 'json' and when to set Content-Type headers manually. While it doesn't directly compare to sibling tools, the detailed parameter usage rules serve as clear alternatives within the tool itself, helping the agent choose between different request configurations.

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. 8 tool updatesv1.0.0
    • Changedfetch8 fields changed
      • addedInput schema / properties / return_content / description
        Added value: +"(optional, Defaults to \"markdown\") processing format for HTML content"
      • removedInput schema / properties / return_content / title
        Removed value: -"Return Content"
      • addedInput schema / properties / url / description
        Added value: +"(require) The URL to fetch content from"
      • removedInput schema / properties / url / title
        Removed value: -"Url"
      • removedInput schema / title
        Removed value: -"fetchArguments"
      • removedOutput schema / properties / result / title
        Removed value: -"Result"
      • removedOutput schema / title
        Removed value: -"fetchOutput"
      • addedOutput schema / x-fastmcp-wrap-result
        Added value: +true
    • Changedfetch_to_file10 fields changed
      • addedInput schema / properties / file_path / description
        Added value: +"(require) Absolute file path where the content will be saved. The path must be absolute and will be validated for security"
      • removedInput schema / properties / file_path / title
        Removed value: -"File Path"
      • addedInput schema / properties / return_content / description
        Added value: +"(optional, Defaults to \"markdown\") processing format for HTML content"
      • removedInput schema / properties / return_content / title
        Removed value: -"Return Content"
      • addedInput schema / properties / url / description
        Added value: +"(require) The URL to fetch content from"
      • removedInput schema / properties / url / title
        Removed value: -"Url"
      • removedInput schema / title
        Removed value: -"fetch_to_fileArguments"
      • removedOutput schema / properties / result / title
        Removed value: -"Result"
      • removedOutput schema / title
        Removed value: -"fetch_to_fileOutput"
      • addedOutput schema / x-fastmcp-wrap-result
        Added value: +true
    • Removedhttp_delete
    • Removedhttp_get
    • Removedhttp_patch
    • Removedhttp_post
    • Removedhttp_put
    • Addedhttp_request
  2. 7 tool updates
    • First observedfetch
    • First observedfetch_to_file
    • First observedhttp_delete
    • First observedhttp_get
    • First observedhttp_patch
    • First observedhttp_post
    • First observedhttp_put
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes with no overlap. 'fetch' retrieves web content for immediate use, 'fetch_to_file' saves web content to a file, and 'http_request' handles general HTTP requests with full control over methods and parameters. Each tool serves a unique function in the web request workflow.

Naming Consistency5/5

All tools follow a consistent snake_case naming pattern with clear verb-action structure. 'fetch', 'fetch_to_file', and 'http_request' all use descriptive verbs that accurately reflect their functionality, maintaining excellent naming consistency throughout the toolset.

Tool Count4/5

Three tools is reasonable for a web requests server, though slightly minimal. The tools cover the core use cases well, but the count feels slightly lean for a server that could potentially benefit from additional specialized tools like websocket handling or streaming responses.

Completeness5/5

The toolset provides comprehensive coverage for web request operations. It includes content fetching with processing options, file-based fetching, and a full-featured HTTP client supporting all major methods, headers, and data formats. No obvious gaps exist for a general-purpose web requests server.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Fetch MCP Server

    XInTheDark
    A
    license
    C
    quality
    D
    maintenance
    Enables LLMs to retrieve and process web content by fetching URLs and converting HTML to markdown, with support for chunked reading and customizable user-agents.
    1
    MIT

  • cURL MCP Server

    sixees
    A
    license
    A
    quality
    A
    maintenance
    Enables LLMs to make HTTP requests using structured cURL commands with support for multiple authentication methods, custom headers, and comprehensive request/response control.
    2
    9 npm
    3
    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.
    119,247 npm
    MIT

  • Fetch MCP Server

    MaartenSmeets
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables LLMs to fetch and extract web content using browser automation, OCR, and multiple extraction methods, handling JavaScript rendering and anti-scraping techniques.
    17
    MIT

Appeared in Searches