MCP Transports and Authentication

Configure MCP server connectivity: stdio for local processes and streamable HTTP for remote services. Set up OAuth 2.1 with PKCE and dynamic registration, API key authentication, bearer tokens, and environment variable credentials.

February 26, 2026

An MCP server's transport defines how the client connects to it, and the authentication configuration defines how the client proves its identity. NeoArc supports documenting both transport types defined in the MCP specification - stdio and streamable HTTP - along with a flexible authentication model that covers OAuth 2.1, API keys, bearer tokens, and environment variable credentials.

Transport Types

MCP defines two transport mechanisms. Most servers support at least one; some support both for different deployment scenarios.

stdio Transport

The stdio transport launches the MCP server as a child process. The client sends JSON-RPC messages to the process's stdin and reads responses from stdout.

{
  "type": "stdio",
  "command": "npx",
  "args": ["-y", "@example/ecommerce-mcp-server"],
  "env": {
    "ECOMMERCE_API_KEY": "${ECOMMERCE_API_KEY}",
    "ECOMMERCE_API_URL": "https://api.example.com/v2"
  },
  "platformNotes": "Requires Node.js 20+ and npm 10+"
}

Streamable HTTP Transport

The streamable HTTP transport connects to a remote server over HTTPS. It supports two additional features beyond basic request-response.

{
  "type": "streamable-http",
  "url": "https://mcp.example.com/ecommerce/v2",
  "sessionManagement": {
    "enabled": true,
    "description": "Sessions persist for 30 minutes of inactivity"
  },
  "sseSupport": {
    "serverInitiatedMessages": true,
    "resumability": true
  }
}

Multiple Transports

A server can offer both transport types. This is common when the same server supports local development via stdio and production deployment via HTTP. Document both transports and note when each is appropriate.

Authentication

MCP authentication is configured at the server level and applies to all tools, resources, and prompts. NeoArc supports three authentication methods that can be used individually or in combination.

OAuth 2.1

OAuth 2.1 is the MCP specification's recommended authentication method for HTTP transports. NeoArc documents the full OAuth configuration so clients can automate the token exchange flow.

API Key and Bearer Token

For simpler authentication requirements, MCP servers can accept API keys or bearer tokens via HTTP headers.

Environment Variable Authentication

For stdio transports, credentials are typically passed as environment variables. Each variable is documented with its name, description, whether it is required, and an example value.

{
  "envAuth": [
    {
      "variableName": "ECOMMERCE_API_KEY",
      "description": "API key for the e-commerce platform",
      "required": true,
      "example": "ek_live_abc123..."
    },
    {
      "variableName": "ECOMMERCE_REGION",
      "description": "Deployment region (affects API endpoint selection)",
      "required": false,
      "example": "eu-west-1"
    }
  ]
}

Combining Transports and Authentication

The transport and authentication configuration work together. Here are common combinations.

Sampling

Sampling allows the MCP server to request LLM completions through the client. This is an advanced capability where the server asks the AI to generate text, analyse data, or make decisions as part of a tool execution.

Related Guides

MCP Server Documentation Overview

Understand the Model Context Protocol and how NeoArc Studio documents MCP servers. Learn about the three primitives (tools, resources, prompts), transport modes, authentication, and how MCP fits into your architecture documentation workflow.

MCP Import and Export

Import existing MCP server manifests into NeoArc Studio and export your documented servers as standard JSON. Understand the file format, directory conventions, and how NeoArc maps MCP primitives to its internal data model.