Skip to main content
Glama
Sign In

Kellian

by app.kellian
OverviewDiscussionsAdmin

Analyze static ask movement for a selected maker roster, with exact costs and explicit one-IOC limits

kellian_analyze_selected_makers
Read-onlyIdempotent

Read-only static selected-book ask movement on a public binary orderbook. Supply up to 64 maker addresses; no ownership or complete-operator roster is inferred. Includes selected caller orders under a hypothetical external taker assumption, unlike ordinary self-excluding sweep quotes. Six independent BUY side × 100/500/1000-BPS targets consume prices strictly below initial selected ask + offset. Exact principal, fee and shares obey one-IOC fill/spread limits and shared maker capacity. Exhaustion has no residual price. Partial or unavailable results must remain incomplete. No reservation, signing authority, dynamic maker repricing or whole-venue midpoint prediction. Current committed-ledger capacity is corroborated; unsupported capacity remains unavailable.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scope": "<scope>",
      "marketAddress": "<marketAddress>",
      "makerAddresses": "<makerAddresses>"
    },
    "name": "kellian_analyze_selected_makers"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeYes
chainIdNoCompiled protocol release chain ID (Base 8453).
marketAddressYes
makerAddressesYesExplicit client-selected roster, including any selected caller. At most 64 submitted addresses; normalized, deduplicated and sorted. The protocol does not infer ownership or roster completeness.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior on top: it is static (no repricing during the run), the external-taker assumption includes the caller's own orders, costs are exact principal/fee/shares subject to one-IOC limits and shared maker capacity, exhaustion leaves no residual price, and partial or unavailable results must stay marked incomplete. Those are real preconditions and output-shape expectations an agent cannot get from the annotations alone.

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

Conciseness5/5

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

No — see correction below.

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

Completeness4/5

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

The tool is analytically complex, and the description covers the assumptions (external taker, static book), the sizing grid, the cost semantics, and the incomplete-result policy, while an output schema exists so return formatting need not be restated. The remaining gap is that two of four parameters (chainId, scope) get no treatment, and the record-corroboration sentence is too cryptic to be actionable.

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?

With schema coverage at 50%, the description does add meaning for makerAddresses (explicit client-selected roster, caller must be included, no ownership or completeness inferred) and implies marketAddress via 'initial selected ask,' but it says nothing about chainId or the fixed scope constant, both of which the schema handles. Net effect is a modest supplement to a partially documented schema.

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

Purpose4/5

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

The opening clause names a specific verb and resource: read-only static ask movement over a client-supplied maker roster on a public binary orderbook, and it distinguishes itself from 'ordinary self-excluding sweep quotes.' It is recognizable as a simulation/analysis tool rather than a read of the live book, but the density of protocol jargon ('selected-book', 'one-IOC fill/spread limits', 'committed-ledger capacity') makes the core purpose harder to grasp than it needs to be.

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

Usage Guidelines3/5

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

The description draws the boundary against one unnamed alternative ('ordinary self-excluding sweep quotes') and lists things it does not do (no reservation, no signing authority, no dynamic maker repricing, no whole-venue midpoint prediction). That is scope framing rather than routing: no sibling tool is named and no condition is given for choosing this over kellian_simulate_trade, kellian_estimate_market_order or kellian_get_market_depth.

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

All Kellian toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources