Click on "Deploy 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 MCP Server GET https://jsonplaceholder.typicode.com/posts/1"
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.
A Model Context Protocol (MCP) server that enables AI agents to send HTTP requests to any endpoint with full control over methods, headers, query parameters, and request bodies.
Note: This MCP server only supports stdio transport.
Support for major HTTP methods (GET, POST, PUT, PATCH, DELETE, QUERY)
Custom headers configuration
Query parameter handling with proper URL encoding
Request body support for POST/PUT/PATCH/QUERY
Comprehensive error handling
TypeScript with strict type safety
Clean, modular architecture
STDIO transport support for seamless integration with MCP clients
Install the package globally using npm:
npm install -g @jules-tnk/ts-http-mcpOr use npx to run it directly:
npx @jules-tnk/ts-http-mcpAdd the following configuration to your Claude Desktop config file (claude_desktop_config.json):
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
{
"mcpServers": {
"http-mcp": {
"command": "npx",
"args": ["@jules-tnk/ts-http-mcp"]
}
}
}After updating the configuration, restart Claude Desktop to load the MCP server.
Related MCP server: API Request MCP Server
For other MCP clients that support stdio transport, configure them to run:
npx @jules-tnk/ts-http-mcppnpm installpnpm buildpnpm startTo test the MCP server locally, you can run it directly and interact with it through stdio:
pnpm startThe server will start and listen for MCP protocol messages on stdin/stdout.
Once configured with your MCP client, the HTTP MCP server provides the following capabilities:
GET requests: Retrieve data from any HTTP endpoint
QUERY requests: Send safe, idempotent requests with request bodies
POST requests: Send data to endpoints that accept POST requests
PUT/PATCH requests: Update resources on remote servers
DELETE requests: Remove resources from remote servers
Custom headers: Add authentication, content-type, and other headers
Query parameters: Include URL parameters with proper encoding
Request bodies: Send JSON, form data, or raw content for supported body-capable methods
The server handles all the HTTP communication details, error handling, and response processing, making it easy for AI agents to interact with web APIs and services.
MIT License - see the LICENSE.md file for details.
Send an HTTP request to any endpoint with custom headers, query parameters, and body
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full URL to send the request to (including path parameters) | |
| body | No | Request body (for POST, PUT, PATCH, and QUERY methods) | |
| method | Yes | HTTP method to use | |
| headers | No | HTTP headers to include in the request | |
| queryParams | No | Query parameters to append to the URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention potential side effects (e.g., sending data to external servers, network access requirements, timeouts, or error handling), leaving the agent without a clear safety/profile picture.
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 a single, compact sentence that gets straight to the point. It front-loads the verb and resource and includes the key customization features without any fluff.
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?
The description lacks information about the response format or return value, which is significant given the absence of an output schema. It also omits details about error conditions or limitations, making it incomplete for an agent to fully anticipate the tool's behavior.
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?
The description mentions custom headers, query parameters, and body, which aligns with the schema, but doesn't add syntax or format details. Since the schema already documents all parameters with 100% coverage, the description provides minimal additional value beyond a high-level summary.
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 the tool's function: sending an HTTP request to any endpoint, listing the key customization options (headers, query params, body). It uses a specific verb and resource, and with no sibling tools, there is no need for differentiation.
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?
The description implies the tool is for general HTTP requests but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Given the lack of sibling tools, the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0send_http_requestScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clear and unambiguous.
The single tool follows a clear verb_noun convention, and the name accurately describes its function. Consistency is trivially maintained.
One tool is appropriate for a server dedicated solely to HTTP requests. While the count is below the typical range, it is not excessive or deficient for the narrow scope.
The tool supports full HTTP request customization, covering all methods and parameters. There are no obvious missing operations within the domain of making HTTP requests.
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Give your AI agents the tools to build, manage, and run automation workflows.
Instant no-signup webhook & HTTP-request inspector for testing webhooks and agent tool-callbacks.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
