Skip to main content
Glama
enesjakozh
coucya

mcp-server-requests

by coucya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

中国語

mcp-server-requests

HTTP リクエスト機能を提供し、LLM が Web コンテンツを取得して処理できるようにする MCP サーバー。

特徴

  • 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] : ランダムに生成されたユーザーエージェントを使用する

  • --force-user-agent : コマンドラインで指定されたユーザーエージェントを強制的に使用し、LLM が提供する UA を無視します。

  • --list-os-and-browser : ランダムなユーザーエージェント生成に使用できるブラウザと OS を一覧表示します

オプションの詳細

  • --user-agentと--random-user-agentは相互に排他的であり、一緒に使用することはできません。

  • ユーザーエージェントの設定方法:

    • カスタム文字列: --user-agent "Mozilla/5.0 (...)"

    • 完全にランダム: --random-user-agent

    • 条件付きランダム生成:

      • ブラウザの種類を指定: --random-user-agent browser=chrome

      • OS を指定: --random-user-agent os=windows

      • ブラウザと OS の両方: --random-user-agent browser=chrome;os=windows

      • 注: ブラウザとOSのパラメータは大文字と小文字を区別しません

  • --random-user-agentで使用可能なブラウザーと OS を表示するには--list-os-and-browserを使用します。

  • --force-user-agent User-Agent の優先順位を制御します:

    • 有効にすると、コマンドラインで指定された User-Agent ( --user-agentまたは--random-user-agent経由) を優先し、LLM が提供する UA を無視します。

    • 無効にした場合:

      • LLMがUser-Agentを提供している場合はそれを使用する

      • それ以外の場合はコマンドラインで指定されたUser-Agentを使用する

1. fetch - Webコンテンツを取得する

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 : HTMLをMarkdownに変換して返す

  2. http_get - HTTP GETリクエストを実行する

    • パラメータ:

      • url (必須): ターゲットURL

      • クエリ（オプション）: クエリパラメータのキーと値のペア

      • ヘッダー（オプション）: カスタムリクエストヘッダー

        • LLM はヘッダーに User-Agent を指定する場合があり、それを使用するかどうかは--force-user-agentによって制御されます (他のツールにも同様に適用されます)

  3. http_post - HTTP POSTリクエストを実行する

    • パラメータ:

      • url (必須): ターゲットURL

      • クエリ（オプション）: クエリパラメータのキーと値のペア

      • ヘッダー（オプション）: カスタムリクエストヘッダー

      • データ（オプション）: リクエストボディデータ（テキスト）

      • json (オプション): リクエストボディデータ (JSON)

      • データと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