[feature]: Expose the live Hoppscotch workspace to user-chosen agents through WebMCP

Is there an existing issue for this?

• I have searched the existing issues

Issue #5966 proposes adding an MCP client to Hoppscotch so users can connect to MCP servers. This proposal addresses a different direction: exposing the live Hoppscotch browser session to an external, user-chosen agent through WebMCP.

Summary

Add an experimental, opt-in WebMCP integration that exposes semantic capabilities from the active Hoppscotch browser session.

This would allow a user-chosen external agent to inspect, modify, execute, and reason about the request a developer is currently working on—including unsaved changes, the current response, the selected environment, and other interaction state—while keeping Hoppscotch as the visible and authoritative workspace.

The goal is not to embed a Hoppscotch-specific AI assistant or replace a conventional MCP server. It is to let Hoppscotch expose the context it already understands best, so a developer and their chosen agent can work on the same live application state.

A working implementation is available in my fork for reference and evaluation:

• https://github.com/andreolli-davide/hoppscotch-webmcp

I would like to validate the product fit, architecture, and acceptable initial scope with the maintainers before opening a pull request. The existing implementation can be reduced, reshaped, or split into smaller contributions based on that feedback.

Why should this be worked on?

Developers currently need to manually transfer API debugging context into an AI conversation:

1. Copy the request URL, headers, body, and response.
2. Remove or mask credentials.
3. Explain the selected environment and other relevant state.
4. Apply the suggested changes manually in Hoppscotch.
5. Execute the request again and copy the new result back.

The main limitation is not the agent's ability to reason about APIs. It is that the agent and the API client operate in separate contexts.

Hoppscotch already knows:

• which request and response are active;
• whether the request contains unsaved changes;
• which environment is selected;
• which values are secret;
• how the request should be executed;
• how a mutation should update the normal UI;
• how the response, history, and tests should be updated.

WebMCP would allow Hoppscotch to expose that information through product-level capabilities instead of requiring an agent to infer it from screenshots, DOM structure, copied prompts, or saved backend resources.

This is particularly valuable for ephemeral state. A request may exist only in the active tab, have no collection or request ID, and contain changes made seconds ago. That state is difficult for a server-side integration to access, but it is immediately available to the browser application.

A core workflow could look like this:

1. The developer asks: “Why is the request I'm looking at failing?”
2. The agent inspects the active request and response through Hoppscotch.
3. The agent proposes or applies a controlled change.
4. The normal Hoppscotch editor visibly updates.
5. Hoppscotch executes the request through its existing execution pipeline.
6. The normal response viewer updates.
7. The developer changes the request manually and asks: “What about now?”
8. The agent re-reads the live state and continues without requiring a request ID, save operation, or another copy/paste cycle.

This would benefit Hoppscotch by:

• making it interoperable with user-chosen agents instead of tying the workflow to a proprietary embedded assistant;
• reducing context switching and manual serialization of API state;
• making unsaved and active browser state available as first-class context;
• preserving Hoppscotch's existing execution, authentication, environment, interceptor, history, and response behavior;
• keeping agent changes visible, reviewable, and editable in the normal UI;
• enabling shared human-agent workflows where control can move naturally between the developer and the agent;
• providing a browser-native complement to resource-oriented MCP servers.

The initial scope could remain intentionally small:

• inspect the active request and response;
• expose safe metadata about the active environment;
• update allow-listed fields of the active request;
• execute through Hoppscotch's normal request pipeline;
• reflect all changes and results in the existing UI;
• re-observe human changes rather than relying on stale snapshots.

The integration should be feature-detected, disabled by default, and have no effect in browsers that do not support WebMCP. Secret values should be redacted or represented as references, and externally consequential actions should retain explicit approval and stale-state protection.

The existing fork implements a broader surface, but it can be reduced or split into smaller pull requests based on maintainer feedback. The purpose of this issue is to agree on whether this interaction model belongs in Hoppscotch and what the smallest acceptable contribution should be.