Skip to main content
Glama
cUDGk

http-mcp

by cUDGk

http

Make HTTP requests with OAuth2 authentication, cookie sessions, retry logic, and cURL command generation.

Instructions

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.

Input Schema

TableJSON 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.
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.

Install Server

Other Tools

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