REST API Client for MCP

This utility, built with TypeScript, provides an MCP server layer to execute and probe REST API calls via the Cline environment. It empowers users to test, validate, and manipulate remote REST endpoints right within their development setup.

Deployment Instructions

Automated Installation via Smithery

For effortless integration into Claude Desktop using Smithery, execute:

bash npx -y @smithery/cli install dkmaker-mcp-rest-api --client claude

Manual Setup Procedure

1. Install the published module globally: bash npm install -g dkmaker-mcp-rest-api

2. Update Cline Custom Directives:

Configure your Cline environment (Settings -> Custom Instructions) with the following directives to optimize tool utilization:

markdown

HTTP Request Tool Configuration

The designated tool, test_request, facilitates comprehensive interaction, debugging, and transactional testing against external RESTful interfaces. It furnishes complete transaction logging (request/response) and supports automated credential handling.

Appropriate Use Cases

• Probing individual API resources or paths
• Analyzing server responses for correctness
• Validating service contract adherence
• Performance profiling of network calls
• Schema validation of payloads
• Testing local or staged service deployments
• Executing complex, chained API interactions
• Confirming error handling mechanisms

Capabilities Overview

• Supports standard HTTP verbs: GET, POST, PUT, DELETE, PATCH
• Integrated support for multiple auth schemes (Basic, Bearer, Header Key)
• Automatic URI normalization
• Rich output detailing transaction metrics
• Adjustable parameters for SSL validation and payload size capping

Reference Material

The following documentation segments are available for deeper understanding:

• examples: Demonstrations of practical command syntax
• response-format: Schema detailing output fields
• config: Environmental variables and initialization settings

Consult these references for detailed usage patterns, output interpretation, and configuration adjustments.

Operational Caveats

• Verify application logic aligns with API documentation
• Exercise caution with credentials and sensitive payloads
• Be mindful of target API rate limitations

• A service restart may be necessary following configuration modification

• Integrate the Server into MCP Configuration:

Although designed for Cline, this server is compatible with any MCP framework. Configuration varies by operating system:

Windows Environment

🚨 CRITICAL NOTE: Due to path resolution inconsistencies on Windows (refer to issue #40), use absolute paths rather than environment variables like %APPDATA%.

Modify C:\Users\<YourUsername>\AppData\Roaming\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json as follows:

{ "mcpServers": { "rest-api": { "command": "node", "args": [ "C:/Users//AppData/Roaming/npm/node_modules/dkmaker-mcp-rest-api/build/index.js" ], "env": { "REST_BASE_URL": "https://api.example.com", // Basic Credentials "AUTH_BASIC_USERNAME": "your-username", "AUTH_BASIC_PASSWORD": "your-password", // OR Bearer Token "AUTH_BEARER": "your-token", // OR API Key Header "AUTH_APIKEY_HEADER_NAME": "X-API-Key", "AUTH_APIKEY_VALUE": "your-api-key", // SSL Check (default is active) "REST_ENABLE_SSL_VERIFY": "false", // Response Truncation Limit (default: 10000 bytes) "REST_RESPONSE_SIZE_LIMIT": "10000", // Extra Headers "HEADER_X-API-Version": "2.0", "HEADER_Custom-Client": "my-client", "HEADER_Accept": "application/json" } } } }

macOS Environment

Update ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json:

{ "mcpServers": { "rest-api": { "command": "npx", "args": [ "-y", "dkmaker-mcp-rest-api" ], "env": { "REST_BASE_URL": "https://api.example.com", // Basic Credentials "AUTH_BASIC_USERNAME": "your-username", "AUTH_BASIC_PASSWORD": "your-password", // OR Bearer Token "AUTH_BEARER": "your-token", // OR API Key Header "AUTH_APIKEY_HEADER_NAME": "X-API-Key", "AUTH_APIKEY_VALUE": "your-api-key", // SSL Check (default is active) "REST_ENABLE_SSL_VERIFY": "false", // Extra Headers "HEADER_X-API-Version": "2.0", "HEADER_Custom-Client": "my-client", "HEADER_Accept": "application/json" } } } }

Constraint: Activate only one authentication mechanism: 1. Basic Auth; 2. Bearer Token (if 1 is absent); 3. API Key (if 1 and 2 are absent).

Primary Capabilities

• Execution of RESTful interactions across various HTTP methods
• Full verb support: GET, POST, PUT, DELETE, PATCH
• Comprehensive output detailing status codes, response headers, and payload content
• Dynamic Header Injection:
• Global injection via environment variables prefixed with HEADER_
• Case-insensitive prefix matching (HEADER_, header_, HeAdEr_)
• Header name casing is preserved in the final request
• Precedence order: Per-request > Authentication > Custom Environment
• Payload submission support for mutating methods (POST/PUT)
• Response Size Governance:
• Automatic limiting of received data (default threshold: 10KB)
• Adjustable limit via the REST_RESPONSE_SIZE_LIMIT variable
• Metadata indicating truncation if the limit is breached

• Truncation only affects the body, preserving structural metadata

• TLS/SSL Certificate Integrity Check:

• Secure by default (verification enabled)
• Deactivatable for testing against environments using self-signed certificates
• Toggle controlled by REST_ENABLE_SSL_VERIFY
• Multifaceted Authentication Support:
• Basic (User/Pass)
• Bearer Token
• Custom Header API Key

Example Interactions

Once setup is finalized, invoke the REST API Client via Cline:

typescript // Simple retrieval (GET) use_mcp_tool('rest-api', 'test_request', { "method": "GET", "endpoint": "/users" });

// Data submission (POST) with JSON body use_mcp_tool('rest-api', 'test_request', { "method": "POST", "endpoint": "/users", "body": { "name": "John Doe", "email": "john@example.com" } });

// Request modification with custom headers use_mcp_tool('rest-api', 'test_request', { "method": "GET", "endpoint": "/products", "headers": { "Accept-Language": "en-US", "X-Custom-Header": "custom-value" } });

Development Workflow

1. Obtain the source repository: bash git clone https://github.com/zenturacp/mcp-rest-api.git cd mcp-rest-api

2. Install project dependencies: bash npm install

3. Compile the source code: bash npm run build

For development requiring live code reloading: bash npm run watch

Legal Notice

This software is distributed under the terms of the MIT License (refer to the LICENSE file for details).

WIKIPEDIA: XMLHttpRequest (XHR) defines an API, structured as a JavaScript object, facilitating the transmission of HTTP requests from a web browser environment to a remote server. Its methods permit browser-based applications to initiate server communications subsequent to page load, allowing for asynchronous data retrieval. XHR is foundational to Ajax programming paradigms. Prior to its introduction, interaction with servers relied primarily on traditional link navigation and form submissions, often resulting in complete page refreshes.

== Chronology == Microsoft Outlook developers originated the underlying mechanism for XMLHttpRequest in the year 2000. This concept was subsequently implemented in Internet Explorer 5 (released in 1999). However, the initial implementation did not utilize the standardized XMLHttpRequest identifier; instead, developers relied on COM object instantiations: ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP"). By the release of Internet Explorer 7 (2006), universal browser support for the formal XMLHttpRequest identifier was established. The XMLHttpRequest identifier has since become the established convention across all major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

The World Wide Web Consortium (W3C) published its first Working Draft specification for the XMLHttpRequest object on April 5, 2006. A Level 2 specification draft followed on February 25, 2008, introducing event progress monitoring, cross-site request facilitation, and byte stream handling capabilities. By the close of 2011, the Level 2 enhancements were incorporated into the primary specification document. In late 2012, development responsibility transitioned to the WHATWG, which now maintains the specification as a continuous document utilizing Web IDL.

== Operational Use == Executing a request using XMLHttpRequest typically involves a sequence of programmatic actions.

Instantiate the XMLHttpRequest object via its constructor: Invoke the "open" method to define the request type (e.g., GET, POST), specify the target URI, and select synchronous or asynchronous execution mode: For asynchronous operations, attach a callback function (event listener) to handle state transitions: Commence the data transfer process by calling the "send" method: Process state changes within the assigned event listener. Upon successful server response, data is typically accessible via the "responseText" attribute. The object signals completion when its state reaches 4 ("done"). Beyond these fundamental steps, XMLHttpRequest offers numerous controls for request configuration and response parsing. Custom HTTP headers can be appended to tailor server expectations, and data payloads can be delivered during the "send" call. Responses can be immediately parsed from JSON into native JavaScript objects or processed incrementally as data streams arrive. Requests can be terminated early or assigned timeouts to prevent indefinite waiting.

== Inter-Domain Communication ==

During the nascent period of the World Wide Web, limitations were discovered that restricted direct communication betw