Skip to main content
Glama
sixees
by sixees

Execute cURL Request

curl_execute

Execute HTTP requests with structured cURL parameters, supporting authentication, custom headers, form data, and JSON path filtering for targeted data extraction.

Instructions

Execute an HTTP request using cURL with structured parameters.

This tool provides a safe, structured way to make HTTP requests with common cURL options. It handles URL encoding, header formatting, and response processing automatically.

Args:

  • url (string, required): The URL to request

  • method (string): HTTP method - GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS

  • headers (object): HTTP headers as key-value pairs

  • data (string): Request body for POST/PUT/PATCH requests

  • form (object): Form data as key-value pairs (multipart/form-data)

  • follow_redirects (boolean): Follow HTTP redirects (default: true)

  • max_redirects (number): Maximum redirects to follow (0-50)

  • insecure (boolean): Skip SSL verification (default: false)

  • timeout (number): Request timeout in seconds (1-300, default: 30)

  • user_agent (string): Custom User-Agent header (a browser-like default is sent automatically if not set; empty string disables)

  • basic_auth (string): Basic auth as "username:password"

  • bearer_token (string): Bearer token for Authorization header

  • verbose (boolean): Include verbose request/response details

  • include_headers (boolean): Include response headers in output

  • compressed (boolean): Request compressed response (default: true)

  • include_metadata (boolean): Wrap response in JSON with metadata

  • jq_filter (string): JSON path filter to extract specific data

  • max_result_size (number): Max bytes to return inline (default: 500KB, max: 1MB). Auto-saves to file when exceeded

  • save_to_file (boolean): Force save response to temp file. Returns filepath instead of content

  • output_dir (string): Custom directory to save files (overrides MCP_CURL_OUTPUT_DIR env var)

jq_filter Syntax:

  • .key - Object property access

  • .[n] or .n - Array index (non-negative only, e.g., .results.0)

  • .[n:m] - Array slice from index n to m

  • .["key"] - Bracket notation for special characters in keys

  • .a,.b,.c - Multiple comma-separated paths (returns array of values, max 20)

jq_filter Validation:

  • Unclosed quotes and brackets throw clear errors

  • Leading zeros in indices rejected (use .0 not .00)

  • Negative indices not supported (unlike real jq)

  • Indices must be within safe integer range

Returns: The HTTP response body, or JSON with metadata if include_metadata is true: { "success": boolean, "exit_code": number, "response": string, "stderr": string (if present), "saved_to_file": boolean (if response was saved), "filepath": string (path to saved file) }

Examples:

  • Simple GET: { "url": "https://api.example.com/data" }

  • POST JSON: { "url": "https://api.example.com/users", "method": "POST", "headers": {"Content-Type": "application/json"}, "data": "{"name": "John"}" }

  • With auth: { "url": "https://api.example.com/secure", "bearer_token": "your-token-here" }

  • Extract field: { "url": "https://api.github.com/repos/octocat/hello-world", "jq_filter": ".name" }

  • Multiple fields: { "url": "https://api.example.com/user", "jq_filter": ".name,.email,.id" }

  • Dot notation: { "url": "https://api.example.com/items", "jq_filter": ".results.0.name" }

  • Array slice: { "url": "https://api.example.com/items", "jq_filter": ".results[0:10]" }

  • Custom output: { "url": "https://api.example.com/large", "save_to_file": true, "output_dir": "/path/to/dir" }

Error Handling:

  • Returns error message if cURL fails or times out

  • Exit code 0 indicates success

  • Non-zero exit codes indicate various cURL errors

  • Invalid JSON with jq_filter returns error with response preview

Temp File Lifecycle: Files saved with save_to_file or auto-save are:

  • Stored in a secure temp directory (owner-only access: 0o700/0o600)

  • Deleted on graceful server shutdown (SIGINT/SIGTERM)

  • Orphaned files from crashed sessions are cleaned on next server start

  • Check mcp-curl-* in system temp dir if files persist after crash

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to request (http or https)
methodNoHTTP method (defaults to GET, or POST if data is provided)
headersNoHTTP headers as key-value pairs (e.g., {"Content-Type": "application/json"})
dataNoRequest body data (for POST/PUT/PATCH). Use JSON string for JSON payloads
formNoForm data as key-value pairs (uses multipart/form-data)
follow_redirectsNoFollow HTTP redirects (default: true)
max_redirectsNoMaximum number of redirects to follow
insecureNoSkip SSL certificate verification (default: false)
timeoutNoRequest timeout in seconds (default: 30, max: 300)
user_agentNoCustom User-Agent header. If not set, a browser-like User-Agent is sent automatically. Set to empty string to disable.
basic_authNoBasic authentication in format 'username:password'
bearer_tokenNoBearer token for Authorization header
verboseNoInclude verbose output with request/response details
include_headersNoInclude response headers in output
compressedNoRequest compressed response and automatically decompress
include_metadataNoWrap response in JSON with metadata (exit code, success status)
jq_filterNoJSON path filter to extract specific data. Supports: .key, .[n] or .n (non-negative array index), .[n:m] (slice), .["key"] (bracket notation), .a,.b (multiple comma-separated paths return array, max 20). Negative indices not supported. Applied after response, before max_result_size check.
max_result_sizeNoMax bytes to return inline (default: 500KB, max: 1MB). Larger responses auto-save to temp file
save_to_fileNoForce save response to temp file. Returns filepath instead of content
output_dirNoDirectory to save response files (must exist and be writable). Overrides MCP_CURL_OUTPUT_DIR env var. Falls back to system temp directory.
Behavior5/5

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

The description goes well beyond annotations, detailing automatic URL encoding, header formatting, response processing, error handling with exit codes, temp file lifecycle, and defaults like user-agent and method selection. No contradictions with annotations.

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 sections (Args, jq_filter Syntax, Examples, Error Handling, Temp File Lifecycle). It front-loads purpose and organizes information logically, though it could be slightly more concise.

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

Completeness5/5

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

Given the tool's complexity (20 parameters), the description thoroughly covers all aspects: return format, error handling, temp file lifecycle, jq_filter syntax with validation, and multiple examples. No output schema is needed as the description explains the response structure.

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?

Despite 100% schema coverage, the description adds significant value with examples, detailed jq_filter syntax, default behavior explanations (e.g., method defaults to POST if data provided), and clarifications on auto-saving to file. It enriches understanding beyond the schema.

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 first sentence clearly states 'Execute an HTTP request using cURL with structured parameters', specifying the verb and resource. It distinguishes from sibling jq_query by focusing on HTTP requests rather than JSON querying.

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?

The description provides clear context for when to use the tool: making safe, structured HTTP requests. It offers examples and explains default behaviors, but does not explicitly contrast with alternatives or provide when-not-to-use guidance.

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/sixees/mcp-curl'

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