Skip to main content

MCP Server

The ssg CLI ships a built-in MCP (Model Context Protocol) server that exposes SigmaShake governance directly to AI coding agents. Connect it once and your agent evaluates tool calls against your rules, checks health, sets up projects, writes rules, or starts governed terminals — all through natural conversation.

Local transport: stdio (ssg mcp-server) — Cursor/Codex/Claude Code on your OS; also Grok Bot when ssg is reachable (--client=grok-bot)
Hosted transport: Streamable HTTP https://mcp.sigmashake.com/mcp — Grok Bot marketplace default and other remote connectors
Legacy hosted SSE: https://mcp.sigmashake.com/sse + POST /message
Protocol: JSON-RPC 2.0 (local: 2024-11-05; hosted Streamable HTTP: 2025-03-26)
Local tools: 14 tools, all served by default (core, terminal, agent threads, audit export, onboarding)

Quick Setup​

Step 1 — Install ssg​

Subscribe at sigmashake.com/pricing, then install the CLI — see Getting Started for the platform-specific install command. After installing:

ssg auth login

Step 2 — Connect your AI client​

# Auto-configures the MCP server in your client's config:
ssg init --client=claude-code      # Claude Code
ssg init --client=antigravity      # Antigravity
ssg init --client=codex            # OpenAI Codex
ssg init --client=grok-bot         # Grok Bot (local stdio MCP + hooks)

Or add it manually to your MCP config file:

{
  "mcpServers": {
    "ssg-governance": {
      "command": "ssg",
      "args": ["mcp-server"],
      "env": {
        "SSG_CLIENT": "claude-code"
      }
    }
  }
}

For Codex, the equivalent manual config lives in ~/.codex/config.toml:

[mcp_servers.ssg-governance]
command = "ssg"
args = ["mcp-server"]

[mcp_servers.ssg-governance.env]
SSG_CLIENT = "codex"

The Go server serves all 14 tools with no extra flag. Do not add --tools for the Go build. See Tool Groups.

Config file locations:

ClientConfig file
Claude Code.claude/mcp_config.json or ~/.claude/mcp_config.json
Antigravitymcp_config.json or ~/.gemini/mcp_config.json
Codex~/.codex/config.toml
Cursor (local).cursor/mcp.json (ssg mcp-server --client=cursor)
Grok BotSigmaShake Guardrails: hosted https://mcp.sigmashake.com/mcp (default) or local ssg mcp-server --client=grok-bot when available
Windsurf~/.codeium/windsurf/mcp_config.json

Step 3 — Restart your client​

The MCP server is registered at startup. Restart your AI client once to pick up the new tools.

Step 4 — Say hello​

"Set up SigmaShake governance for my project"

Tool Groups​

The Go ssg mcp-server serves three groups of tools. All three are on by default. You do not need a flag or an environment variable.

GroupToolsAlways served
core4yes
terminal2yes
onboarding4yes
Total10

The startup line on stderr shows what loads:

[ssg] MCP server v0.21.1 started (SSG_CLIENT=cursor, tools=core+onboarding, 14 tools)

The --tools flag​

The --tools flag accepts core and onboarding. Both values still serve all 14 tools. The server does not hide any tool.

The Go build does not have fleet, coder, memory, or debug groups. If you pass one of these names, the server prints a warning to stderr and ignores it. The server still serves the 14 tools. These groups need the Bun runtime:

SSG_CLI_RUNTIME=bun ssg mcp-server --tools=fleet

Token Budget​

The server sends all 14 tool definitions at startup. This is a one-time cost in each conversation. A typical ssg_evaluate call (tool name + input) + allow response costs ~62 tokens.

Tool Reference​

The Go MCP server provides 14 tools across five groups. All groups are active by default.

Core Governance​

ToolDescription
ssg_evaluateEvaluate a tool call against active rules. Returns allow, block, ask, log, or force. Call it before every agent tool use.
ssg_checkScan a file or directory path for rule violations. Returns the matched rules and their decisions.
ssg_statusReturn governance health: active rule count, daemon status, client adapter.
ssg_blockedReturn the blocked and forced tool calls from this session.

Governed Terminal​

ToolDescription
ssg_terminal_spawnCreate a governed terminal session in ssg serve and launch an agent. Parameters: agent (required), prompt, cwd, title, account. Returns the session JSON (id, launched).
ssg_terminal_stateRead the state of a governed terminal session. Parameters: id (required), screen (last N lines, 0 to 500), idle_after (seconds, 1 to 3600). Returns state (starting, running, idle, or dormant), alive, idleSeconds, liveAgent, and the screen text if screen is set.
ssg_terminal_acceptControl the auto-accept engine of governed terminal sessions. Parameter action: status, on, off, or session (session and mode are then required).

Agent Thread Mirror​

ToolDescription
ssg_agent_threads_statusRead the state of the agent thread mirror of ssg serve: enabled, dry run, running, channel state, thread count, queue and error counters.
ssg_agent_threads_setSet the switches of the agent thread mirror and restart it. Use dry_run to log what the mirror would post, without a Discord call.

Audit Export​

ToolDescription
ssg_audit_exportExport the local audit log as JSON Lines or CSV, oldest first, with filters. Secrets are masked. Returns at most limit rows (default 1000, maximum 10000). Needs a Pro or Enterprise license.

Onboarding & Setup​

ToolDescription
ssg_onboardProject setup in one call. Creates the .sigmashake/ directory with starter rules, runs lint, and returns a health summary. Parameters: project_path, preset (minimal, security, strict), client, skip_hub. Needs prior Terms of Service acceptance. Start here.
ssg_doctorHealth check. Returns ok, warn, or fail for version, Terms acceptance, local rules, daemon, license tier, and client adapter.
ssg_apply_ruleWrite a project rule file while evaluation stays on. Validates the DSL and the sealed-kernel invariants, writes only to the project rules directory, and returns {ok, live, rule_id, applied_ms}. Parameters: content, filename (required), project_path. Needs a Pro license and an initialized project.
ssg_rule_statusShow rule liveness. Returns mode, live_count, files, last_applied_unix_ms, and pending_file_mtime.

Tool Examples​

ssg_onboard — Full project setup​

"Set up SigmaShake for my TypeScript + React project"

Response:

SigmaShake Onboarding — /home/user/my-app

Stack Detection
  Detected: TypeScript + React

Initializing .sigmashake/
  ✓ .sigmashake/config.toml
  ✓ .sigmashake/rules/security.rules

Hub Rulesets (2 detected)
  ✓ TypeScript Governance Rules v3
  ✓ React Component Rules v2
  2/2 rulesets installed

Validation
  ✓ All rules pass lint checks

✓ SigmaShake is ready!

ssg_apply_rule — Write a custom rule​

"Block any command that runs npm publish without my approval"

The agent calls ssg_apply_rule with a filename (npm-safety.rules) and this rule body:

rule require-approval-npm-publish {
  enabled true
  priority 90
  severity error
  ASK execution
  IF command CONTAINS "npm publish"
  MESSAGE "npm publish detected."
  PROMPT "Allow publishing to npm registry?"
}

Response: {"ok":true,"live":true,"rule_id":"require-approval-npm-publish","applied_ms":12}

ssg_evaluate — Manual rule evaluation​

{
  "tool": "run_command",
  "input": { "CommandLine": "git push --force origin main" }
}

Response:

{
  "decision": "block",
  "rule_id": "no-force-push",
  "reason": "Force push is blocked. Use --force-with-lease."
}

Environment Variables​

VariableDescription
SSG_CLIENTClient adapter name: claude-code, cursor, antigravity, codex, copilot, generic

Governance Enforcement​

The MCP server enforces its own governance rules through ssg_evaluate. A tool call is evaluated when the host hook or the agent calls ssg_evaluate. On hosts with a pre-tool hook, the hook enforces this. On other hosts, the agent must choose to call ssg_evaluate, so evaluation is not guaranteed. See Adapters for the enforcement level of each host.

The evaluation chain:

  1. Agent calls a tool (e.g. run_command)
  2. ssg_evaluate is called first with the tool name + input
  3. Engine evaluates against active .sigmashake/rules/ files
  4. Decision returned: allow → tool runs, block → tool rejected, ask → paused for approval

Troubleshooting​

Tools not appearing in my AI client​

  1. Check that ssg mcp-server starts and lists tools:

    echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | ssg mcp-server

    Should return a JSON array. The Go server returns 14 tools.

  2. If you see fewer than 14 tools, update ssg. Older builds served fewer tools.

  3. Restart your AI client — MCP connections are established at startup.

  4. Verify the config file path and JSON syntax are correct.

"Not authenticated" error from onboarding tools​

ssg auth login      # Browser login — one click
ssg auth status     # Verify you're logged in

A tool group warning at startup​

If you pass --tools=fleet (or coder, memory, debug), the Go build prints a warning and ignores the group. Remove the flag, or use the Bun runtime:

SSG_CLI_RUNTIME=bun ssg mcp-server --tools=fleet

ssg_apply_rule returns ok: false​

Read the error and next_step fields in the response. Common causes:

  • Terms of Service not accepted. Run ssg init -y --accept-terms.
  • No Pro license. Run ssg auth activate --license <key>.
  • The project is not initialized. Run ssg init -y --accept-terms.
  • A parse error in the rule body.
  • A rule weakens a sealed-kernel rule.

See Rule Syntax for the complete language reference.

Security Notes​

  • The MCP server runs locally as a subprocess.
  • ssg_apply_rule writes only inside the project rules directory. It accepts a bare *.rules filename and rejects path traversal.