Skip to main content
Glama
pavex

mcp-http-request

by pavex
OverviewSchemaRelated ServersScoreDiscussions
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

A4.2/5.0
Behavior4/5

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

Discloses key behaviors: stripping HTML, extracting title, truncating to max_chars, handling non-HTML as-is. Lacks details on error handling, rate limits, or auth, but sufficient given no annotations.

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?

Three front-loaded sentences with no redundancy; each sentence adds value. Efficient and well-structured.

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 read tool with no output schema and no annotations, it adequately describes behavior and return type (clean text). However, missing details on errors and timeout behavior.

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 explain parameters. Explains url implicitly and max_chars with default, but does not mention timeout_ms parameter.

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 fetches a URL and returns clean readable text, distinguishing itself from the sibling http_request by emphasizing noise removal. Specific verb and resource.

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?

States ideal use for articles and web pages without context bloat, but does not explicitly exclude cases where raw HTML is needed or mention alternatives beyond the sibling.

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

A3.5/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that it works with internal network addresses (security implication) and returns status/headers/body/elapsed time. Missing traits: error handling, idempotency, rate limits, authentication, redirect behavior. Moderate transparency but gaps remain.

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?

Four concise sentences, each serving a purpose: purpose and methods, body options, scope, return values. No redundancy, front-loaded with essential information. Highly 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?

Covers methods, body options, and return structure. However, missing details on timeout_ms, max_bytes, error behavior, and security considerations (e.g., auth, rate limits). Given 7 parameters and no output schema, the description is adequate but not fully complete.

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

Parameters2/5

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

Schema description coverage is 0%, so description must add meaning. It explains body_json vs body and auto Content-Type setting, but does not describe parameters like url, method, headers, timeout_ms, max_bytes. Only 2 of 7 parameters are elaborated, insufficient given no schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it's a universal HTTP client performing various methods. It lists GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. However, it does not explicitly differentiate from sibling 'fetch_text', which likely is a subset. The purpose is clear but sibling distinction is implicit.

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 JSON APIs versus raw payloads. Mentions scope (remote, localhost, internal). However, no direct comparison with fetch_text or exclusions. The context is clear but alternative use cases are not fully addressed.

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

A3.9/5.0
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
ResponsivenessSyncing

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

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/pavex/mcp-web-fetch'

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