Skip to main content
Glama
sixees
by sixees

cURL MCP Server

A security-hardened MCP server that gives LLMs the ability to make HTTP requests via cURL. Use it as a standalone server, extend it programmatically, or define APIs declaratively with YAML.

Key features:

  • Security-first — SSRF protection, DNS rebinding prevention, rate limiting, input validation

  • ExtensibleMcpCurlServer class with hooks, custom tools, and configuration

  • YAML-driven — Define API endpoints declaratively and generate MCP tools automatically

  • Two toolscurl_execute for HTTP requests, jq_query for querying saved JSON files

Quick Start: MCP Server

Claude Code

claude mcp add curl -- npx -y github:sixees/mcp-curl

Or add to .mcp.json:

{
  "mcpServers": {
    "curl": {
      "command": "npx",
      "args": [
        "-y",
        "github:sixees/mcp-curl"
      ]
    }
  }
}

Claude Desktop

Add to your config file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "curl": {
      "command": "npx",
      "args": [
        "-y",
        "github:sixees/mcp-curl"
      ]
    }
  }
}

Related MCP server: curl-mcp

Quick Start: Standalone

# Stdio transport (default)
npx -y github:sixees/mcp-curl

# HTTP transport
TRANSPORT=http PORT=3000 npx -y github:sixees/mcp-curl

# HTTP with authentication
TRANSPORT=http PORT=3000 MCP_AUTH_TOKEN=your-secret npx -y github:sixees/mcp-curl

Or clone and build locally:

git clone https://github.com/sixees/mcp-curl.git
cd mcp-curl && npm install && npm run build
npm start

Tools

curl_execute

Execute HTTP requests with structured parameters. Supports all common HTTP methods, authentication (basic, bearer), headers, form data, redirects, and timeouts.

{
  "url": "https://api.github.com/users/octocat",
  "bearer_token": "ghp_xxx",
  "jq_filter": ".name,.email,.location"
}

Responses exceeding max_result_size (default 500KB) are automatically saved to file. Use jq_filter to extract specific data before the size limit is checked.

jq_query

Query saved JSON files without making new HTTP requests:

{
  "filepath": "/path/to/saved_response.txt",
  "jq_filter": ".users[0:5]"
}

Files must be in the temp directory, MCP_CURL_OUTPUT_DIR, or current working directory.

jq_filter syntax

Syntax

Example

Description

.key

.data

Object property

.[n] or .n

.[0], .0

Array index (non-negative only)

.[n:m]

.[0:10]

Array slice

.["key"]

.["special-key"]

Bracket notation

.a,.b,.c

.name,.email

Multiple paths (returns array)

.key[]

.items[]

Array passthrough (must be last)

This is a path extractor, not jq. The jq expression language — pipes, object construction, and functions (| {id}, map(...), select(...), length) — is not supported and is rejected with an error naming the offending syntax. Iterate-and-project (.items[].id) is rejected too; use an explicit index (.items[0].id) or a slice (.items[0:20]). To reshape or aggregate a response, save it (save_to_file) and post-process it with real jq outside the server.

Programmatic API

Install as a library and build custom MCP servers:

npm install mcp-curl
import { McpCurlServer } from "mcp-curl";

const server = new McpCurlServer()
    .configure({
        baseUrl: "https://api.example.com",
        defaultHeaders: {"Authorization": `Bearer ${process.env.API_TOKEN}`},
        defaultTimeout: 60,
    })
    .beforeRequest((ctx) => {
        console.log(`${ctx.tool}: ${ctx.params.url}`);
    })
    .afterResponse((ctx) => {
        console.log(`Response: ${ctx.response.length} bytes`);
    });

await server.start("stdio");

See the library documentation for the full API reference, including hooks, custom tools, instance utilities, and lifecycle management.

Sanitizing externally-sourced field descriptions

registerCustomTool() sanitizes title, description, and every .describe() string inside inputSchema automatically — recursing through nested z.object(), z.array(), z.union() / z.discriminatedUnion(), z.tuple(), z.record() / z.map(), z.set(), z.intersection(), z.lazy(), .transform() / .pipe(), and through z.optional() / z.default() / z.nullable() / .readonly() / .catch() / z.promise() wrappers. The walker mutates z.globalRegistry in place, preserving every Zod runtime invariant (.refine() / .check() chains, .strict() / .passthrough() modes, array length constraints, factory defaults, ZodDiscriminatedUnion discriminators). You don't need to call sanitizeDescription() manually.

The example below applies sanitizeDescription() defensively at the call site as well — it's optional: registration-time sanitisation already covers every depth. Use it as belt-and-suspenders when wiring untrusted strings (database rows, remote APIs, user-authored YAML) into Zod descriptions.

import { z } from "zod";
import { sanitizeDescription } from "mcp-curl";

// `server` is the McpCurlServer instance from the example above.
const fieldMeta = await fetchFieldDescriptionsFromDb();

server.registerCustomTool(
    "search_records",
    {
        title: "Search records",            // sanitized internally
        description: "Search the catalog.", // sanitized internally
        inputSchema: z.object({
            // sanitizeDescription() here is defensive — registerCustomTool() also
            // sanitises every .describe() string at every depth at registration time.
            q: z.string().describe(sanitizeDescription(fieldMeta.q)),
            limit: z.number().int().min(1).max(100)
                .describe(sanitizeDescription(fieldMeta.limit)),
        }),
    },
    async (params) => { /* handler logic */ }
);

For trusted internal strings, no sanitization is required. See docs/custom-tools.md for the full discussion.

YAML Schema

Define API endpoints declaratively and generate MCP tools:

import { createApiServer } from "mcp-curl";

const server = await createApiServer({
    definitionPath: "./my-api.yaml",
});
await server.start("stdio");
apiVersion: "1.0"
api:
  name: my-api
  baseUrl: https://api.example.com
endpoints:
  - id: list_items
    path: /items
    method: GET
    title: List Items
    description: Get all items
    parameters:
      - name: page
        in: query
        type: integer
        required: false

See YAML Schema Reference for the full specification including authentication, defaults, response filtering, and parameter types.

Fork Workflow

If you fork this repo to build an API-specific server, use the configs/ directory for your definitions:

# 1. Fork and clone
git clone https://github.com/your-org/mcp-curl.git
cd mcp-curl && npm install && npm run build

# 2. Copy the template
cp configs/example.yaml.template configs/my-api.yaml

# 3. Edit your API definition
# See docs/api-schema.md for the full YAML specification

# 4. Create your entry point (configs/*.ts is gitignored)
#    See configs/README.md for a full TypeScript template

# 5. Run your server (using tsx to run the TS file directly)
npx tsx configs/my-api.ts

Files in configs/ matching *.yaml, *.yml, *.ts, *.js are gitignored, so pulling upstream changes (git pull upstream main) won't conflict with your application-specific configuration.

Alternatively, install mcp-curl as an npm dependency in a separate project — see Getting Started.

Security Highlights

  • SSRF protection — blocks private IPs, cloud metadata endpoints, DNS rebinding services, internal TLDs

  • DNS rebinding prevention — DNS resolved before validation, cURL pinned to validated IP via --resolve

  • Protocol whitelist — only http:// and https:// allowed; file://, ftp://, data:, javascript:, etc. blocked at the schema layer (createHttpOnlyUrlSchema), the SSRF layer, and via cURL --proto

  • Rate limiting — 60 req/min per host, 300 req/min per client

  • Input validation — Zod schemas, CRLF injection prevention, --data-raw/--form-string to block @ file reads

  • No shell execution — commands spawned via spawn() without shell; allowlist permits only curl

  • File access controljq_query restricted to temp dir, MCP_CURL_OUTPUT_DIR, and cwd; symlinks resolved

  • Resource limits — 10MB response cap, 100MB global memory, 100ms jq parse timeout, 30s default request timeout, 256 KB HTML/markdown strip cap

  • Secure file permissions — temp dirs 0o700, files 0o600 (owner-only)

  • Localhost port restrictions — when MCP_CURL_ALLOW_LOCALHOST=true, only ports 80, 443, and any port > 1024 are reachable; ports 1–1024 (other than 80/443) stay blocked even with the flag set, to prevent the LLM from reaching SSH (22), SMTP (25), DNS (53), etc.

  • Auth-token validationMCP_AUTH_TOKEN rejected at HTTP startup if not printable ASCII (0x20–0x7E) or longer than 4096 chars; the rejected token is never echoed in error messages; bearer comparison is timing-safe (crypto.timingSafeEqual over length-padded buffers); the Bearer scheme is matched case-insensitively per RFC 6750 §2.1

  • YAML pre-sanitisation invariantloadApiSchema(), loadApiSchemaFromString(), validateApiSchema(), AND the directly-re-exported ApiSchemaValidator.parse() all run a single z.preprocess() step that sanitises every user-facing string field before Zod validates structure, so attacker-controlled bidi/zero-width bytes never reach the LLM and never appear in Zod error messages

  • Custom-tool input-schema sanitisationregisterCustomTool() walks inputSchema and sanitises every .describe() string at every depth in place via Zod's globalRegistry (recurses through ZodObject, ZodArray, ZodUnion/ZodDiscriminatedUnion, ZodTuple, ZodRecord/ZodMap, ZodSet, ZodIntersection, ZodPipe, ZodLazy, and through ZodOptional/ZodDefault/ZodNullable/ZodReadonly/ZodCatch/ZodPromise wrappers); all Zod runtime invariants preserved

  • Defence-in-depth response wrap — every tool result (curl_execute, jq_query, YAML endpoints, custom tools, hook short-circuit returns) routes through a single internal post-processor that runs detect-on-original → sanitise → optional spotlight on each text part; idempotent via a module-private (non-Symbol.for) tag; fail-open with throttled [wrap-error] log

  • Response sanitisation — Unicode attack chars (bidi overrides, zero-width family, "Sneaky Bits" Variation Selector Supplement, Braille blank, Hangul fillers, Mongolian invisibles, Arabic Letter Mark, …) stripped from text responses; visual-space-padding runs (50+ tabs / NBSP / em-spaces / IDEOGRAPHIC SPACE) and newline runs (20+, with single inline-whitespace interrupters tolerated) collapsed before reaching the LLM; idempotence loop (≤4 iterations) defeats (49 spaces + ZWSP) × N interleaving

  • HTML / Markdown content stripping<script> and <style> blocks removed from HTML/XHTML/SVG/*+xml responses (ReDoS-hardened with bounded fixed-point stripping, numeric-entity decode inside the loop, 256 KB cap); body-shape sniffer catches markup served under tampered Content-Type; Markdown image beacons and external-URL links replaced with [image removed] / [link removed]; dangerous-scheme URLs (javascript:, vbscript:, file:, data:) blocked in Markdown links and images, including the [![safe](http://x)](javascript:...) nesting case

  • Injection-detection signal[injection-defense] [hostname] InjectionDetected logged to stderr (throttled 60s per hostname) when a NFKC-normalised regex matches the original response text; observability only — never refuses, redacts, or alters content

Environment Variables

Variable

Description

TRANSPORT

Transport mode: stdio (default) or http

PORT

HTTP transport port (default: 3000)

MCP_AUTH_TOKEN

Bearer token for HTTP transport auth (printable ASCII, ≤4096)

MCP_CURL_OUTPUT_DIR

Default directory for saved responses

MCP_CURL_ALLOW_LOCALHOST

Set true to allow localhost requests

MCP_CURL_HOST

HTTP transport bind address (default: 127.0.0.1)

MCP_CURL_ALLOWED_ORIGINS

Comma-separated origins for HTTP Origin header validation

MCP_CURL_USER_AGENT

Default User-Agent for every request (empty string disables)

MCP_CURL_REFERER

Default Referer for every request (empty string disables)

Documentation

Guide

Description

Library Overview

McpCurlServer class and YAML usage patterns

Getting Started

Step-by-step setup guide

Configuration

All configuration options

Hooks

Request/response interception

Custom Tools

Creating custom MCP tools

YAML Schema Reference

API definition format

Examples

Working example projects in examples/:

MCP Resources & Prompts

  • Resource: curl://docs/api — Built-in API documentation

  • Prompts: api-test (test an endpoint), api-discovery (explore a REST API)

License

MIT

Available Tools

2 tools
curl_executeExecute cURL RequestA

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:

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

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

TDQS

A4.7/5.0
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.

jq_queryQuery JSON FileA
Read-onlyIdempotent

Query an existing JSON file with a jq-like filter expression.

This tool allows you to extract data from saved JSON files without making new HTTP requests. Useful for:

  • Extracting different fields from a large saved response

  • Applying multiple queries to the same data

  • Processing any local JSON file within allowed directories

Args:

  • filepath (string, required): Path to a JSON file to query

  • jq_filter (string, required): JSON path filter expression

  • max_result_size (number): Max bytes inline (default: 500KB, max: 1MB)

  • save_to_file (boolean): Force save result to file

  • output_dir (string): Custom directory to save result files

Filter Syntax:

  • .key - Get object property

  • .[n] - Get array element at index n (non-negative only, also .n with dot notation)

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

  • .["key"] - Bracket notation for keys with special chars

  • .name,.email - Multiple comma-separated paths (returns array of values, max 20)

  • Note: Negative indices not supported (unlike real jq)

Security:

  • Only files in these directories can be read:

    1. Our temp directory (files saved by curl_execute)

    2. MCP_CURL_OUTPUT_DIR environment variable path

    3. Current working directory and ALL subdirectories (broad - ensure cwd is safe)

  • Maximum file size: 10MB

Examples:

  • Extract name: { "filepath": "/path/to/response.txt", "jq_filter": ".name" }

  • Multiple fields: { "filepath": "/path/to/data.json", "jq_filter": ".name,.email,.id" }

  • Array slice: { "filepath": "/path/to/list.json", "jq_filter": ".items[0:5]" }

ParametersJSON Schema
NameRequiredDescriptionDefault
filepathYesPath to a JSON file to query. Must be in temp directory, MCP_CURL_OUTPUT_DIR, or current working directory.
jq_filterYesJSON path filter expression. 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.
max_result_sizeNoMax bytes to return inline (default: 500KB, max: 1MB). Larger results auto-save to file
save_to_fileNoForce save result to file. Returns filepath instead of content
output_dirNoDirectory to save result files (must exist and be writable)

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare read-only, non-destructive, idempotent, closed world. Description adds security path restrictions, max file size (10MB), auto-save behavior for large results, and filter limitations (no negative indices). No contradictions.

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?

Well-structured with sections: purpose, use cases, args, filter syntax, security, examples. Slightly long but all content is relevant. Front-loaded with purpose.

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?

Covers all 5 parameters, filter syntax, security constraints, size limits, examples, and behavioral details. No output schema, but return behavior (inline vs file) is explained.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds detailed filter syntax with examples, security path rules, and default behaviors for max_result_size and save_to_file. This goes beyond schema descriptions.

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 'Query an existing JSON file with a jq-like filter expression.' It distinguishes from sibling tool curl_execute by noting it avoids new HTTP requests. The verb 'query' and resource 'JSON file' are specific.

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 lists use cases: extracting fields from saved responses, multiple queries, processing local files. It implicitly suggests use after HTTP fetch but lacks explicit 'when not to use' or direct alternative comparison beyond the sibling name.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv3.1.0
    • Changedcurl_execute10 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / form / propertyNames
        Added value: +{
        +  "type": "string"
        +}
      • addedInput schema / properties / headers / propertyNames
        Added value: +{
        +  "type": "string"
        +}
      • addedInput schema / properties / jq_filter
        Added value: +{
        +  "description": "JSON 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.",
        +  "type": "string"
        +}
      • addedInput schema / properties / max_result_size
        Added value: +{
        +  "description": "Max bytes to return inline (default: 500KB, max: 1MB). Larger responses auto-save to temp file",
        +  "maximum": 1000000,
        +  "minimum": 1000,
        +  "type": "integer"
        +}
      • addedInput schema / properties / output_dir
        Added value: +{
        +  "description": "Directory to save response files (must exist and be writable). Overrides MCP_CURL_OUTPUT_DIR env var. Falls back to system temp directory.",
        +  "type": "string"
        +}
      • addedInput schema / properties / save_to_file
        Added value: +{
        +  "description": "Force save response to temp file. Returns filepath instead of content",
        +  "type": "boolean"
        +}
      • removedInput schema / properties / timeout / default
        Removed value: -30
      • changedInput schema / properties / url / description
        Previous value: -"The URL to request"New value: +"The URL to request (http or https)"
      • changedInput schema / properties / user_agent / description
        Previous value: -"Custom User-Agent header"New value: +"Custom User-Agent header. If not set, a browser-like User-Agent is sent automatically. Set to empty string to disable."
    • Addedjq_query
  2. 1 tool updatev1.0.0
    • First observedcurl_execute

TDQS

A4.5/5.0
Disambiguation5/5

The two tools have completely distinct purposes: curl_execute handles HTTP requests, while jq_query queries saved JSON files. There is no functional overlap, making selection unambiguous.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern in snake_case (curl_execute, jq_query). The style is uniform, promoting predictability.

Tool Count3/5

With only two tools, the server feels minimal for its intended scope. While it covers core HTTP request and JSON querying functionality, additional tools (e.g., manage saved files, list responses) could enhance the surface without overloading it.

Completeness3/5

The curl_execute tool is comprehensive for HTTP requests, but the server lacks auxiliary tools such as file management (list, delete saved files) or a way to retrieve response metadata separately. This leaves minor but notable gaps for certain workflows.

Maintenance

ActivityMaintained
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
    D
    maintenance
    Enables LLMs to make HTTP requests with OAuth2, session cookies, retry logic, and cURL command generation, while providing security features like SSRF protection and TLS enforcement.
    1
    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/sixees/mcp-curl'

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