Kirk — Unsupervised Structural Change Detection
Server Details
The Kalman filter for the non-Gaussian, non-stationary world. Unsupervised structural change.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- UlyssesModel/kirk-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 12 of 12 tools scored.
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.
All tools follow a consistent 'kirk_<domain>_<verb>' pattern (e.g., kirk_billing_checkout, kirk_score_book). No mixing of conventions or unpredictable names.
12 tools is well within the optimal range. Each tool serves a specific need without redundancy, covering scoring, billing, health, models, and research.
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.
Available Tools
12 toolskirk_billing_checkoutCreate Checkout SessionAInspect
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 Path B (wheel), Path C (OpenShift Operator), or Path D (Nitro AMI) — enterprise deployments are invoiced directly, not via Checkout.
Capability class(es): Meta (billing).
Path fit: MCP only.
Cost: 0 IU. Callable at balance=0.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | one of 'starter' ($500 / 50K IU), 'scale' ($5K / 500K IU), or 'enterprise' ($50K / 5M IU). | starter |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: cost is 0 IU, callable at balance=0, and it's a 'Meta (billing)' capability. This goes beyond annotations by explaining side effects (external URL creation) and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded: first sentence states core purpose, followed by concise bullet-like sections for use conditions, exclusions, capabilities, and cost. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool simplicity (1 parameter, output schema exists), the description covers all needed context: purpose, when to use, when to avoid, cost, capabilities. It is complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the single parameter 'pack' with high coverage (100%), explicitly listing options and prices. The description mentions 'starter / scale / enterprise' but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a Stripe Checkout Session URL for buying a credit pack', specifying the action (create) and resource (Stripe Checkout Session URL). It distinguishes from sibling tools like kirk_billing_show and kirk_billing_usage by focusing on self-serve top-up, not display or usage reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly includes 'Use when: caller's balance low, or want to route to self-serve top-up' and 'Do not use when: Path B, C, D (enterprise deployments invoiced directly)'. This provides clear context and alternatives, guiding the agent on appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_billing_showShow Billing BalanceARead-onlyInspect
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. Path B / C / D 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds valuable context: cost is 0 IU and callable at balance=0, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, use cases, exclusions, path fit, cost). Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a parameterless tool with output schema and annotations. Covers purpose, usage, cost, and path restrictions thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters with 100% schema coverage, so baseline is 4. No additional parameter description is needed; description adds no param info but that is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact information returned (account_id, IU balance, USD equivalent, frozen flag, recent ledger entries) and clearly distinguishes from siblings like kirk_billing_checkout and kirk_billing_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (checking credit before batch, debugging charges) and when not to use (per-call cost is better from envelope). Also provides capability class and path fit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_billing_usageGet Usage SummaryARead-onlyInspect
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 operator, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | window size (default 30). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint; description adds context about the append-only table, capability class, path, and cost, enhancing transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is highly concise with eight short lines, front-loaded with core purpose, and includes structured usage guidance and metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and existing output schema, the description covers all necessary context including usage, capability class, path, and cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description only restates the window size in prose, adding minimal value beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns 'caller's inference consumption over the last N days' and provides a per-tool breakdown, distinguishing it from sibling tools like kirk_billing_checkout and kirk_billing_show.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, including a specific alternative (real-time cost via `_cost` envelope).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_bulk_howtoGet Bulk Scoring ClientARead-onlyInspect
Return a self-contained stdlib Python client for scoring at ZERO per-call LLM tokens.
Purpose: Hand the caller a Path-A 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 a Path A HTTP consumer of the same MCP endpoint. For sub-millisecond in-process scoring, move to Path B (wheel), Path C (OpenShift Operator), or Path D (Nitro Enclave AMI).
Cost: 0 IU. Free tool. The returned client, once running locally,
pays 1 IU per scored book (same rate as kirk_score_book) with
no LLM tokens on top.
Cost comparison (2,700,000-book Test-1 rerun): MCP via Sonnet 5: $1,968 + ~15 days wall clock MCP via Haiku 4.5: $656 + ~10 days Python client (this tool): $0.00 + ~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) }
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds extensive context: cost-steering capability class, zero IU cost, path fit options, and cost comparison numbers. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded with purpose. Some verbosity in cost comparison and path details, but every sentence adds value. Very clear overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and description additionally provides return structure example. Explains cost, use cases, and alternatives comprehensively. No gaps for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% trivial. Description does not need to add parameter meaning, which is appropriate. Baseline 4 for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a Python client for bulk scoring with zero per-call LLM tokens. Distinguishes from siblings by explicitly contrasting with kirk_score_book and kirk_score_book_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (more than ~200 books, batch_too_large, autonomous bulk) and when not to (one-off interactive calls). Provides explicit alternative: 'direct kirk_score_book invocation is simpler'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_healthzCheck Kirk Engine HealthARead-onlyInspect
Ping the sealed backend, confirm engine identity, return the sha256 of the running scoring binary.
Purpose: Verify which Kirk build is currently serving scoring calls. Response carries the sealed engine sha (kirk_version) that will stamp any subsequent kirk_score_* result.
Use when: You want to record engine sha in your own provenance log before capturing scoring output, or you want a cheap liveness probe 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 verify identity via wheel sha (Path B), OpenShift KBS quote (Path C), or Nitro Enclave PCR0 measurement (Path D) — all four paths ship the same sealed binary sha.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and non-destructive. Description adds cost (0 IU), specific return fields, error behavior, and capability class, providing transparent behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Purpose, Use, Cost, Returns). Slightly verbose but each sentence adds value. Could be tightened slightly, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existing annotations+output schema, the description covers all necessary context: purpose, usage, behavioral traits, cost, return structure, and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters. Schema coverage 100%. Baseline is 4; description does not need to add parameter info as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pings the backend, confirms engine identity, and returns the SHA. It distinguishes from siblings (e.g., scoring tools) by emphasizing it returns identity/liveness only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (record engine SHA, liveness probe) and when not to use (scoring results). Also mentions alternative validation paths, guiding the agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_infer_legacyScore Legacy Feature VectorARead-onlyInspect
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 via Path B (in-process wheel), Path C (OpenShift Operator), or Path D (Nitro Enclave AMI).
Cost: 1 IU per call. For agent-driven callers, per-call LLM tokens accrue on top; the response _cost envelope surfaces both.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | 50 floats. kirk-server renders these internally into the 50-element sample the sealed engine consumes. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds capability class (C2), path fit details, cost (1 IU) and LLM token overhead, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections and front-loaded purpose. Every sentence serves a purpose, though slightly verbose; could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (legacy surface, cost model, deployment paths), the description covers purpose, usage, behavior, and cost comprehensively. Output schema exists, so return details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'values' (50 floats). Description adds that kirk-server renders these internally, which is minor extra context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Score', the resource '50-value feature vector', and the legacy route '/v1/infer'. It explicitly distinguishes from siblings like kirk_score_book for fresh integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'Use when' and 'Do not use when' sections with clear conditions. Provides alternatives (kirk_score_book, kirk_bulk_howto) and cautions against tight loops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_list_modelsList Kirk ModelsARead-onlyInspect
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. Operator tooling lives elsewhere.
Capability class(es): C5 (engine sha attested on every response).
Path fit: Validation via MCP (this tool). Path B (in-process wheel)
exposes the same registry via kirk_cascade.list_models().
Cost: 0 IU. Free tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, destructiveHint=false), description adds that each response bears an attested engine sha, capability class C5, and cost zero. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with labeled sections (Purpose, Use when, Do not use when, Capability class, Path fit, Cost). Each sentence adds unique value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, annotations, and presence of an output schema, the description fully covers purpose, usage, behavioral details, and additional context (engine sha, cost) without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%), so baseline is 4. Description does not need to add parameter details; it correctly omits them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool enumerates model_ids and provides the engine sha. It distinguishes from siblings by noting it's for discovering model_ids for scoring calls and intentionally does not expose hyperparameters, which is a clear differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (first-time client wiring, need model_ids for score_book calls) and when-not-to-use (need hyperparameter detail). Also mentions cost (0 IU), giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_render_bookRender Order Book TensorARead-onlyInspect
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 Test-1 reference, 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 kirk_cascade.run_cascade() consumes on Path B.
Cost: 0 IU. Free tool.
| Name | Required | Description | Default |
|---|---|---|---|
| ask_px | Yes | 10 ask prices, level 1 first. | |
| bid_px | Yes | 10 bid prices, level 1 first. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so no mutation. Description adds context: 'No sealed-engine interaction', 'prep-only', 'Capability class(es): Local prep', and 'Cost: 0 IU'. This goes beyond annotations to clarify behavioral traits like no engine invocation and zero cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (purpose, use when, do not use, capability class, path fit, cost). It is informative but not overly verbose. Could be slightly tighter, but each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context: 'Has output schema: true') and comprehensive annotations, the description covers purpose, usage, behavioral constraints, and cost. It references sibling tools and the broader workflow (Path B, Test-1 reference). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both bid_px and ask_px described as arrays of 10 numbers, level 1 first). The description does not add extra semantics beyond what the schema already says; it reiterates the purpose but not the parameters themselves. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Render an L2 order-book snapshot into the 20×20 complex128 thermometer tensor WITHOUT invoking the sealed engine.' The verb 'Render' and resource 'Order Book Tensor' are specific. It distinguishes from sibling 'kirk_score_book' by noting this is prep-only and not for scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Use when' (sanity-check, inspect pattern, debug) and 'Do not use when' (need entropy score, use kirk_score_book). Also mentions 'Cost: 0 IU' and 'Local prep for the C2 workflow'. Provides clear guidance on when to use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_score_bookScore Single Order BookARead-onlyInspect
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 speed lives in-process (Path B wheel, Path C OpenShift Operator, or Path D Nitro Enclave AMI); 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ask_px | Yes | 10 ask prices, level 1 first. Same NaN convention. | |
| bid_px | Yes | 10 bid prices, level 1 first. NaN allowed for missing levels. | |
| model_id | No | Registered single-layer model. Defaults to the Jarett Test-1 winner (`kirk-test1-binary-threshold-v1`). | kirk-test1-binary-threshold-v1 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by detailing behavioral traits: sealed engine with attestation, bit-exact reproducibility, rate limit (60 req/min), and cost (1 IU per call). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, front-loading the core purpose. While not excessively verbose, it could be slightly tighter without losing information. Score 4 for good organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, output schema exists, annotations present), the description covers purpose, usage constraints, cost, rate limits, and path fit. It assumes some domain knowledge (e.g., 'sealed single-layer path') but is appropriate for the target audience.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 3 parameters. The tool description does not add additional parameter-level details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('score'), the resource ('L2 order-book snapshot'), and the outputs ('scalar entropy plus engine attestation'). It distinguishes from sibling tools like kirk_score_book_batch (batch) and kirk_bulk_howto (for bulk processing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'Use when' and 'Do not use when' sections, providing clear context for appropriate usage (validation, interactive) and exclusions (throughput, per-book loops). It also recommends an alternative (kirk_bulk_howto for >200 books).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_score_book_batchScore Batch of Order BooksARead-onlyInspect
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 live in-process on Path B (wheel), Path C (OpenShift Operator), or Path D (Nitro Enclave AMI); the MCP round-trip is inappropriate for high-throughput consumption.
Cost: 1 IU per call regardless of batch size (Gate 3 flat rating; per-batch scaling ships with Gate 6). LLM-agent-scoped cap at 500 books; use kirk_bulk_howto for anything larger.
| Name | Required | Description | Default |
|---|---|---|---|
| books | Yes | list of book dicts (bid_px, ask_px, sizes...). Max 500 per call — larger batches raise a structured `batch_too_large` error pointing at kirk_bulk_howto. | |
| model_id | No | registered model_id (see kirk_list_models). | kirk-test1-binary-threshold-v1 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description discloses cost (1 IU), batch limit behavior (structured error for >500), capability classes (C2, C5, C6), path fit (MCP vs production), and reproducibility guarantees. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with headings (Purpose, Use when, Do not use when, Capability class, Path fit, Cost). Each section adds unique value; no redundancy. Slightly verbose but not excessive for the information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (5 sibling tools, 2 params, output schema, annotations), the description covers all critical aspects: batch limits, error handling, cost, alternative paths, capability classes, and references to related tools. Output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds practical context: 'Max 500 per call' (already in schema) but also details cost, model_id default, links to kirk_list_models, and error behavior, enhancing agent understanding beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Score up to 500 L2 order-book snapshots'), the resource ('entropies list plus engine attestation'), and distinguishes from siblings like 'kirk_score_book' (single snapshots) and 'kirk_bulk_howto' (bulk).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do not use when' sections, naming alternatives such as 'kirk_bulk_howto' for sustained bulk work, and specifies limits (max 500 books).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_score_randomScore Random Synthetic BooksARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | RNG seed for reproducibility. | |
| model_id | No | Registered single-layer model. | kirk-test1-binary-threshold-v1 |
| n_samples | No | How many books to synthesize + score. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds significant context: it is a convenience wrapper, uses the same entropy path, costs 1 IU, routes through kirk_score_book_batch, and is not a production surface. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections, concise sentences, and no waste. It front-loads the core action and uses formatting (bold) for emphasis. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and clear context, the description covers purpose, usage, cost, capability class, and relationship to siblings. It is complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description does not need to add parameter details. However, it adds no additional meaning beyond the schema; for example, it mentions 'N' but the schema already describes n_samples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool synthesizes N realistic book snapshots and scores them, serving as a convenience wrapper on kirk_score_book_batch. It distinguishes itself from siblings by focusing on synthetic data for wiring checks rather than real scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: use for wiring checks, first integrations, or quick response reference; do not use for real scoring, instead use kirk_score_book_batch. This leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kirk_sweep_test1_daySweep Test-1 Day (Research)ARead-onlyInspect
Score one day of the Jarett Test-1 QQQ L2 corpus at a caller-supplied override via the desk-01 research daemon.
Purpose: Reproduce or extend a specific research configuration on the
published Test-1 corpus. Unlike kirk_score_book* (sealed backend,
fixed model configuration), this tool routes to a local research
daemon that accepts caller-supplied model overrides for
Milestone-D-Phase-B autoresearch.
Use when: You are doing research on the Test-1 corpus or reproducing a specific published sweep configuration.
Do not use when: You want an actual product signal — this is a research surface, not a customer capability. Sealed-engine scoring on your own data goes through kirk_score_book / kirk_score_book_batch instead. Also do not use if the caller is external — this tool targets the desk-01 daemon and is scoped for research reproduction.
Capability class(es): None on the customer-advertised C1-C6 axis. Internal research surface; the daemon exercises the same engine binary (so C5 attestation still applies) but override behaviour is out of scope for the customer capability map.
Path fit: Path A research daemon on desk-01. Not a Path B / C / D surface — there is no in-process wheel exposure of this endpoint.
Cost: 1 IU per call. The scoring binary is byte-identical to the sealed multi-cloud sha, so engine identity is attested on every response regardless of the caller's overrides.
| Name | Required | Description | Default |
|---|---|---|---|
| hp | Yes | Model override dict passed through to the research daemon. Accepted keys are documented in the operator research runbook and are intentionally not enumerated here (LEAK-1). Missing keys fill from the Test-1 baseline. | |
| day | Yes | ISO date string, e.g. `"2020-01-13"`. Must be present in the Test-1 day manifest. | |
| batch_size | No | Cold-per-batch size. Default 100 matches Phase A. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context: cost (1 IU), research vs. customer capability, engine identity attestation, and path fit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and a front-loaded summary. Some redundancy (e.g., 'research daemon' repeated), but overall efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, usage, behavior, cost, capability class, and path fit. Output schema exists externally, so return values need not be explained. Comprehensively addresses agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds value by explaining the 'hp' parameter as a model override dict, noting intentional omission of keys (LEAK-1), and mentioning the day must be in the Test-1 manifest. This goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Score') and resources ('one day of the Jarett Test-1 QQQ L2 corpus') and explicitly distinguishes from siblings like kirk_score_book* by noting the research daemon and caller-supplied overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'Use when' and 'Do not use when' sections, names alternatives (kirk_score_book, kirk_score_book_batch), and warns against external callers. Clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!