{
  "id": "mcp-transport:websocket",
  "_kind": "MCPTransport",
  "_file": "compute/mcp-transports/websocket.yaml",
  "_cluster": "compute",
  "attributes": {
    "displayName": "WebSocket (non-standard)",
    "kind": "websocket-non-standard",
    "specVersion": "2025-11-25",
    "currentSpecRevision": "2025-11-25",
    "specRevisions": [],
    "status": "community",
    "streaming": "full",
    "specUrl": "https://modelcontextprotocol.io/specification/",
    "connectionLifecycle": "Community-defined; not in the canonical spec. Typical shape:\n  1. Client opens a WebSocket to the server URL (often with\n     `Sec-WebSocket-Protocol: mcp` or a vendor sub-protocol).\n  2. Once the WS handshake completes, JSON-RPC `initialize` is sent\n     as a text frame; server responds with a text frame.\n  3. Client sends `notifications/initialized`. Session is ready.\n  4. Shutdown via WS close frame.\n",
    "capabilityNegotiation": "Same `initialize` request/response payloads as the canonical\ntransports; carried as JSON-RPC messages over WS text frames.\n",
    "notificationModel": "Bidirectional text frames; either side may send notifications and\nrequests at any time. Standard JSON-RPC framing — no SSE event names.\n",
    "reconnectPolicy": "Implementation-defined. No spec-mandated session-resumption\nidentifier. Most implementations require a fresh `initialize` on\nreconnect.\n",
    "authentication": "Implementation-defined. Common patterns: bearer token in the\n`Authorization` header on the WS upgrade request, or a token query\nparameter. Auth is not standardised by the MCP spec for WebSocket;\neach implementation chooses.\n",
    "streamingFraming": "One JSON-RPC message per WebSocket text frame; binary frames are\nnot used. Standard JSON-RPC message-id discipline.\n"
  },
  "outgoingEdges": [
    {
      "from": "mcp-transport:websocket",
      "to": "layer:3-transport",
      "kind": "realizes",
      "attributes": {}
    }
  ],
  "incomingEdges": []
}