en es ja ko zh

mcp-server-requests

Name: mcp-server-requests
Author: coucya

by coucya

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Chino

solicitudes del servidor mcp

Un servidor MCP que proporciona capacidades de solicitud HTTP, lo que permite a los LLM obtener y procesar contenido web.

Características

Admite la conversión de contenido web al formato Markdown
Admite el filtrado de contenido inútil para los LLM
Admite encabezados de agente de usuario personalizados
Admite encabezados de agente de usuario aleatorios
Admite encabezados de solicitud personalizados en solicitudes HTTP
Admite métodos HTTP completos (GET, POST, PUT, DELETE, PATCH)
Los LLM pueden acceder a la información completa del encabezado de respuesta HTTP

Related MCP server: cURL MCP Server

Instalación

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

Uso

Configuración del servidor MCP

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

Línea de comandos

0. Iniciar el servidor MCP

Inicie el servidor MCP directamente:

python -m mcp_server_requests

Opciones

--user-agent TEXT : Especifica una cadena de agente de usuario personalizada
--random-user-agent [browser=xxx;os=xxx] : Utiliza un agente de usuario generado aleatoriamente
--force-user-agent : Fuerza el uso del agente de usuario especificado por la línea de comandos, ignorando el UA proporcionado por LLM
--list-os-and-browser : enumera los navegadores y sistemas operativos disponibles para la generación aleatoria de agentes de usuario

Detalles de la opción

--user-agent y --random-user-agent son mutuamente excluyentes y no se pueden usar juntos
Métodos de configuración del agente de usuario:
- Cadena personalizada: --user-agent "Mozilla/5.0 (...)"
- Completamente aleatorio: --random-user-agent
- Generación aleatoria condicional:
  - Especifique el tipo de navegador: --random-user-agent browser=chrome
  - Especifique el sistema operativo: --random-user-agent os=windows
  - Tanto el navegador como el sistema operativo: --random-user-agent browser=chrome;os=windows
  - Nota: Los parámetros del navegador y del sistema operativo no distinguen entre mayúsculas y minúsculas.
Utilice --list-os-and-browser para ver los navegadores y sistemas operativos disponibles para --random-user-agent .
--force-user-agent controla la prioridad del agente de usuario:
- Cuando está habilitado: prioriza el agente de usuario especificado en la línea de comandos (a través de --user-agent o --random-user-agent ), ignorando el UA proporcionado por LLM
- Cuando está deshabilitado:
  - Si LLM proporciona un agente de usuario, úselo
  - De lo contrario, utilice la línea de comandos especificada por el agente de usuario.

1. fetch - Obtener contenido web

El subcomando fetch es equivalente a la funcionalidad de la herramienta fetch y demuestra las capacidades de búsqueda.

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

Opciones:

--return-content : Tipo de contenido de retorno (predeterminado: markdown)
- raw : Devuelve contenido HTML sin procesar
- basic_clean : Limpieza básica, eliminando etiquetas que no se muestran, como script y estilo.
- strict_clean : Limpieza estricta, eliminando etiquetas que no se muestran y la mayoría de los atributos HTML
- Markdown : convierte HTML a formato Markdown limpio

Ejemplo:

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

2. get - Ejecutar solicitud HTTP GET

El subcomando get es equivalente a la funcionalidad de la herramienta http_get, demostrando las capacidades de http_get.

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

Opciones:

--headers : Encabezados de solicitud personalizados (formato: "clave1=valor1;clave2=valor2")

3. post - Ejecutar solicitud HTTP POST

El subcomando post es equivalente a la funcionalidad de la herramienta http_post, demostrando las capacidades de http_post.

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

Opciones:

--headers : encabezados de solicitud personalizados
--data : Datos del cuerpo de la solicitud

4. put - Ejecutar solicitud HTTP PUT

El subcomando put es equivalente a la funcionalidad de la herramienta http_put, demostrando las capacidades de http_put.

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

Opciones: Igual que el método POST

5. eliminar - Ejecutar solicitud HTTP DELETE

El subcomando eliminar es equivalente a la funcionalidad de la herramienta http_delete, lo que demuestra las capacidades de http_delete.

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

Opciones: Igual que el método POST

Funcionalidad

Herramientas disponibles

fetch - Obtener contenido web
- Parámetros:
  - URL (obligatorio): URL de destino
  - return_content (opcional): Tipo de contenido de retorno ('raw', 'basic_clean', 'strict_clean', 'markdown')
    - raw : Devuelve contenido HTML sin procesar
    - basic_clean : Devuelve contenido HTML filtrado, eliminando etiquetas que no se muestran, como script y estilo.
    - strict_clean : Devuelve contenido HTML filtrado, eliminando las etiquetas que no se muestran y la mayoría de los atributos HTML inútiles
    - markdown : Devuelve HTML convertido a Markdown
http_get - Ejecutar solicitud HTTP GET
- Parámetros:
  - URL (obligatorio): URL de destino
  - consulta (opcional): pares clave-valor de parámetros de consulta
  - encabezados (opcionales): encabezados de solicitud personalizados
    - LLM puede especificar User-Agent en los encabezados; si se usa o no se controla mediante --force-user-agent (lo mismo se aplica a otras herramientas)
http_post - Ejecutar solicitud HTTP POST
- Parámetros:
  - URL (obligatorio): URL de destino
  - consulta (opcional): pares clave-valor de parámetros de consulta
  - encabezados (opcionales): encabezados de solicitud personalizados
  - datos (opcional): Datos del cuerpo de la solicitud (texto)
  - json (opcional): datos del cuerpo de la solicitud (JSON)
  - Los datos y JSON no se pueden usar juntos
http_put - Ejecutar solicitud HTTP PUT
- Parámetros: Igual que http_post
http_patch - Ejecutar solicitud HTTP PATCH
- Parámetros: Igual que http_post
http_delete - Ejecutar solicitud HTTP DELETE
- Parámetros: Igual que http_post

Licencia

Instituto Tecnológico de Massachusetts (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

Name	Required	Description	Default
`url`	Yes	(require) The URL to fetch content from
`return_content`	No	(optional, Defaults to "markdown") processing format for HTML content	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`url`	Yes	(require) The URL to fetch content from
`file_path`	Yes	(require) Absolute file path where the content will be saved. The path must be absolute and will be validated for security
`return_content`	No	(optional, Defaults to "markdown") processing format for HTML content	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description
`url`	Yes	(require) Target URL for the HTTP request
`method`	Yes	(optional, Defaults to "GET") HTTP method to use for the request
`query`	Yes
`headers`	Yes
`data`	Yes
`json`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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.

8 tool updatesv1.0.0Jan 3, 2026
- 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
7 tool updatesSep 9, 2025
- 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 2026-04-18 10:40 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

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

mcp A
ai.foura
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Web Scraping Browser Automation
434
SteadyFetch A
io.github.carsonroell-debug
Reliable web fetching for AI agents with retry, circuit breaker, caching, and anti-bot bypass
Browser Automation Web Scraping Agent Orchestration
52
mcp-server A
io.tooltrace
Web tools for AI agents: scrape pages to Markdown, audit SEO, detect tech stacks, check sitemaps
Browser Automation Web Scraping
71
glim.sh A
sh.glim
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
Browser Automation Social Media Version Control
1434

Related MCP Servers

Fetch MCP Server
Web Scraping Browser Automation
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.
Updated a year ago (2025-08-29 15:44 UTC)
1
MIT
cURL MCP Server
API Testing Developer Tools App Automation
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.
Updated 21 days ago (2026-09-10 10:41 UTC)
2
9 npm
3
MIT
Fetch MCP Server
Browser Automation Web Scraping Search
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.
Updated 8 months ago (2026-02-09 04:29 UTC)
119,247 npm
MIT
Fetch MCP Server
Browser Automation Web Scraping
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.
Updated a year ago (2025-06-11 14:39 UTC)
17
MIT

solicitudes del servidor mcp

Características

Instalación

Uso

Configuración del servidor MCP

Línea de comandos

0. Iniciar el servidor MCP

Opciones

Detalles de la opción

1. fetch - Obtener contenido web

2. get - Ejecutar solicitud HTTP GET

3. post - Ejecutar solicitud HTTP POST

4. put - Ejecutar solicitud HTTP PUT

5. eliminar - Ejecutar solicitud HTTP DELETE

Funcionalidad

Herramientas disponibles

Licencia

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches