Skip to main content
The Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools and data sources. CyberStrike supports both local MCP servers (processes you run on your machine) and remote MCP servers (HTTPS endpoints, optionally secured with OAuth). MCP servers appear to CyberStrike agents as additional tools — they can be called the same way as built-in tools, and their results flow back into the agent’s reasoning loop.

​
Server types

​
Local MCP servers

A local MCP server is a process CyberStrike launches on your machine. You specify the command to run; CyberStrike manages the process lifecycle. Config fields:
Value: "local" — requiredIdentifies this as a locally-executed MCP server.
Type: string[] — requiredThe command and arguments to run. CyberStrike splits the array into the executable and its arguments.
"command": ["npx", "-y", "my-security-tool"]
Type: Record<string, string> — optionalEnvironment variables to inject when starting the process. Use this to pass API keys and configuration without hard-coding them in the command string.
"environment": {
  "API_KEY": "your-key",
  "LOG_LEVEL": "info"
}
Type: boolean — optionalWhether to start this server on launch. Set to false to keep the config without activating the server.
Type: number (integer, positive) — optionalRequest timeout in milliseconds. Defaults to 5000 (5 seconds). Increase this for tools with slow startup or long-running operations.

​
Remote MCP servers

A remote MCP server is an HTTPS endpoint that speaks the MCP protocol. CyberStrike connects over HTTP and optionally authenticates with OAuth or static headers. Config fields:
Value: "remote" — requiredIdentifies this as a remote MCP server.
Type: string — requiredThe full URL of the remote MCP server.
"url": "https://tools.example.com/mcp"
Type: boolean — optionalWhether to connect to this server on launch.
Type: Record<string, string> — optionalStatic HTTP headers to include with every request. Use this for Bearer token authentication or custom API keys that don’t change between sessions.
"headers": {
  "Authorization": "Bearer your-static-token"
}
Type: McpOAuth | false — optionalOAuth authentication configuration. When present and not false, CyberStrike will attempt OAuth authentication with the server.Set to false to explicitly disable OAuth auto-detection for a server that returns WWW-Authenticate headers but doesn’t require OAuth.The McpOAuth object accepts:
  • clientId (string, optional) — OAuth client ID. If omitted, CyberStrike attempts dynamic client registration (RFC 7591).
  • clientSecret (string, optional) — OAuth client secret, if required by the authorization server.
  • scope (string, optional) — OAuth scopes to request during authorization.
Type: number (integer, positive) — optionalRequest timeout in milliseconds. Defaults to 5000 (5 seconds).

​
Configuration

Add MCP servers to cyberstrike.json under the "mcp" key. Each entry is a named server.
cyberstrike.json
{
  "mcp": {
    "my-local-tool": {
      "type": "local",
      "command": ["npx", "-y", "my-security-tool"],
      "environment": { "API_KEY": "your-key" }
    },
    "remote-server": {
      "type": "remote",
      "url": "https://tools.example.com/mcp",
      "headers": { "Authorization": "Bearer token" }
    }
  }
}

​
CLI commands

​
Adding a server

The interactive add command walks you through configuring a new MCP server and writes the result to your config file. 
cyberstrike mcp add
You’ll be prompted to choose a scope (current project or global), a server name, a type (local or remote), and the connection details. For remote servers with OAuth, the wizard collects your client credentials.

​
Listing servers

cyberstrike mcp list
Shows all configured MCP servers with their connection status:
  • ✓ connected — server is reachable and responding
  • ○ disabled — server is present in config but disabled
  • ⚠ needs authentication — server requires OAuth and no credentials are stored
  • ✗ failed — server is unreachable or returned an error

​
OAuth authentication

cyberstrike mcp auth <name>
Starts the OAuth flow for a remote MCP server. CyberStrike opens your browser to the authorization page; after you approve, the token is stored locally and used for all subsequent requests. If your server requires dynamic client registration and you haven’t pre-registered a client ID, CyberStrike attempts registration automatically (RFC 7591). If the server doesn’t support dynamic registration, add your clientId to the config:
cyberstrike.json
{
  "mcp": {
    "my-server": {
      "type": "remote",
      "url": "https://example.com/mcp",
      "oauth": {
        "clientId": "your-client-id",
        "clientSecret": "your-client-secret"
      }
    }
  }
}

​
Logging out

cyberstrike mcp logout <name>
Removes stored OAuth credentials for a server. The server entry remains in your config; you’ll need to run cyberstrike mcp auth again before using it.

​
Debugging OAuth

cyberstrike mcp debug <name>
Tests connectivity and OAuth state for a remote server. Shows the HTTP status, WWW-Authenticate headers, stored token expiry, and client registration status. Useful when a server shows needs authentication but auth fails.

​
Project vs. global scope

When you run cyberstrike mcp add inside a Git repository, you can choose to save the server to your project config (cyberstrike.json in the repo root) or your global config (~/.config/cyberstrike/cyberstrike.json).
  • Project scope — The server is available when you run CyberStrike from that repository. Commit cyberstrike.json to share the config with your team.
  • Global scope — The server is available in every CyberStrike session on your machine.
Avoid committing API keys or OAuth secrets to your project config. Use the environment field to reference keys that exist in your shell environment, or keep sensitive servers in your global config.

Build docs developers (and LLMs) love

Get started for freeTalk to us