Skip to main content
Glama
pavex

mcp-http-request

by pavex
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Remote

mcp-web-fetch

Token-efficient web reading and HTTP requests for MCP agents.

An MCP server with two tools: fetch_text strips web pages down to clean readable text — dramatically reducing token usage when an agent needs to read a URL. http_request is a full HTTP client for REST API calls, form submissions, and anything requiring raw control.

Built for Claude, Cursor, and any MCP-compatible agent. No browser required. Pure Node.js, single bundled file.

Why fetch_text matters for agents

A typical web page weighs 300–800 KB of raw HTML — scripts, styles, nav bars, footers. Most of it is noise. An agent reading that page burns thousands of tokens on markup it cannot use.

fetch_text scrapes the page and returns only the readable content:

google.com raw HTML   →  ~480 000 chars
google.com fetch_text →       177 chars
manifesto page HTML   →  ~42 000 chars  
manifesto fetch_text  →    5 800 chars  (~7× smaller)

This is a simple HTML scraper — not a full browser renderer. It does not execute JavaScript, handle SPAs, or bypass bot protection. That is the tradeoff for zero dependencies and minimal overhead. For static pages, documentation, articles, and llms.txt files it works excellently.

Related MCP server: MCP API Requester

Tools

fetch_text — low-token web content

Fetches a URL and returns clean readable text. Skips all scripts, styles, navigation, and layout noise. Extracts <title> separately. Prefers <main> or <article> when available.

param

type

default

description

url

string

required

Any valid URL

max_chars

number

20000

Output character cap

timeout_ms

number

10000

Request timeout in ms

Response:

{
  "ok": true,
  "url": "https://example.com/article",
  "status": 200,
  "title": "Article title",
  "text": "Clean readable content without any HTML...",
  "char_count": 4821,
  "truncated": false,
  "elapsed_ms": 248
}

Examples:

# Read an article or documentation page
fetch_text("https://docs.example.com/guide")

# Read a manifesto or about page
fetch_text("https://unpredictablemachine.com/manifesto")

# Read llms.txt
fetch_text("https://example.com/llms.txt")

# Limit output for large pages
fetch_text("https://en.wikipedia.org/wiki/Node.js", max_chars=5000)

Limits:

  • Does not execute JavaScript — SPAs and dynamically rendered content may return empty or partial text

  • Does not handle bot protection or CAPTCHAs

  • Not a replacement for a headless browser

http_request — full HTTP client

Universal HTTP client with full control over method, headers, and body. Use for REST APIs, form posts, webhooks, localhost, and internal network addresses.

param

type

default

description

url

string

required

Any valid URL (https, http, localhost, internal IP)

method

string

GET

GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS

headers

object

{}

Custom request headers

body

string

—

Raw request body (XML, form-data, plain text)

body_json

object

—

Auto-serialized JSON + sets Content-Type: application/json

timeout_ms

number

10000

Request timeout in ms

max_bytes

number

500000

Response body size cap

body_json takes priority over body when both are provided.

Response:

{
  "ok": true,
  "url": "https://api.example.com/posts",
  "method": "POST",
  "status": 201,
  "status_text": "Created",
  "content_type": "application/json",
  "headers": { "content-type": "application/json" },
  "body": "{\"id\": 42}",
  "truncated": false,
  "elapsed_ms": 142
}

Examples:

# REST POST with JSON body
http_request("https://api.example.com/posts",
  method="POST",
  body_json={"title": "Hello", "published": true})

# PUT with Authorization header
http_request("https://api.example.com/users/1",
  method="PUT",
  headers={"Authorization": "Bearer TOKEN"},
  body_json={"name": "Pavel"})

# Raw XML payload
http_request("https://legacy.api/endpoint",
  method="POST",
  headers={"Content-Type": "application/xml"},
  body="<root><item>value</item></root>")

# DELETE
http_request("http://localhost:8080/api/posts/42", method="DELETE")

# Internal network
http_request("http://192.168.1.100:8080/api/status")

When to use which

situation

tool

Reading articles, docs, blog posts

fetch_text

Reading llms.txt or plain text files

fetch_text

REST API calls (POST / PUT / DELETE)

http_request

Raw response body or headers needed

http_request

Localhost or internal network

both work

JavaScript-rendered SPA

neither (use a browser)

Logging

All requests logged to .var/requests.log — one JSON line per request:

{"ts":"2026-06-10T08:20:00.000Z","tool":"fetch_text","method":"GET","url":"https://example.com","status":200,"ok":true,"elapsed_ms":248}

Rotates at ~1 MB → keeps one .1 backup. Configure or disable in src/Config.js:

LOG_FILE: '.var/requests.log',  // '' = disabled
LOG_MAX_BYTES: 1_000_000

Install & build

build.cmd

Installs dependencies, bundles to dist/mcp.js, runs tests. The dist/ folder is self-contained — no node_modules needed at runtime.

Claude Desktop config

{
  "mcpServers": {
    "mcp-web-fetch": {
      "command": "node",
      "args": ["D:/dev/ai/mcp-web-fetch/dist/mcp.js"]
    }
  }
}

Stack

  • Node.js 22+ (native fetch built-in, no extra HTTP dependency)

  • @modelcontextprotocol/sdk

  • node-html-parser — fast pure-JS HTML parser, no native bindings

  • zod + zod-to-json-schema

  • esbuild (build only)

Available Tools

2 tools
fetch_textA

Fetches a URL and returns clean readable text — no HTML tags, scripts, or navigation noise. Ideal for reading articles, documentation, and web pages without context bloat. Extracts separately. Truncates to max_chars (default 20 000) when needed. Non-HTML responses (JSON, plain text) are returned as-is up to max_chars.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
max_charsNo
timeout_msNo

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses key behaviors: extraction of <title> separately, truncation to max_chars (default 20000), and handling of non-HTML responses as-is. Missing details like error behavior or rate limits, but the provided information is substantive.

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 three sentences, front-loaded with purpose, then usage context, then details. Each sentence adds value without redundancy. Could be slightly more concise by combining the first two sentences, but overall efficient.

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

Completeness3/5

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

No output schema is provided, so the description should explain return structure. It mentions returning clean text and extracting <title> separately, but does not specify if the return is a string or an object. Leaves ambiguity about the return format, making it somewhat incomplete.

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

Parameters3/5

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

Schema coverage is 0%, so description must compensate. It adds meaning for 'max_chars' by mentioning default and truncation behavior, but does not describe 'url' or 'timeout_ms' beyond what the schema indicates. Partial coverage, adequate but not comprehensive.

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 fetches a URL and returns clean readable text, stripping HTML and noise. It uses specific verbs ('Fetches', 'returns') and resource ('clean readable text'), and implicitly distinguishes from sibling 'http_request' by focusing on text extraction rather than raw HTTP responses.

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

Usage Guidelines3/5

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

The description mentions it is 'Ideal for reading articles, documentation, and web pages without context bloat,' providing context for when to use it. However, it does not explicitly contrast with sibling 'http_request' or state when not to use this tool, leaving some ambiguity for the agent.

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

http_requestA

Universal HTTP client. Performs GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS requests. Use body_json for JSON APIs (auto-serializes + sets Content-Type: application/json). Use body for raw payloads (XML, form-data, plain text). Works with remote URLs, localhost, and internal network addresses. Returns status, headers, body, and elapsed time.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
methodNoGET
headersNo
bodyNo
body_jsonNo
timeout_msNo
max_bytesNo

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses auto-serialization for JSON, handling of raw payloads, and return fields (status, headers, body, elapsed time). However, it omits error handling, authentication, rate limits, or potential side effects (though HTTP requests are generally idempotent).

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 concise, front-loading purpose, then detailing parameter usage, scope, and return format. No redundant sentences, every sentence adds unique value.

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 7 parameters, no output schema, and no annotations, the description covers key behavioral aspects: method support, payload types, network scope, and return shape. Lacks error/security details but is sufficient for typical use.

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

Parameters3/5

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

With 0% schema description coverage, the description must compensate. It explains the difference between body and body_json, which are the most semantically nuanced parameters. However, other parameters (url, method, headers, timeout_ms, max_bytes) rely solely on schema metadata. The description adds value but not exhaustive.

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 it is a universal HTTP client performing all major methods (GET, POST, PUT, etc.), and distinguishes itself from the sibling tool fetch_text by indicating broader functionality.

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?

Provides explicit guidance on when to use body_json vs body for different payload types, and mentions compatibility with various network addresses. Lacks explicit exclusions or comparison to fetch_text, but context is clear.

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. 2 tool updatesv0.1.0
    • First observedfetch_text
    • First observedhttp_request
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

fetch_text and http_request serve clearly distinct purposes: one extracts clean text from HTML pages, the other is a general HTTP client returning full response details. There is no ambiguity in selecting between them.

Naming Consistency5/5

Both tool names follow a consistent snake_case verb_noun pattern: fetch_text and http_request. This pattern is predictable and clear.

Tool Count4/5

With only 2 tools, the set is slightly minimal but still appropriate for the server's focused purpose of HTTP requests and text extraction. It covers the core needs without bloat.

Completeness4/5

The tools cover the essential HTTP methods and provide a specialized text extraction feature. Minor gaps like file uploads or streaming exist, but for the stated purpose of 'HTTP requests' and 'fetching text', the surface is reasonably complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

  • MCP API Server

    fikri2992
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants to make HTTP requests (GET, POST, PUT, DELETE) to external APIs through standardized MCP tools.
    4
    2
    MIT

  • MCP API Requester

    yryuu
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables LLMs to make arbitrary HTTP requests (GET, POST, PUT, DELETE, etc.) with custom headers, bodies, and cookies, supporting JSON and error handling.
    1
    2
    -

  • HTTP MCP Server

    jules-tnk
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to send HTTP requests to any endpoint with full control over methods, headers, query parameters, and request bodies.
    1
    17
    MIT