Skip to main content
Glama
cUDGk

http-mcp

by cUDGk

http-mcp

HTTP リクエストを LLM から安全に叩く MCP サーバー

TypeScript Node.js undici MCP License: MIT

API テスト・OAuth2 フル対応・セッションクッキー・リトライ・curl コマンド生成を一撃で。


概要

curl 相当の機能を undici 直叩きで提供する。レスポンスボディは content-type に応じてテキスト decode か base64 encode を自動選択し、2 MiB で自動 truncate。ヘッダは全て小文字化して返す。

v0.3 では実用で詰まる所を埋めた: OAuth2 の主要 3 フロー (client_credentials / refresh / device flow) をトークンキャッシュ付きで、セッションクッキー (tough-cookie) で複数リクエストを跨ぐ状態保持、5xx 指数バックオフリトライ、任意リクエストを cURL コマンド文字列に変換。

Related MCP server: curl-mcp

特徴

HTTP リクエスト

アクション

用途

request

フル機能(method / headers / body / json / form / query / 認証 / リダイレクト制御 / retry / session)

get / post / put / delete / patch / head

method だけ固定したショートカット

download

GET してレスポンスを output_path に書き出す。バイナリも OK

as_curl

リクエスト仕様から cURL コマンド文字列を生成 (`shell: bash

アクション

用途

session_create

セッションを作成、ID を返す (session_id オプション指定可)

session_close

セッション破棄

session_list

現在アクティブなセッション一覧

リクエスト系アクションで session: <id> を指定すると、そのセッションの Cookie jar を使って送受信する (tough-cookie ベース)。

OAuth2

アクション

用途

oauth2_client_credentials

machine-to-machine (M2M) フロー。basic / form 認証方式対応、scope/audience 付与可、デフォルトで token キャッシュ (use_cache: false で無効化)

oauth2_refresh

refresh_token フロー

oauth2_device_start

デバイス認可フロー開始。device_code / user_code / verification_uri / interval を返す

oauth2_device_poll

認可待ちをポーリング (max_wait_seconds デフォルト 120、initial_interval 秒刻み)。status: authorized / pending / expired / denied / errorpending は isError ではない(同じ device_code で再呼び出し)、expired / denied / error は isError

oauth2_list_tokens

キャッシュ済みトークンの一覧(expires_in_s 付き)

oauth2_clear_cache

トークンキャッシュ全消去

トークンは (flow, token_url, client_id, secret_fingerprint, scope, audience) でキャッシュ、有効期限の 30 秒前まで再利用。取得した access_token を次のリクエストで bearer: ... に渡せば認証済みリクエストが打てる。

リトライ

retry: {max, on_status, backoff_ms, max_backoff_ms} を渡すと指数バックオフ (min(max_backoff_ms, backoff_ms * 2^n)) でリトライ。デフォルト on_status: [502, 503, 504]。レスポンスに attemptsretried_on[] が入る。

インストール

git clone https://github.com/cUDGk/http-mcp.git
cd http-mcp && npm install && npm run build

使い方

Claude Code に登録

<install-dir>git clone した先の絶対パスに置き換える。

# POSIX
claude mcp add http -- node <install-dir>/dist/index.js
# Windows (PowerShell / cmd)
claude mcp add http -- node C:\path\to\http-mcp\dist\index.js

環境変数

変数

デフォルト

用途

HTTP_TIMEOUT

30000

per-hop タイムアウト (ms)。各 redirect hop ごとに独立して適用される。total wall-clock budget = HTTP_TIMEOUT × (max_redirects + 1) なので、 redirect 上限を上げると全体のタイムアウトも比例して伸びる

HTTP_MAX_BODY

2097152

レスポンスボディの最大バイト数 (デフォルト 2 MiB)

HTTP_USER_AGENT

http-mcp/<package version>

既定の User-Agent (package.json の version を反映)

HTTP_ALLOW_PRIVATE

(未設定)

1 で SSRF ガード無効化(loopback / 10/8 / 172.16/12 / 192.168/16 / 169.254/16 / IPv6 ULA / localhost / *.internal 等を許可)

HTTP_ALLOW_INSECURE_TLS

(未設定)

1reject_unauthorized: false を尊重。未設定の場合は警告して TLS 検証を強制

HTTP_ALLOW_INSECURE_OAUTH

(未設定)

1 で OAuth2 token_url / device_authorization_url の http:// 接続を許可(デフォルトは HTTPS のみ。クライアントシークレット流出を防ぐためテスト用途以外では未設定推奨)

HTTP_DOWNLOAD_ROOT

(未設定)

download の出力先許可ディレクトリ。未設定だと download は失敗output_path はこの配下のみ許可、UNC パス (\\?\, \\server\) は拒否

HTTP_DOWNLOAD_MAX

1073741824

download の最大バイト数 (デフォルト 1 GiB) — 通常レスポンスの HTTP_MAX_BODY とは別

HTTP_SESSION_TTL

3600000

セッションの idle TTL (ms)。これを過ぎたセッションは自動 evict

HTTP_SESSION_MAX

256

同時に保持できるセッション数の上限

呼び出し例

JSON POST + Bearer 認証:

{"action": "post", "url": "https://api.example.com/v1/items",
 "bearer": "sk-...", "json": {"name": "hello"}}

OAuth2 client_credentials で取ったトークンで API を叩く:

{"action": "oauth2_client_credentials",
 "token_url": "https://auth.example.com/oauth/token",
 "client_id": "...", "client_secret": "...",
 "scope": "read:users"}

レスポンスの access_token を次の呼び出しの bearer に渡す:

{"action": "get", "url": "https://api.example.com/users",
 "bearer": "<access_token>"}

OAuth2 デバイス認可フロー (GitHub CLI / Google OAuth 等):

{"action": "oauth2_device_start",
 "device_authorization_url": "https://github.com/login/device/code",
 "client_id": "Iv1.xxx",
 "scope": "repo"}

user_code をユーザーに提示し、ブラウザで認証してもらってから:

{"action": "oauth2_device_poll",
 "token_url": "https://github.com/login/oauth/access_token",
 "client_id": "Iv1.xxx",
 "device_code": "<device_code>",
 "max_wait_seconds": 180}

Cookie jar を使った複数リクエストの状態保持:

{"action": "session_create"}
// → {"id": "s_..."}
{"action": "post", "session": "s_...", "url": "https://example.com/login", "form": {"u":"u","p":"p"}}
{"action": "get",  "session": "s_...", "url": "https://example.com/dashboard"}

5xx に指数バックオフでリトライ:

{"action": "get", "url": "https://flaky.example.com/api",
 "retry": {"max": 3, "on_status": [502, 503, 504],
           "backoff_ms": 500, "max_backoff_ms": 10000}}

リクエスト仕様を cURL コマンドに変換してターミナルで再現:

{"action": "as_curl", "shell": "bash",
 "url": "https://api.example.com/v1/items",
 "method": "POST", "bearer": "sk-abc",
 "json": {"name": "hello"}}

バイナリダウンロード(要 HTTP_DOWNLOAD_ROOToutput_path はその配下に限る、UNC 不可):

# 例: HTTP_DOWNLOAD_ROOT=C:/tmp  をセットしてから
{"action": "download", "url": "https://example.com/asset.zip",
 "output_path": "C:/tmp/asset.zip"}

レスポンスはストリーミングでディスクに直書きされる (通常レスポンスの 2 MiB 上限と分離、デフォルト HTTP_DOWNLOAD_MAX=1 GiB)。

レスポンス形式

{
  "url": "https://...",
  "status": 200,
  "headers": {"content-type": "application/json; charset=utf-8", ...},
  "content_type": "application/json; charset=utf-8",
  "content_length": 1234,
  "body_encoding": "text",
  "body": "{\"ok\": true}",
  "body_truncated": false,
  "redirects": [],
  "duration_ms": 123
}

status >= 400 は MCP 応答で isError: true が立つ。

セキュリティ注意

  • SSRF ガード: localhost / 127.0.0.0/8 / 10.0.0.0/8 / 172.16.0.0/12 / 192.168.0.0/16 / 169.254.0.0/16 / IPv6 ULA・link-local・loopback / *.internal への接続をデフォルトで拒否。DNS 解決後の IP も再検証。社内ネットワーク向けには HTTP_ALLOW_PRIVATE=1 を明示的に設定。

  • リダイレクト再検証: 各 3xx hop ごとに SSRF ガードを再評価。クロスオリジン redirect では Authorization / Cookie / Proxy-Authorization を破棄。

  • ヘッダーインジェクション: ヘッダー名・値を RFC 7230 でバリデート。bearer は printable ASCII のみ。

  • TLS: reject_unauthorized: falseHTTP_ALLOW_INSECURE_TLS=1 がない限り無視 (警告ログ出力)。

  • セッション: caller が指定した session_id は SHA-256 でハッシュ化された値を内部で使用 (cross-leak 防止)。idle TTL HTTP_SESSION_TTL ms (デフォルト 1 時間) で自動 evict。

  • OAuth トークンキャッシュ: cache key に client_secret の sha256 fingerprint を含めるため、同じ client_id でも secret が違えばキャッシュ衝突しない。

  • as_curl 出力: Authorization / Cookie を含むコマンドは平文で出力される。LLM 経由で他者に共有する場合は要注意 (出力に # WARNING: ... を自動で前置)。

  • download: HTTP_DOWNLOAD_ROOT を設定しないと使えない。output_path はそれ配下に限定、UNC パスは拒否。

  • 上記に加え、basic_auth / bearerサーバ自身のログには残らないが、MCP の上位ログに残る可能性はあるので、本物の認証情報を安易に LLM プロンプトに載せない。

v0.3.1 修正

R4 final-pass: edge-case fixes on top of v0.3.0.

  • セキュリティ: SSRF guard を ::ffff:127.0.0.1 等の IPv4-mapped IPv6(dotted / hex 両形式)と :: (unspecified) にも拡張 (S1 / S2)、OAuth2 全フローで token_url / device_authorization_url の HTTPS を必須化 — HTTP_ALLOW_INSECURE_OAUTH=1 で明示的に opt-out 可 (S3)、クロスオリジン redirect で caller 由来の Cookie ヘッダも破棄するよう拡張 (S4)、basic_auth.user: を含む値を拒否 (S5)、downloadoutput_path で UNC に加え Windows device-namespace path (\\.\) も拒否 (S6)、OAuth トークンキャッシュに 512 entry 上限と expired-first eviction を追加 (S7)

  • バグ: redirect の body drain で destroy が無いストリームを iterate-to-completion でフォールバック (B1)、hop === maxRedirects 時に redirect レスポンスを最終応答として返してしまう問題を修正(drain して exceeded-max-redirects を throw)(B2)、max_body 到達時の abort と timeout abort を別フラグで track して aborted_reason を正しくラベリング (B3)、oauth2_refresh のキャッシュキーに scope と refresh_token fingerprint を追加(rotation 後に古い token を返す問題を修正)(B4)、oauth2_device_poll で 200 + access_token 無 + error 無の応答を unexpected_200 として明示終了(無限ソフトループ防止)(B5)、Content-Type: ...; charset=utf-8 明示時にも UTF-8 BOM を strip (B6)、file sink で received = cap を await 完了前に立てていたのを修正 (B7)

  • UX/Schema/Docs: timeout / max_body_bytes / retry / initial_interval / session_id / extra_params の describe を整備 (U1-U6)、README env-var table に HTTP_USER_AGENT / HTTP_ALLOW_INSECURE_OAUTH を追加 (U7)、v0.3.1 changelog 追加 + version 同期 (U8)、stale な v0.2 では 文言を v0.3 に更新 (U9)、HTTP_TIMEOUT を per-hop と明記し total wall-clock = timeout × (max_redirects + 1) を README にも反映 (U10)、oauth2.tsmakeError 内 catch swallow に理由コメントを追加 (U11)、curl bash の binary body を echo から printf '%s' へ(trailing newline 防止)(U12)、PowerShell binary の [Convert]::FromBase64String(...) | curl がバイト忠実でない警告と temp-file 代替を出力に追加 (U13)

v0.3.0 修正

セキュリティ・バグ・UX 全方位アップデート。サーバ名を http-mcp に統一。

  • セキュリティ: SSRF ガード (S1)、redirect 毎の再検証 + クロスオリジン認証ヘッダ破棄 (S2)、ヘッダーインジェクション防御 (S3)、TLS 検証バイパスの env ゲート化 (S4)、download の path allowlist (S5)、session id ハッシュ + idle TTL evict (S6)、OAuth キャッシュキーに secret fingerprint (S7)、as_curl 認証情報警告 (S8)

  • バグ: グローバル Agent の再利用 (B1)、独自 redirect → redirects[] を実値で出力 (B3)、timeout 時に aborted_reason: "timeout" を返す (B4)、上限到達時に socket クリーンアップ (B5)、charset / BOM 対応の本文デコード (B6)、TEXTUAL regex の修正 (B7)、Buffer.from の死コード除去 (B8)、Set-Cookie を redirect 後の最終 URL で保存 (B9)、リトライ末尾の sleep 削除 (B10)、coerceObject JSON エラー伝播 (B11)、OAuth body_encoding=base64 対応 (B12)、expires_in - 30 負値ガード (B13)、device poll の HTTP ステータス分離 (B14)、token レスポンス zod バリデーション (B15)、body_base64 の Content-Type デフォルト (B16)、noUncheckedIndexedAccess 有効化 (B17)、env 数値バリデーション (B18)、SIGTERM/SIGINT 経由のグレースフル shutdown (B19)

  • UX: 全プロパティに describe (U1)、download ストリーミング書き出し (U2/U3)、README の path / env / 警告整備 (U4)、as McpResponse 型化 (U5)、OAuth 構造化エラー (U6)、binary body の curl 警告整形 (U7)、cmd 引用注意書き (U8)、tough-cookie swallow コメント (U9)、unhandledRejection ロガー (U10)

v0.2.1 修正

一部の MCP クライアント (Claude Code の LLM ツール使用パス等) がオブジェクト引数を JSON 文字列化してからサーバーに渡す挙動があり、json パラメータが二重エンコードされて送信先 (例: Discord Webhook) が「dictionary が期待された」と 400 を返す問題があった。

修正内容:

  • headers / form / basic_auth / query / retry / extra_params の zod schema を z.union([<本来の型>, z.string()]) に緩和

  • coerceObject() ヘルパを追加し、文字列で届いた場合は JSON.parse で object に戻してから使用

  • json パラメータは文字列を受けたら先に JSON.parse して、本来のボディ形状で再シリアライズ (二重エンコード防止)

Attribution

ライセンス

MIT License © 2026 cUDGk — 詳細は LICENSE を参照。

Available Tools

1 tool
httpA

HTTP client for LLMs. curl-equivalent + OAuth2 + sessions + retry.

Response bodies: textual types decoded with charset awareness; binary types base64-encoded; capped at HTTP_MAX_BODY (default 2 MiB) with body_truncated flag. status >= 400 sets MCP isError.

BODY SELECTION (choose one per request): json | form | body | body_base64.

AUTH: basic_auth | bearer | oauth2_* flows that cache tokens and can feed into 'bearer' of a subsequent request.

SESSIONS: cookie jars keyed by session id. Pass 'session' on request/get/post/etc to send and store cookies per domain. Manage with session_create / session_list / session_close. Caller-supplied ids are hashed; idle sessions evicted after HTTP_SESSION_TTL ms.

RETRY: retry={max, on_status, backoff_ms, max_backoff_ms}. Exponential backoff on transient 5xx by default.

SECURITY: SSRF guard blocks loopback / private networks unless HTTP_ALLOW_PRIVATE=1. reject_unauthorized=false ignored unless HTTP_ALLOW_INSECURE_TLS=1. download requires HTTP_DOWNLOAD_ROOT.

Actions:

  • request / get / post / put / delete / patch / head: HTTP requests.

  • download: GET + stream to output_path (must be under HTTP_DOWNLOAD_ROOT).

  • as_curl: convert a request spec to a cURL command string. shell = bash | cmd | powershell. Output may include plaintext credentials; warning lines are prepended.

  • session_create / session_close / session_list: cookie jar lifecycle.

  • oauth2_client_credentials: machine-to-machine. Returns {access_token, expires_in, ...}. Caches by (token_url, client_id, secret_fingerprint, scope, audience).

  • oauth2_refresh: refresh_token grant.

  • oauth2_device_start: start device authorization flow.

  • oauth2_device_poll: poll token endpoint. status=pending is NOT an error — caller should retry with the same device_code; status=expired/denied/error are isError.

  • oauth2_list_tokens / oauth2_clear_cache.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform
urlNorequest/get/post/put/delete/patch/head/download/as_curl: target URL (http/https)
methodNorequest: HTTP method override (default GET)
headersNorequest/*/as_curl: additional request headers; values must be RFC 7230 valid
queryNorequest/*/as_curl: query string params; arrays append multiple values
bodyNorequest/*/as_curl: raw text body (mutually exclusive with json/form/body_base64)
body_base64Norequest/*/as_curl: binary body, base64-encoded; defaults Content-Type to application/octet-stream
jsonNorequest/*/as_curl: JSON body; sets Content-Type application/json
formNorequest/*/as_curl: form-urlencoded body
basic_authNorequest/*/as_curl: HTTP Basic credentials
bearerNorequest/*/as_curl: Bearer token (printable ASCII only)
timeoutNorequest/*/download: per-hop timeout in ms (default HTTP_TIMEOUT, 30000). Total wall-clock budget = timeout × (max_redirects + 1).
follow_redirectsNorequest/*/as_curl: follow 3xx redirects (default true; cross-origin drops Authorization/Cookie)
max_redirectsNorequest/*: max redirect hops (default 5)
reject_unauthorizedNorequest/*: TLS verification toggle; false requires HTTP_ALLOW_INSECURE_TLS=1
max_body_bytesNorequest/*: response body cap (default HTTP_MAX_BODY, 2 MiB). Also overrides HTTP_DOWNLOAD_MAX for the download action (which otherwise defaults to 1 GiB).
sessionNorequest/*: session id for the cookie jar. Accepts either the server-generated id from session_create or a caller-supplied id (the latter is sha256-hashed before use)
retryNorequest/*: retry policy with exponential backoff (default on 502/503/504). Active only when max >= 1.
output_pathNodownload (REQUIRED): absolute destination path; must reside under HTTP_DOWNLOAD_ROOT; UNC paths rejected
shellNoas_curl: target shell syntax (default bash)
session_idNosession_create/session_close: optional on session_create, REQUIRED for session_close. Caller-supplied id; the server hashes it (sha256, prefixed 'u_') before using it as the live key, so the raw id is never the cache key
token_urlNooauth2_client_credentials/oauth2_refresh/oauth2_device_poll: token endpoint URL
device_authorization_urlNooauth2_device_start: device authorization endpoint URL
client_idNooauth2_*: OAuth client id
client_secretNooauth2_client_credentials/oauth2_refresh/oauth2_device_poll: OAuth client secret (cache key uses sha256 fingerprint, not raw secret)
scopeNooauth2_*: OAuth scope string
audienceNooauth2_client_credentials/oauth2_device_start: optional audience parameter
refresh_tokenNooauth2_refresh: refresh_token to exchange
device_codeNooauth2_device_poll: device_code from oauth2_device_start
auth_methodNooauth2_client_credentials/oauth2_refresh: how to send client credentials. oauth2_client_credentials defaults to 'basic'. oauth2_refresh defaults to 'basic' only when client_secret is set, otherwise 'form' (public client)
use_cacheNooauth2_client_credentials: reuse cached token if not yet expired (default true)
max_wait_secondsNooauth2_device_poll: max polling duration in seconds (default 120)
initial_intervalNooauth2_device_poll: initial polling interval (in seconds; default 5). slow_down responses add 5 seconds each.
extra_paramsNooauth2_client_credentials/oauth2_device_start: extra form params merged into the token/device request. Not supported for oauth2_refresh.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: response body truncation with body_truncated flag, status >=400 sets isError, OAuth token caching and key fingerprints, session id hashing, retry exponential backoff defaults, SSRF guard conditions, and download path restrictions. This is exceptionally thorough.

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 long but well-structured with clear section headers (Response bodies, BODY SELECTION, AUTH, etc.) and a one-line summary at the start. Every sentence serves a purpose, though it could be slightly tighter given the complexity. It is appropriately sized for a tool with 34 parameters.

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 the high complexity, no sibling tools, and no output schema, the description covers response handling, body choices, authentication flows, sessions, retry, security, and all actions. It lacks explicit return value documentation for some actions (e.g., session_list), but is otherwise very complete.

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?

Schema coverage is 100% with parameter descriptions, but the tool description adds significant value: mutual exclusivity of body types, defaults for timeout and retry, OAuth flow details (e.g., use_cache, auth_method defaults), and session id handling. It augments the schema substantially.

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's an 'HTTP client for LLMs' and lists all 18 distinct actions (e.g., request, get, post, oauth2_*), each with a specific verb and resource. It differentiates between similar actions like oauth2_device_start vs oauth2_device_poll, providing sufficient distinction.

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?

Extensive guidance on when to use each action is provided, such as 'oauth2_device_poll: status=pending is NOT an error — caller should retry' and the body selection choice. Security restrictions (SSRF guard, TLS) are also given. Since there are no sibling tools, explicit when-not-to-use statements are absent, but the context is clear.

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

TDQS

A4.6/5.0
Disambiguation5/5

Only one tool exists, so there is no ambiguity between tools. The tool's description clearly defines its purpose as an HTTP client.

Naming Consistency5/5

With a single tool named 'http', naming consistency is trivially maintained. The name directly reflects the tool's function.

Tool Count3/5

One tool is on the lower end of the typical range. While it covers HTTP functionality, the server might benefit from splitting into separate tools for requests, sessions, and OAuth to improve modularity.

Completeness5/5

The tool covers all major HTTP operations, authentication methods, session management, retry logic, and security features. No obvious gaps for a general-purpose HTTP client.

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

  • A
    license
    A
    quality
    C
    maintenance
    Web Content Retrieval (full webpage, filtered content, or Markdown-converted), Custom User-Agent, Multi-HTTP Method Support (GET/POST/PUT/DELETE/PATCH), LLM-Controlled Request Headers, LLM-Accessible Response Headers, and more.
    3
    7
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides a structured HTTP client tool for making web requests with full HTTP method support, detailed response metadata, and error handling. Enables AI assistants to interact with any web API or endpoint through the curl_request tool.
    12
    2
    MIT
  • A
    license
    A
    quality
    B
    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
  • 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/cUDGk/http-mcp'

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