AI / MCP integration

Симолёт exposes a native Model Context Protocol server. Add it to a Claude client you already pay for (Claude Desktop, Claude Code, or a claude.ai connector) and Claude launches simulations, polls status, reads logs and fetches artifacts — from the chat, on your Claude Max/Pro subscription, with no per-token API bill. Симолёт does the heavy compute (meshing, solving, rendering) on its own fleet.

Settings → Connectors → Add custom connector, then:

Name simolyot · URL https://sim-orch.sverk.io/mcp · Bearer token slt_…

Claude runs initialize → tools/list and shows the 37 tools below. If your build takes a JSON config for remote servers:

{
  "mcpServers": {
    "simolyot": {
      "type": "url",
      "url": "https://sim-orch.sverk.io/mcp",
      "authorization_token": "slt_YOUR_TOKEN"
    }
  }
}

claude mcp add --transport http simolyot https://sim-orch.sverk.io/mcp \
  --header "Authorization: Bearer slt_YOUR_TOKEN"

claude mcp list          # → simolyot should appear

Then just describe the task in chat — Claude picks and calls the tools.

To drive it from your own automation, attach the server via the Messages API MCP connector (this path uses an Anthropic API key, separate from the subscription story):

import anthropic
client = anthropic.Anthropic()  # ANTHROPIC_API_KEY

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=2048,
    betas=["mcp-client-2025-11-20"],
    mcp_servers=[{
        "type": "url",
        "name": "simolyot",
        "url": "https://sim-orch.sverk.io/mcp",
        "authorization_token": "slt_YOUR_TOKEN",
    }],
    messages=[{"role": "user", "content":
        "List the stacks, run hello-sim, wait for it, and summarize the logs."}],
)
print(resp.content)

Call get_stack_guide first to learn how to author a run — it returns the run contract (how /work, /config/run.json and the ##metric protocol work), the stack’s config schema, and a working example to adapt. (list_stacks also carries each base’s docs and configurable fields.) Then reach for the smallest surface that fits:

• One run → submit_job → poll get_job until phase is succeeded/failed → read get_logs + list_artifacts. preflight_job validates limits/headroom first.
• Layered config → submit_run (four overlays platform<org<project<user, provenance-tracked); resolve_run/validate_run preview it. run.id == job.id, so the job tools still apply.
• Multi-step DAG → submit_pipeline (each stage a run gated on its needs) → poll get_pipeline. validate_pipeline checks it first.
• Interactive pod → create_session → get_session (launching→ready) → stop_session.
• Share a live run → mint_embed. Admin → orgs, get_policy/preview_policy, node grants.

Every tool dispatches back through the live REST router, so it inherits that route’s RBAC scope, tenancy and quota — the MCP facade adds no bypass.

A 5-second connectivity check: initialize → tools/list → tools/call list_stacks.

curl -sS https://sim-orch.sverk.io/mcp \
  -H "Authorization: Bearer slt_YOUR_TOKEN" -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"list_stacks","arguments":{}}}'

A tools/call result is {"content":[{"type":"text","text":"…JSON…"}],"isError":false} — the text is the raw REST response body (the stack catalog, a job object, …). If you see serverInfo.name = “simolyot” and a stack list, MCP is live.