RFC: MCP Profile for Low-Bandwidth Intent Inputs

This RFC proposes a standardized Model Context Protocol (MCP) profile designed specifically for low-bandwidth, discrete intent inputs, such as those generated by silent speech interfaces (ssi), electromyography (sEMG) arrays, brain-computer interfaces (bci), and discrete mechanical switches.

1. Abstract & Motivation

As AI agents move closer to real-time integration with user operating systems and devices, there is an increasing demand for physical input modalities that bypass traditional keyboards and high-bandwidth voice interfaces. Subvocal speech recognition (AlterEgo style) classifies subtle muscle contractions into a limited set of noisy shorthand abbreviations (e.g., clk for Click, gt for GoTo, typ for Type).

This document establishes a Low-Bandwidth Intent Profile for the Model Context Protocol. Standardizing these inputs as MCP tools and resources allows LLM-powered developer environments (e.g., Claude Desktop, Cursor) to natively ingest, query, and orchestrate biosensor inputs without custom, client-specific device drivers.

2. Low-Bandwidth Intent Profile Handshake

During the initial MCP connection negotiation (initialize request/response), both the client and the server declare capabilities. An SSI/sEMG server announces support for the low-bandwidth-intent profile as part of its capabilities structure:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "tools": {
        "listChanged": true
      },
      "resources": {
        "listChanged": true
      },
      "experimental": {
        "low-bandwidth-intent": {
          "supportedInputs": ["abbreviations", "phonetic_tokens"],
          "hardwareFrequencyHz": 250
        }
      }
    },
    "serverInfo": {
      "name": "SubvocalMiddlewareMCPServer",
      "version": "1.0.0"
    }
  }
}

3. Tool Specifications

To orchestrate real-time stream state and buffer execution, the server exposes the following tools to the client:

A. get_pipeline_status

Retrieves physical sensor status metrics, z-score normalization configurations, and the currently active classification model (e.g., 1D CNN, GRU, or Transformer).

• Parameters: None
• Success Output Schema:

{
  "content": [
    {
      "type": "text",
      "text": "Subvocal Pipeline Status:\n- Hardware Source: Connected (SyntheticSignalGenerator)\n- Active Classifier: cnn (Pre-trained)\n- Buffer Size: 0 tokens\n- Total Actions Dispatched: 1"
    }
  ]
}

B. get_buffer

Allows the AI client to query the active, uncommitted phrase buffer of classified command tokens. * Parameters: None * Success Output Schema:

{
  "content": [
    {
      "type": "text",
      "text": "[\n  {\n    \"text\": \"clk\",\n    \"confidence\": 0.98,\n    \"timestamp\": 1780826170.82\n  }\n]"
    }
  ]
}

C. inject_mock_token

Mainly used for automated integration testing, simulation, and software-fallback inputs. It injects a discrete classified token into the buffer. * Parameters: - token (string, required): The gesture abbreviation (e.g., gt, clk, typ). - confidence (number, optional): Classifier confidence between 0.0 and 1.0. * Success Output: "Successfully injected token 'clk' with confidence 0.95"

D. process_phrase

Triggers immediate phrase-timeout decoding, bypassing the physical cooldown period. The server merges the token buffer, queries context sources, invokes the LLM intent reconstructor, and returns the resulting structured Action. * Parameters: None * Success Output Schema:

{
  "content": [
    {
      "type": "text",
      "text": "Reconstructed and executed action:\n{\n  \"action_type\": \"click\",\n  \"params\": {\n    \"arguments\": [],\n    \"resolved_text\": \"CLICK\",\n    \"confidence\": 0.9\n  },\n  \"intent_id\": \"b83c50ad-44b4-4b55-be28-a53c89694eb3\",\n  \"timestamp\": 1780826182.25\n}"
    }
  ]
}

4. Resource Specifications

To provide the client model with contextual telemetry and historical records, the profile exposes intent histories and real-time buffers as standardized MCP resources:

5. Client Execution Flow & Best Practices

AI clients (such as developer shells, file browsers, and operating system agents) should implement the following control loop when interfacing with a Low-Bandwidth Intent MCP server:

                  ┌───────────────────────┐
                  │   Client Agent Loop   │
                  └───────────┬───────────┘
                              │
                    Poll / Read Resource
                 "subvocal://intent/history"
                              │
                              ▼
            Is there a new Intent Action logged?
                     /                 \
                   YES                  NO
                   /                      \
                  ▼                        ▼
        1. Parse parameters         Sleep & Repeat
        2. Execute OS Action 
        3. Feed result back to model

1. Passive Telemetry: Rather than polling execution loops continuously, clients are encouraged to subscribe to the subvocal://intent/history resource to receive push notifications when new commands are dispatched.
2. Context Enrichment: The client agent should populate its local OS context metrics so that the middleware's LLM intent reconstructor has access to high-fidelity target windows (such as active browser tabs or clipboard text) when translating shorthand sequences like gt.
3. Safety Confirmations: For high-risk actions (e.g., file deletions, network writes), the client executor must prompt the user for confirmation before acting upon reconstructed intents.