mcpbeat

Kirk — Unsupervised Structural Change Detection MCP Server

io.github.UlyssesModel/kirk-mcp
answering

Kirk — Unsupervised Structural Change Detection is answering right now. Last checked 10 min ago. It exposes 13 tools.

The Kalman filter for the non-Gaussian, non-stationary world. Unsupervised structural change.

The linked repository no longer exists on GitHub — it was deleted or made private.

Uptime history 41 hours of history
41 hours agonow
100.0%
Uptime 24h
91 of 91 checks
13
Tools
read from the server
471 ms
Response time
average over 24h
open, no key
Access
streamable-http

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 10 min ago.

run in your terminal
claude mcp add kirk-mcp --transport http https://kirk-mcp.kavara.ai/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "kirk-mcp": {
      "url": "https://kirk-mcp.kavara.ai/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.kirk-mcp]
url = "https://kirk-mcp.kavara.ai/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "kirk-mcp": {
      "url": "https://kirk-mcp.kavara.ai/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "kirk-mcp": {
      "url": "https://kirk-mcp.kavara.ai/mcp"
    }
  }
}

Available tools 13

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

kirk
kirk_billing_checkout
Create a Stripe Checkout Session URL for buying a credit pack (starter / scale / enterprise). Purpose: Hand the caller a self-serve URL to purchase IU credits. Use when: The caller's balance is low, or you want to route to a self-serve top-up flow before a larger validation batch. Do not use when: The caller is on an enterprise in-process deployment — those are invoiced directly, not via Checkout. Capability class(es): Meta (billing). Path fit: MCP only. Cost: 0 IU. Callable at balance=0.
kirk_billing_show
Return the caller's account_id, IU balance, USD equivalent at list, frozen flag, and recent ledger entries. Purpose: Surface the caller's current billing state — what they can spend, whether the account is frozen, and how recent entries landed. Use when: The caller wants to check available credit before committing to a large batch, or you are debugging a "why-was-I-charged" question. Do not use when: You just need per-call cost — the `_cost` envelope on every agent-driven tool result carries that inline without a separate call. Capability class(es): Meta (account state), not a capability of the scoring engine. Path fit: MCP only. Enterprise in-process deployments have their own billing surface (invoiced separately). Cost: 0 IU. Callable at balance=0 so a customer with zero credit can still self-serve to top up.
kirk_billing_usage
Return the caller's inference consumption over the last N days from the append-only Gate 2 events table. Purpose: Historical usage summary + per-tool breakdown for the caller's account. Use when: You need a usage report for the caller or an admin, or you are reconciling ledger debits against actual inference events. Do not use when: You need real-time cost — the `_cost` envelope on every agent-driven tool result covers that inline. Capability class(es): Meta (metering). Path fit: MCP only. Cost: 0 IU.
kirk_bulk_howto
Return a self-contained stdlib Python client for scoring at ZERO per-call LLM tokens. Purpose: Hand the caller an HTTP consumer that runs locally so bulk scoring doesn't burn LLM tokens per book. Use when: You need to score more than ~200 books, or `kirk_score_book_batch` returned `batch_too_large`, or the caller is running an autonomous bulk workload that would otherwise pay per-tool-call LLM tokens for every book. Do not use when: You are running a one-off interactive call — a direct `kirk_score_book` invocation is simpler; don't route through the client for a single book. Capability class(es): Cost-steering / delivery-path tool. Hands the caller a runner that exercises the same C2 / C5 / C6 capabilities as the MCP scoring tools, but at zero per-call LLM token cost. Path fit: The returned client is an HTTP consumer of the same MCP endpoint. Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. Cost: 0 IU. Free tool. Once running locally, the returned client bills against the same tools it drives: single-book calls at 1 IU each, and batch calls at 1 IU per 50 books (minimum 1 IU per call). A full 500-book batch → 10 IU. No LLM tokens on top. Cost comparison (2.7M-book validation rerun via 500-book batches — ~5400 batches, 54000 IU billed either way): MCP via Sonnet 5: $1,968 LLM + $540 IU + ~15 days wall clock MCP via Haiku 4.5: $656 LLM + $540 IU + ~10 days Python client (this tool): $0 LLM + $540 IU + ~55 min Return structure: { "language": "python", "filename": "kirk_online_client.py", "requirements": str, "usage": str, "code": str (the client source, ~500 LOC), "example": str (2-line copy-paste demo) }
kirk_demo_trading
Runs a curated demonstration of Kirk on a trading example. Zero arguments. Returns real Kirk output against the same sealed engine that customer callers hit. Free, rate-limited. First-time users: call this to see what Kirk does before signing up. Purpose: Score n=30 jittered L2 snapshots per market regime (stationary vs stressed) through the sealed engine and surface the per-regime score-distribution statistics (mean, sd) plus the z-separation between the two distributions in pooled-sd units. Also carries a representative canonical book pair so callers see two concrete scores alongside the distributions. Use when: You are a first-time caller exploring what Kirk does. You want a zero-friction "what does the output look like" experience against real sealed-engine attestation. Do not use when: You are scoring your own data — use ``kirk_score_book`` or ``kirk_score_book_batch``. This tool's input is a fixed synthetic representative pair, not a market feed. Capability class(es): C2 (variable-universe cross-section entropy scoring) demonstrated end-to-end against the sealed engine. Path fit: MCP demonstration surface only. Cost: 0 IU. Rate-limited 3/hour per IP. Returns: Dict with per-regime ``stationary`` and ``stressed`` blocks (each: ``mean``, ``sd``, ``n``, ``kirk_version``), ``z_separation`` (pooled-sd distance between the two regime distributions), ``representative_pair`` (canonical un-jittered ``stationary_score`` / ``stressed_score`` plus ``book_summaries``), ``interpretation_hint``, ``provenance``, and ``synthetic_representative`` flag.
kirk_demo_uav
Runs a curated demonstration of Kirk on a UAV example. Zero arguments. Returns real Kirk output against the same sealed engine that customer callers hit. Free, rate-limited. First-time users: call this to see what Kirk does before signing up. Purpose: Score n=30 jittered 50-element spectra per acoustic class (drone / bird / helicopter) through the sealed engine and surface per-class score-distribution statistics plus z-separations for the three class pairs. Demonstrates that the same sealed engine sha handles market microstructure and acoustic spectra with the same primitive. Use when: You want to see Kirk's cross-domain generalization without needing your own audio dataset. Do not use when: You have real feature vectors to score — use ``kirk_infer_legacy`` directly (arg: list of 50 floats). This tool's inputs are fixed synthetic spectra baked into the demo. Capability class(es): Demonstrates domain-agnostic mathematical primitive — the same engine sha handles kirk_score_book (L2) and kirk_infer_legacy (arbitrary 50-vector). Path fit: MCP demonstration surface only. Cost: 0 IU. Rate-limited 3/hour per IP. Returns: Dict with per-class ``drone`` / ``bird`` / ``helicopter`` blocks (each: ``mean``, ``sd``, ``n``, ``kirk_version``), ``z_separation`` (dict of drone_vs_bird / drone_vs_helicopter / bird_vs_helicopter in pooled-sd units), ``representative_scores`` (the three single-sample scores from the canonical un-jittered spectra), ``interpretation_hint``, ``provenance``, and ``synthetic_spectral`` flag.
kirk_infer_legacy
Score a 50-value feature vector against the legacy /v1/infer route on the sealed engine. Purpose: Backwards-compatible scoring surface for callers that were already targeting the legacy path. Use when: You have an existing client wired to /v1/infer and need continued MCP access without refactoring. Do not use when: You are on a fresh integration — prefer kirk_score_book (single-layer, cascade-shaped path). Also do not use in a tight loop against a large corpus: the MCP round-trip is millisecond-scale, and the LLM tool-call cost accrues per book for agent-driven callers. For bulk work, call kirk_bulk_howto first. Capability class(es): C2 (cross-section entropy scoring), legacy interface. Path fit: Validation via MCP (this tool). Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. Cost: 1 IU per call. For agent-driven callers, per-call LLM tokens accrue on top; the response _cost envelope surfaces both.
kirk_list_models
Enumerate the model_ids the sealed engine exposes, with the engine sha stamped in-response. Purpose: Discover the model catalog and record the sealed engine sha alongside your inference results. Use when: You are wiring a client for the first time and need model_id values for kirk_score_book / kirk_score_book_batch calls, or you want a machine-readable catalog with attestation. Do not use when: You need per-model hyperparameter detail — those are intentionally not exposed on the customer surface. Capability class(es): C5 (engine sha attested on every response). Path fit: Validation via MCP (this tool). Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. Cost: 0 IU. Free tool.
kirk_render_book
Render an L2 order-book snapshot into the 20×20 complex128 thermometer tensor WITHOUT invoking the sealed engine. Purpose: Local tensor prep and inspection — see what shape the sealed engine will receive without paying for a scoring call. Use when: You want to sanity-check bid/ask level convention against the model's canonical input convention, inspect the non-zero cell pattern for a snapshot, or debug an unexpected entropy value by first confirming the tensor is well-formed. Do not use when: You need an entropy score — this tool is prep-only. Call kirk_score_book to score. Capability class(es): Local prep for the C2 (variable-universe cross-section entropy) workflow. No sealed-engine interaction; no capability class is exercised beyond the input-shape convention. Path fit: Validation via MCP (this tool). The same tensor shape is what production in-process integrations consume under sealed-engine attestation. Cost: 0 IU. Free tool.
kirk_score_book
Score one L2 order-book snapshot through the sealed single-layer path and return a scalar entropy plus engine attestation. Purpose: Score one snapshot end-to-end through the sealed engine and surface the result plus the engine sha that produced it. Use when: You are validating Kirk on your own data before committing to a production path, or you are scoring a single snapshot inside an interactive workflow (rate-limited at 60 req/min per account). Do not use when: You need throughput above interactive scale, or you are in a per-book loop from an LLM. MCP round-trip is millisecond-scale and inappropriate for latency-critical work. For >200 books, call kirk_bulk_howto first — the returned stdlib Python client scores at zero LLM tokens per iteration. Capability class(es): - C2 (variable-universe cross-section entropy scoring — same model handles any N without retraining). - C5 (sealed engine sha stamped on every response). - C6 (bit-exact reproducibility across substrates; validated by the FY24 252-day reproduction, byte-identical on repeat runs). Path fit: Validation via MCP (this tool). Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. MCP is a validation and discovery surface, not a latency-critical production path. Cost: 1 IU per call. LLM tokens accrue on top for agent-driven callers.
kirk_score_book_batch
Score up to 500 L2 order-book snapshots in one MCP call — returns an entropies list plus engine attestation. Purpose: Batch-score up to 500 snapshots through the sealed engine in a single MCP dispatch. Use when: You are validating batch behaviour, comparing entropy distributions across small book sets, or running interactive experiments up to 500 books at a time. Do not use when: You have more than 500 books, or you are looping this tool from an LLM. Batches >500 raise a structured `batch_too_large` before any ledger debit. For sustained bulk work, call kirk_bulk_howto — the stdlib Python client scores at zero LLM tokens per iteration. Capability class(es): - C2 (variable-universe cross-section entropy — heterogeneous batch shapes are handled by one model without retraining). - C5 (sealed engine sha stamped on every response). - C6 (bit-exact reproducibility across substrates and runs). Path fit: Validation via MCP (this tool). Production bulk workloads run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. The MCP round-trip is inappropriate for high-throughput consumption. Cost: 1 IU per 50 books (minimum 1 IU per call). n≤50 → 1 IU; n=51..100 → 2 IU; a full 500-book batch → 10 IU. Validation tier — validation-scale limits. LLM-agent-scoped cap at 500 books; use kirk_bulk_howto for anything larger.
kirk_score_random
Synthesize N realistic-geometry L2 book snapshots and score them — convenience wrapper on kirk_score_book_batch. Purpose: Produce a live entropy series with no external data — the fastest way to confirm a new integration is wired end-to-end. Use when: You want a wiring-check, a first-integration walk-through, or a quick reference for the response shape without needing to supply your own market data. Do not use when: You are scoring anything real — feed your own data through kirk_score_book_batch. Synthetic bids/asks are not benchmark input and should not appear in customer-visible results. Capability class(es): C2 (uses the same variable-universe cross- section entropy path as kirk_score_book_batch, on synthetic input). Path fit: Validation via MCP (this tool). Not a production surface. Cost: 1 IU per invocation. Internally routes through kirk_score_book_batch — one metered dispatch, no double-metering.
kirk_verify_engine
Verify sealed engine identity — returns the sha256 of the running scoring binary. Also serves as a liveness probe against the sealed backend. Purpose: Attest which Kirk build is currently serving scoring calls. Response carries the sealed engine sha (kirk_version) that will stamp any subsequent kirk_score_* result. Secondary role: a cheap liveness probe for callers wiring up MCP for the first time. Use when: You want to record engine sha in your own provenance log before capturing scoring output, or you want a cheap liveness check ahead of a larger validation batch. Do not use when: You want a scoring result — this returns identity/liveness only, no entropies. Capability class(es): C5 (cryptographic attestation of engine identity). Path fit: Validation via MCP (this tool). Production integrations run in-process under sealed-engine attestation — same binary sha as this endpoint. Contact Kavara for deployment options. Cost: 0 IU. Free tool. For agent-driven callers, the _cost envelope still reports iu_this_call=0 and the running session totals. Returns: Dict with `status`, `engine`, `env`, and `kirk_version` (the sealed .so sha). A non-2xx response raises; caller sees a clean MCP tool error.

Endpoints

URLTransportStateLatencyChecked
https://kirk-mcp.kavara.ai/mcp streamable-http answering 497 ms 10 min ago

Kirk — Unsupervised Structural Change Detection — questions

Answers built from our own checks of this server.

What can Kirk — Unsupervised Structural Change Detection do?
It exposes 13 tools, read directly from the server on our last check. Among them: kirk_billing_checkout, kirk_billing_show, kirk_billing_usage, kirk_bulk_howto, kirk_demo_trading, kirk_demo_uav and 7 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is Kirk — Unsupervised Structural Change Detection working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 471 ms. The bar chart above shows every period we have measured.
Is Kirk — Unsupervised Structural Change Detection still maintained?
The linked repository no longer exists on GitHub — it was deleted or made private. We show this because it changes what you can expect: an unmaintained server may keep answering for months and then stop without warning.
How do I connect Kirk — Unsupervised Structural Change Detection?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Kirk — Unsupervised Structural Change Detection need an API key?
No. Kirk — Unsupervised Structural Change Detection completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 13 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Kirk — Unsupervised Structural Change Detection?
It answers our handshake in 471 ms on average, which is faster than 25% of all working MCP servers we measure. That is on the slow side — worth knowing if the tool sits inside an interactive loop. The comparison comes from our own checks across the whole registry, every 15 minutes.