Whistle MCP Service Gateway

English | 中文

Project Overview

This service acts as an MCP bridge, enabling artificial intelligence systems to exert granular control over a local Whistle web debugging proxy. By leveraging this tool, AI can execute advanced tasks like dynamically adjusting proxy routing policies, inspecting captured network traffic, simulating request executions, and managing configuration assets without direct manual interaction with the Whistle GUI. This fundamentally streamlines sophisticated network diagnostics, API validation workflows, and proxy environment governance via intuitive conversational input.

Core Capabilities

• Policy Administration: Execute full lifecycle management for Whistle rules (creation, modification, renaming, removal, activation/deactivation).
• Grouping Semantics: Construct, rename, and dismantle rule sets; assign and relocate specific rules within these hierarchical groups.
• Asset Management: Provision, revise, rename, and retire stored value definitions, including support for structured value grouping.
• Proxy State Manipulation: Toggle core proxy services, control SSL/TLS traffic inspection (HTTPS interception), manage HTTP/2 protocol adherence, etc.
• Traffic Observation: Retrieve detailed logs of intercepted network transactions, supporting sophisticated URL pattern filtering.
• Transaction Simulation: Re-execute previously captured network interactions, optionally overriding request payload details.
• Concurrency Mode: Activate or deactivate the multi-rule execution capability.

Deployment Instructions

Automated Setup via Smithery

For seamless integration with Claude Desktop environments using Smithery:

bash npx -y @smithery/cli install @7gugu/whistle-mcp --client claude

Standard NPM Installation

Install the package globally using npm:

bash npm install -g whistle-mcp-tool

MCP Integration Configuration

Integrate the service by declaring an entry in your overarching MCP configuration manifest (JSON format):

{ "mcpServers": { "whistle-mcp": { "command": "whistle-mcp", "args": [ "--host=", "--port=" ] } } }

Parameter Specification

• host: The network address where the Whistle server is accessible. Defaults to 'localhost' if omitted.
• port: The specific port utilized by the Whistle service. Defaults to 8899 if unspecified.

AI Client Configuration Pointers

Refer to these resources for configuring your preferred AI interface to recognize this server:

• Claude Client: https://modelcontextprotocol.io/quickstart/user
• Raycast: Requires the dedicated MCP extension module.
• Cursor: Consult their documentation regarding MCP integration: https://docs.cursor.com/context/model-context-protocol#configuring-mcp-servers

Exposed MCP Functionality

The Whistle MCP Service exposes the following discrete operational endpoints callable via the MCP communication layer:

Rule Policy Operations

| Endpoint Name | Summary Description | Core Action | | :--- | :--- | :---- | | getRules | Retrieve all active and latent policies | Enumerates all stored policies and their associated scripting content | | createRule | Establish a novel policy entry | Initializes a new rule entity based on a provided identifier name | | updateRule | Modify existing policy script | Overwrites the operational body of a designated rule | | renameRule | Re-label a policy identifier | Assigns a new name to an existing rule | | deleteRule | Permanently discard a policy | Erases a specified rule from the configuration | | selectRule | Activate policy execution | Marks a specific rule for immediate enforcement | | unselectRule | Deactivate policy execution | Prevents a specific rule from being processed | | disableAllRules | System-wide policy suspension | Immediately deactivates every currently enabled policy |

Group Organization Operations

| Endpoint Name | Summary Description | Core Action | | :--- | :--- | :---- | | createGroup | Establish a new policy grouping | Formulates a container for organizing related rules | | renameGroup | Re-label a policy container | Changes the identifier name of an existing group | | deleteGroup | Remove a policy grouping structure | Eliminates a specified group entity | | moveRuleToGroup | Hierarchical relocation | Places a designated rule inside a target group | | moveRuleOutOfGroup | Flat structure promotion | Relocates a rule from its current group back to the root level |

Value Asset Operations

| Endpoint Name | Summary Description | Core Action | | :--- | :--- | :---- | | getAllValues | Inventory of all defined constants | Lists all stored values and their containing groups | | createValue | Introduce a new constant definition | Creates a new named constant/variable | | updateValue | Revise constant content | Alters the payload associated with a specified value name | | renameValue | Re-label a constant | Changes the public identifier for a stored value | | deleteValue | Purge a constant definition | Removes a specified value entry | | createValueGroup | Establish a constant grouping container | Initializes a container for organizing related values | | renameValueGroup | Re-label a constant container | Changes the identifier name of an existing value group | | deleteValueGroup | Remove a constant grouping structure | Eliminates a specified value group entity | | moveValueToGroup | Hierarchical value placement | Assigns a specified value into a designated group | | moveValueOutOfGroup | Flat structure value promotion | Relocates a value from its group to the top-level scope |

Proxy Environment Control

| Endpoint Name | Summary Description | Core Action | | :--- | :--- | :---- | | getStatus | Query proxy operational metrics | Fetches the current operational state report from the Whistle core | | toggleProxy | Service state switching | Flips the main proxy listener between enabled and disabled states | | toggleHttpsInterception | SSL/TLS Inspection toggle | Toggles the capability to decrypt and inspect secure traffic | | toggleHttp2 | HTTP/2 Protocol Switch | Activates or deactivates the server's handling of the HTTP/2 protocol | | toggleMultiRuleMode | Concurrency setting adjustment | Modifies the flag determining if multiple rules can execute concurrently |

Network Interaction Management

| Endpoint Name | Summary Description | Core Action | | :--- | :--- | :---- | | getInterceptInfo | Fetch recorded traffic data | Retrieves details of captured network events, supporting input filtering parameters | | replayRequest | Simulate past network activity | Re-sends a previously intercepted request, allowing parameter overrides |

Developer Contact

• Electronic Mail: gz7gugu@qq.com
• Professional Blog/Site: https://7gugu.com

WIKIPEDIA CONTEXTUAL NOTE: The XMLHttpRequest (XHR) object presents an interface utilizing methods to dispatch synchronous or asynchronous HTTP communications from a web browser to a designated web service endpoint. These capabilities permit browser-resident applications to solicit and receive data from a backend server post-initial page load. XHR is foundational to the Ajax programming paradigm. Prior to its widespread adoption, server interaction relied predominantly on traditional hyperlink navigation or form submissions, which typically mandated a full-page reload.

== Historical Development == The foundational concept for asynchronous web requests originated around 2000, conceived by Microsoft Outlook development teams. This idea was first realized within Internet Explorer 5 (released 1999). However, the initial invocation syntax did not use the standardized 'XMLHttpRequest' identifier; instead, developers employed COM object instantiation via ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP"). By the release of Internet Explorer 7 (2006), universal browser support for the canonical 'XMLHttpRequest' identifier was established. This standardized 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).

=== Standardization Trajectory === The World Wide Web Consortium (W3C) published the initial Working Draft specification for the XMLHttpRequest object on April 5, 2006. A subsequent Working Draft Level 2 specification was released by the W3C on February 25, 2008. Level 2 introduced enhancements such as progress event monitoring, enablement for cross-origin requests, and mechanisms for handling raw byte streams. By the close of 2011, the Level 2 features were formally merged back into the primary specification document. Development responsibilities transitioned to the WHATWG near the end of 2012, which now maintains the specification as a living document defined using Web IDL.

== Operational Procedure == Generally, executing a network inquiry using XMLHttpRequest involves a sequence of distinct programming stages:

Instantiate the XMLHttpRequest object via its constructor call: Invoke the "open" method to define the request verb, specify the target resource URI, and select synchronous or asynchronous execution mode: For asynchronous operations, register an event handler callback function to be executed upon state transitions: Commence the transmission by executing the "send" method: Process the status changes within the registered event listener. Upon successful receipt of server data, this information is typically held within the "responseText" attribute. When the object completes processing the response, its state transitions to 4, signifying 'done': Beyond these foundational steps, XMLHttpRequest offers extensive configuration options for request transmission control and response parsing. Custom HTTP headers can be appended to tailor server behavior, and payload data can be transmitted during the "send" call. The received response can be parsed directly into native JavaScript objects if formatted as JSON, or processed incrementally as data arrives instead of awaiting full buffer completion. Furthermore, transactions can be terminated prematurely or assigned a time-out threshold.

== Cross-Origin Restrictions == During the nascent period of the World Wide Web, limitations were soon identified that made it possible to breach s