http-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@http-mcpfetch https://api.example.com/users"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
http-mcp
HTTP リクエストを LLM から安全に叩く MCP サーバー
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 リクエスト
アクション | 用途 |
| フル機能( |
|
|
| GET してレスポンスを |
| リクエスト仕様から cURL コマンド文字列を生成 (`shell: bash |
セッション (Cookie jar)
アクション | 用途 |
| セッションを作成、ID を返す ( |
| セッション破棄 |
| 現在アクティブなセッション一覧 |
リクエスト系アクションで session: <id> を指定すると、そのセッションの Cookie jar を使って送受信する (tough-cookie ベース)。
OAuth2
アクション | 用途 |
| machine-to-machine (M2M) フロー。 |
| refresh_token フロー |
| デバイス認可フロー開始。 |
| 認可待ちをポーリング ( |
| キャッシュ済みトークンの一覧(expires_in_s 付き) |
| トークンキャッシュ全消去 |
トークンは (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]。レスポンスに attempts と retried_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環境変数
変数 | デフォルト | 用途 |
|
| per-hop タイムアウト (ms)。各 redirect hop ごとに独立して適用される。total wall-clock budget = |
|
| レスポンスボディの最大バイト数 (デフォルト 2 MiB) |
|
| 既定の User-Agent (package.json の version を反映) |
| (未設定) |
|
| (未設定) |
|
| (未設定) |
|
| (未設定) |
|
|
|
|
|
| セッションの idle TTL (ms)。これを過ぎたセッションは自動 evict |
|
| 同時に保持できるセッション数の上限 |
呼び出し例
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_ROOT、output_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: falseはHTTP_ALLOW_INSECURE_TLS=1がない限り無視 (警告ログ出力)。セッション: caller が指定した
session_idは SHA-256 でハッシュ化された値を内部で使用 (cross-leak 防止)。idle TTLHTTP_SESSION_TTLms (デフォルト 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)、downloadのoutput_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.tsのmakeError内 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)、TEXTUALregex の修正 (B7)、Buffer.fromの死コード除去 (B8)、Set-Cookie を redirect 後の最終 URL で保存 (B9)、リトライ末尾の sleep 削除 (B10)、coerceObjectJSON エラー伝播 (B11)、OAuthbody_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
undici — Node.js の HTTP/1.1 クライアント
Model Context Protocol — 仕様・SDK
ライセンス
MIT License © 2026 cUDGk — 詳細は LICENSE を参照。
Available Tools
1 toolhttpA
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.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| url | No | request/get/post/put/delete/patch/head/download/as_curl: target URL (http/https) | |
| method | No | request: HTTP method override (default GET) | |
| headers | No | request/*/as_curl: additional request headers; values must be RFC 7230 valid | |
| query | No | request/*/as_curl: query string params; arrays append multiple values | |
| body | No | request/*/as_curl: raw text body (mutually exclusive with json/form/body_base64) | |
| body_base64 | No | request/*/as_curl: binary body, base64-encoded; defaults Content-Type to application/octet-stream | |
| json | No | request/*/as_curl: JSON body; sets Content-Type application/json | |
| form | No | request/*/as_curl: form-urlencoded body | |
| basic_auth | No | request/*/as_curl: HTTP Basic credentials | |
| bearer | No | request/*/as_curl: Bearer token (printable ASCII only) | |
| timeout | No | request/*/download: per-hop timeout in ms (default HTTP_TIMEOUT, 30000). Total wall-clock budget = timeout × (max_redirects + 1). | |
| follow_redirects | No | request/*/as_curl: follow 3xx redirects (default true; cross-origin drops Authorization/Cookie) | |
| max_redirects | No | request/*: max redirect hops (default 5) | |
| reject_unauthorized | No | request/*: TLS verification toggle; false requires HTTP_ALLOW_INSECURE_TLS=1 | |
| max_body_bytes | No | request/*: response body cap (default HTTP_MAX_BODY, 2 MiB). Also overrides HTTP_DOWNLOAD_MAX for the download action (which otherwise defaults to 1 GiB). | |
| session | No | request/*: 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) | |
| retry | No | request/*: retry policy with exponential backoff (default on 502/503/504). Active only when max >= 1. | |
| output_path | No | download (REQUIRED): absolute destination path; must reside under HTTP_DOWNLOAD_ROOT; UNC paths rejected | |
| shell | No | as_curl: target shell syntax (default bash) | |
| session_id | No | session_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_url | No | oauth2_client_credentials/oauth2_refresh/oauth2_device_poll: token endpoint URL | |
| device_authorization_url | No | oauth2_device_start: device authorization endpoint URL | |
| client_id | No | oauth2_*: OAuth client id | |
| client_secret | No | oauth2_client_credentials/oauth2_refresh/oauth2_device_poll: OAuth client secret (cache key uses sha256 fingerprint, not raw secret) | |
| scope | No | oauth2_*: OAuth scope string | |
| audience | No | oauth2_client_credentials/oauth2_device_start: optional audience parameter | |
| refresh_token | No | oauth2_refresh: refresh_token to exchange | |
| device_code | No | oauth2_device_poll: device_code from oauth2_device_start | |
| auth_method | No | oauth2_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_cache | No | oauth2_client_credentials: reuse cached token if not yet expired (default true) | |
| max_wait_seconds | No | oauth2_device_poll: max polling duration in seconds (default 120) | |
| initial_interval | No | oauth2_device_poll: initial polling interval (in seconds; default 5). slow_down responses add 5 seconds each. | |
| extra_params | No | oauth2_client_credentials/oauth2_device_start: extra form params merged into the token/device request. Not supported for oauth2_refresh. |
TDQS
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.
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.
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.
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.
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.
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
Only one tool exists, so there is no ambiguity between tools. The tool's description clearly defines its purpose as an HTTP client.
With a single tool named 'http', naming consistency is trivially maintained. The name directly reflects the tool's function.
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.
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
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
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Reliable web fetching for AI agents with retry, circuit breaker, caching, and anti-bot bypass
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
Enable language models to perform advanced AI-powered web scraping with enterprise-grade reliabili…
Related MCP Servers
- AlicenseAqualityCmaintenanceWeb 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.37MIT
- AlicenseNot gradedqualityCmaintenanceProvides 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.122MIT
- AlicenseAqualityBmaintenanceEnables LLMs to make HTTP requests using structured cURL commands with support for multiple authentication methods, custom headers, and comprehensive request/response control.2163MIT
- AlicenseAqualityCmaintenanceEnables AI agents to send HTTP requests to any endpoint with full control over methods, headers, query parameters, and request bodies.117MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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