Skip to main content
Glama

Kirk — Unsupervised Structural Change Detection

by io.github.UlyssesModel

Score Single Order Book

kirk_score_book
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ask_pxYes10 ask prices, level 1 first. Same NaN convention.
bid_pxYes10 bid prices, level 1 first. NaN allowed for missing levels.
model_idNoRegistered single-layer model. Defaults to `kirk-test1-binary-threshold-v1`.kirk-test1-binary-threshold-v1

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / model_id / description
      Previous value: -"Registered single-layer model. Defaults to the reference\nTest-1 winner (`kirk-test1-binary-threshold-v1`)."New value: +"Registered single-layer model. Defaults to\n`kirk-test1-binary-threshold-v1`."
  2. Changed1 schema field changed
    • changedInput schema / properties / model_id / description
      Previous value: -"Registered single-layer model. Defaults to the Jarett\nTest-1 winner (`kirk-test1-binary-threshold-v1`)."New value: +"Registered single-layer model. Defaults to the reference\nTest-1 winner (`kirk-test1-binary-threshold-v1`)."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only/destructive annotations, the description discloses rate limits (60 req/min), cost (1 IU per call), millisecond-scale latency, bit-exact reproducibility, and sealed-engine attestation. This gives agents a comprehensive understanding of operational traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with distinct sections (Purpose, Use when, Do not use when, Capability classes, Path fit, Cost). It is somewhat longer than minimal but every section provides relevant operational context, and the front-loaded summary sentence delivers the core purpose immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's input/output behavior, performance characteristics, cost, limitations, and relationships to sibling tools. It is complete for an interactive single-snapshot scoring use case, and the presence of an output schema means return value detail is not strictly required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The tool description does not add parameter-specific details beyond what the schema already documents, which is acceptable but not additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Score one L2 order-book snapshot through the sealed single-layer path and return a scalar entropy plus engine attestation.' It uses specific verbs and resources, and distinguishes itself from siblings like kirk_score_book_batch by emphasizing single-snapshot scoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use when' and 'Do not use when' sections provide clear guidance on when to invoke this tool versus alternatives. It explicitly directs users to kirk_bulk_howto for >200 books and notes that MCP is not for production or latency-critical work.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Kirk — Unsupervised Structural Change Detection toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Every tool has a clearly distinct purpose: billing (checkout/show/usage), scoring (single/batch/legacy/synthetic/random), utility (health/models/bulk_howto/render/research). Descriptions are detailed enough to prevent confusion.

Naming Consistency5/5

All tools follow a consistent 'kirk_<domain>_<verb>' pattern (e.g., kirk_billing_checkout, kirk_score_book). No mixing of conventions or unpredictable names.

Tool Count5/5

12 tools is well within the optimal range. Each tool serves a specific need without redundancy, covering scoring, billing, health, models, and research.

Completeness5/5

The tool surface covers the full workflow: scoring (single/batch/legacy/synthetic/research), billing (checkout/balance/usage), health checking, model listing, tensor prep, and bulk client generation. No obvious gaps for the intended domain.

Resources