Proposal: Include chat tab identifier (window_id) in MCP requests

Feature Requests
1

:puzzle_piece: Context

When using a single Cursor instance with multiple chat tabs, all MCP requests share the same session_id generated at app launch. As a result, the backend cannot differentiate which chat tab initiated a particular request, even though each tab maintains separate conversation context and history.

:bullseye: Problem

  • All chat tabs share one MCP session_id, making it impossible for tools or custom backend services to identify which tab sent a request.
  • This limitation hinders backend features like per-tab analytics, routing, or isolation of tool calls, especially when running parallel workflows across tabs.

:white_check_mark: Proposed Feature

Please enhance Cursor to generate a unique window_id for each chat tab and include it in MCP requests. This could be done via:

  • Adding a "window_id" field in the JSON payload sent over stdio/SSE.
  • Or including it in a header (e.g. Mcp-Window-Id: <uuid>) in HTTP mode.

:sparkles: Benefits

  • Parallel tab support: Backend services can map requests to tabs, enabling multi-window workflows.
  • Analytics & monitoring: Track usage and performance per chat tab.
  • Better tool routing: MCP servers can make tab-specific routing or caching decisions.
  • Plugin and extension readiness: Plugins can operate correctly in separate tabs without cross-talk.

:link: Related discussions

:hammer_and_wrench: Example usage

{
  "session_id": "abc123",
  "window_id": "550e8400-e29b-41d4-a716-446655440000",
  "payload": { ... }
}
2

I would like to add to this that the MCP spec’s description of what a session is, is:

”An MCP “session” consists of logically related interactions between a client and a server”

( Transports - Model Context Protocol )

Which seems to me pretty clearly point towards that individual cursor tabs are exactly the scope for an MCP session, and that cursor should keep such mcp-session-ids per tab to be properly MCP-compliant.

This is also a critically lacking part of cursor as an mcp client in my current project ( Open-Edison and blocks us from being able to protect our users from data exfiltration. We need the appropriate tab-granularity on the mcp-server side to determine when to allow/block mcp calls in our data protection model.

Best,
Hugo

3

This is exactly on point, if the session identifies a client then we should be able to identify “tabs”.

When your MCP depends on context per tab, for example to continue a chat thread, this is very important.