Skip to main content
Glama
enesjakozh
coucya

mcp-server-requests

by coucya
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

中文

mcp-server-requests

An MCP server that provides HTTP request capabilities, enabling LLMs to fetch and process web content.

Features

  • fetch: Web content fetching tool

    • Supports converting web content to Markdown format

    • Supports filtering web content (non-visual elements like script, style, meta)

    • Feeds into LLM context, reducing token consumption through Markdown conversion or filtering non-visual elements

  • fetch_to_file: Web content saving tool

    • Web content is not fed into LLM context, avoiding excessive token consumption

  • http_request: Generic HTTP request tool

    • Full HTTP method support (GET, POST, PUT, PATCH, DELETE)

    • Supports custom request headers

    • Supports text and JSON request bodies

    • Returns complete HTTP response information (status, headers, body) for LLMs

  • Supports custom User-Agent

  • Supports random User-Agent generation

  • Supports using MCP Root capability, controlled by --use-root, usable with MCP Clients that have root capability

Related MCP server: cURL MCP Server

Installation

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

Usage

MCP Server Configuration

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

Command Line

0. Start MCP Server

Start the MCP server directly:

python -m mcp_server_requests

Options

  • --user-agent TEXT: Specify custom User-Agent string

  • --random-user-agent [browser=xxx;os=xxx]: Use randomly generated User-Agent

  • --force-user-agent: Force using command line specified User-Agent, ignoring LLM provided UA

  • --list-os-and-browser: List available browsers and OS for random User-Agent generation

  • --use-root: Enable workspace root support for file operations (requires MCP Client with root capability support)

  • --allow-external-file-access: Allow file operations outside workspace (only with --use-root)

Option Details

  • --user-agent and --random-user-agent are mutually exclusive and cannot be used together

  • User-Agent setup methods:

    • Custom string: --user-agent "Mozilla/5.0 (...)"

    • Fully random: --random-user-agent

    • Conditional random generation:

      • Specify browser type: --random-user-agent browser=chrome

      • Specify OS: --random-user-agent os=windows

      • Both browser and OS: --random-user-agent browser=chrome;os=windows

      • Note: Browser and OS parameters are case insensitive

  • Use --list-os-and-browser to view available browsers and OS for --random-user-agent.

  • --force-user-agent option controls User-Agent priority:

    • When --force-user-agent is enabled: Force using command-line specified User-Agent (via --user-agent or --random-user-agent)

    • When --force-user-agent is disabled:

      • If LLM provides User-Agent in headers, use the LLM-provided one

      • Otherwise use command-line specified User-Agent

    • If none specified, use default User-Agent: Mozilla/5.0 (compatible; mcp-server-requests/{version})

  • --use-root enables file operations relative to workspace root:

    • Prerequisite: Requires MCP Client with root capability support

    • When enabled: fetch_to_file allows absolute paths or relative paths, relative paths are relative to workspace root

    • When disabled: fetch_to_file must use absolute paths, files are saved to specified absolute path locations

  • --allow-external-file-access: Controls whether file operations outside workspace are allowed (only usable with --use-root)

    • Prerequisite: Requires --use-root to be enabled, this option has no effect if --use-root is not enabled

    • When enabled: fetch_to_file can operate on files outside the workspace directory

    • When disabled: fetch_to_file can only operate on files within the workspace directory, even if absolute paths are provided, files outside the workspace cannot be operated on

1. fetch - Fetch Web Content

The fetch subcommand is equivalent to the MCP fetch tool functionality, used to demonstrate fetch capabilities.

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

Options:

  • --return-content: Return content type (default: markdown)

    • raw: Return raw unprocessed HTML content (includes response headers)

    • basic_clean: Basic cleanup, removing non-display tags (script, style, meta, etc.) while preserving structure

    • strict_clean: Strict cleanup, removing non-display tags and most HTML attributes, keeping only essential structure

    • markdown: Convert HTML to clean Markdown format

Functionality

MCP Tool Details

1. fetch - Fetch Web Content

Fetch content from the specified URL and return it in the specified format.

Parameters:

  • url (required, string): Target URL, supports HTTP/HTTPS protocols

  • return_content (optional, enum): Content processing format, defaults to "markdown"

    • "raw": Return raw HTML content with complete HTTP response headers

    • "basic_clean": Basic cleanup, removing non-display tags (script, style, meta, etc.) while preserving HTML structure

    • "strict_clean": Strict cleanup, removing non-display tags and most HTML attributes, keeping only essential structure

    • "markdown": Convert HTML content to clean Markdown format

Returns: Content processed according to the specified format

2. fetch_to_file - Fetch Web Content and Save to File

Fetch content from the specified URL and save it to a file.

Parameters:

  • url (required, string): Target URL

  • file_path (required, string): File save path

    • When --use-root is enabled: Must be a relative path (relative to workspace root)

    • When --use-root is disabled: Must be an absolute path

  • return_content (optional, enum): Content processing format, defaults to "markdown", same options as fetch tool

Features:

  • Automatically creates parent directories for nested paths

  • All files saved with UTF-8 encoding

  • When --use-root is enabled, can work with --allow-external-file-access to control file access scope

Returns: Operation result or error message

3. http_request - Generic HTTP Request Tool

Send HTTP requests using any method and get complete responses.

Parameters:

  • url (required, string): Target URL

  • method (optional, enum): HTTP method, defaults to "GET"

    • "GET", "POST", "PUT", "PATCH", "DELETE"

  • query (optional, object): URL query parameters as key-value pairs, automatically URL-encoded

  • headers (optional, object): Custom HTTP request headers

  • data (optional, string): Text format request body data, mutually exclusive with json parameter

  • json (optional, any type): JSON format request body data, mutually exclusive with data parameter

Parameter Constraints:

  • data and json parameters cannot be used together

  • When using json parameter, Content-Type: application/json is automatically set

  • When using data parameter, it's recommended to manually set appropriate Content-Type

Returns: Complete HTTP response (status line, response headers, and response body)

Note: Individual HTTP method tools (http_get, http_post, http_put, http_patch, http_delete) have been removed and replaced by the unified http_request tool.

License

MIT

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
    16
    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.
    102,856
    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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/coucya/mcp-server-requests'

If you have feedback or need assistance with the MCP directory API, please join our Discord server