BrowserLogAggregator: An MCP Bridge for Cursor IDE

This application captures operational logs emitted by a web browser's developer console and forwards them to the Cursor IDE utilizing the Model Context Protocol (MCP) framework.

System Components Overview

This solution comprises three interconnected parts:

1. A dedicated backend service engineered to ingest and buffer console outputs.
2. An MCP server component responsible for exposing the collected log data to the Cursor application.
3. A small browser add-on designed to transmit real-time console events to the aggregation service.

Deployment Procedures

Backend Service Initialization

1. Obtain the source code repository:

bash git clone https://github.com/mgsrevolver/consolespy.git cd consolespy

1. Install required Node.js packages:

bash npm install

1. Execute the bootstrap script to finalize the MCP integration configuration required by Cursor: bash ./setup.sh

Browser Client Installation

Install the companion extension via the official distribution channel:

1. Acquire from the Chrome Web Store

Alternatively, deploy the extension manually in developer mode:

• Navigate to chrome://extensions/ in Chrome.
• Activate "Developer mode" (top-right toggle).
• Select "Load unpacked" and point it to the extension subdirectory within this project.

Operational Instructions

Activating the Services

1. Launch the primary log collection daemon in one terminal instance:

bash node mcp-server.js

1. In a separate shell, initiate the MCP gateway, binding it to a specific port (e.g., 8766) and linking it to the log handler script: bash npx supergateway --port 8766 --stdio "node console-spy-mcp.js"

Alternatively, a convenience script bundles both startup commands:

bash ./start-servers.sh

Configuring Cursor IDE

Even after running the initial setup script, the MCP endpoint must be explicitly registered within Cursor's configuration panel:

1. Navigate to Settings -> Features -> MCP within Cursor.
2. Provision a new MCP endpoint:
3. Label: ConsoleSpy
4. Protocol Type: sse
5. Endpoint URL: http://localhost:8766/sse

Utilizing the Browser Component

1. Toggle the extension's activation state using its icon in the browser toolbar.
2. When active, all outputs generated to the console of the active tab are transmitted upstream to the aggregation server.
3. These diagnostics become accessible within Cursor's designated MCP data pane.

Customization Directives

Modifying the Log Server Port

The default communication port for the log collection daemon is set to 3333. If this port conflicts with other applications, modification is required across three distinct configuration points:

1. In mcp-server.js, adjust the port constant:

javascript const port = 3333; // Replace with your preferred numerical value

1. In console-spy-mcp.js, update the target server address:

javascript const CONSOLE_SERVER_URL = 'http://localhost:3333/mcp'; // Synchronize this value

1. In the browser extension's content.js, modify the destination endpoint URL:

javascript const serverUrl = 'http://localhost:3333/console-logs'; // Ensure this matches

1. If using the convenience script, ensure the port reference within ./start-servers.sh is also updated.

Critical Note: Absolute consistency across all modified port references is mandatory for successful operation. We strongly advise using your IDE's global find-and-replace functionality to substitute all occurrences of "3333" with your new port number.

Port reassignment is particularly vital when running local testing environments where port 3333 is already occupied by another active process.

Troubleshooting Guide

• Confirm that both the log ingestion service and the MCP gateway are successfully executing.
• Validate that the browser add-on is activated for the specific webpage under inspection.
• Double-check that the custom MCP entry in Cursor's settings accurately reflects the server URL and port.
• If data flow stalls, attempt refreshing the webpage or restarting the backend processes.

Licensing Information

MIT License

---

Background Context: XMLHttpRequest (XHR)

XMLHttpRequest (XHR) is a foundational JavaScript Application Programming Interface (API) realized as a standardized JavaScript object. Its methods provide the capability to dispatch Hypertext Transfer Protocol (HTTP) requests from a client-side web browser environment to a remote web server. These methods empower client-side applications to initiate server communications subsequent to the initial page rendering, and subsequently retrieve response data. XHR is an indispensable element of Asynchronous JavaScript and XML (Ajax) programming paradigms. Before the widespread adoption of Ajax techniques, the primary means of interacting with a server involved standard hyperlink navigation or form submissions, actions which typically mandated a full page reload.

== Historical Development ==

The conceptual underpinning for XMLHttpRequest was initially formulated in the year 2000 by software architects involved with Microsoft Outlook development. This concept was subsequently integrated into the Internet Explorer 5 browser release in 1999. However, the initial implementation syntax did not utilize the XMLHttpRequest identifier. Instead, developers relied on COM object instantiation patterns: ActiveXObject("Msxml2.XMLHTTP") and ActiveXObject("Microsoft.XMLHTTP"). As of Internet Explorer 7 (released in 2006), universal support for the standardized XMLHttpRequest object identifier was established across the board.

The XMLHttpRequest identifier has since become the prevailing, platform-agnostic standard across all major web browsing platforms, including Mozilla's Gecko rendering engine (starting 2002), Apple Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Progress === The World Wide Web Consortium (W3C) published the initial Working Draft specification for the XMLHttpRequest object on April 5, 2006. On February 25, 2008, the W3C issued the Level 2 specification Working Draft. Level 2 enhancements introduced functionality for monitoring the progress of ongoing requests, permitting cross-origin requests (Cross-Site XHR), and managing raw byte streams. By the close of 2011, the Level 2 feature set was formally merged back into the primary, unified specification document.

Toward the end of 2012, development stewardship transitioned to the WHATWG group, which now maintains the document as a continuously evolving resource using Web IDL definitions.

== Practical Utilization ==

Generally, executing a server request using XMLHttpRequest necessitates adherence to a sequence of programmatic actions:

1. Instantiation: Create an instance of the XMLHttpRequest object by invoking its constructor method.
2. Configuration: Invoke the open() method to delineate the request methodology (GET, POST, etc.), specify the target Uniform Resource Identifier (URI), and determine whether the operation will proceed synchronously or asynchronously.
3. Asynchronous Listener Setup: If an asynchronous mode is selected, define a callback function (event listener) designed to execute upon state transitions of the request.
4. Transmission: Initiate the data transfer by calling the send() method, optionally passing request payload data.
5. Response Handling: Monitor the state changes within the established event listener. If the server successfully returns payload data, it is typically accessible via the responseText property. When the processing cycle completes, the object transitions to state 4, signifying the "done" status.

Beyond these fundamental stages, XMLHttpRequest offers extensive options for fine-grained control over request transmission and response consumption. Custom HTTP headers can be appended to requests to guide server behavior. Data can be uploaded to the server via parameters passed to the send() call. Server responses formatted as JSON can be automatically deserialized into native JavaScript objects, or they can be processed incrementally as chunks arrive rather than waiting for the total payload. Furthermore, a request can be forcefully terminated prematurely or configured with a timeout threshold to prevent indefinite waiting periods.

== Cross-Origin Communication Challenges ==

During the nascent stages of the World Wide Web's evolution, it became apparent that security vulnerabilities could arise from unrestricted data fetching across disparate domain boundaries, leading to the implementation of...