mcp-server-requests
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| user-agent | No | Specify a custom User-Agent | |
| force-user-agent | No | Force the use of the specified or randomly generated UA, ignore the UA provided by the model | |
| random-user-agent | No | Use a random User-Agent, can specify browser and OS (e.g. 'browser=chrome;os=windows') | |
| list-os-and-browser | No | List available browsers and operating systems for UA selection |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fetchA | Fetch web page content Function/Features:
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"}) |
| fetch_to_fileA | Fetch web content and save it to a file in the workspace Function/Features:
Notes:
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"}) |
| http_requestA | Execute an HTTP request with the specified method Function/Features:
Notes:
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"}) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
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.
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.
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.
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.