Sardine: Kalshi crypto settlement history

get_settlement_rate

Read-onlyIdempotent

How often has a contract like this one settled in favour of side?

    Uses the asset's live spot price. Give the contract's strike (target
    price), the minutes left until it settles, and optionally Kalshi's ask
    in dollars (0.01-0.99) to get Kalshi's fee and all-in price on the same
    line.

    Returns the historical settlement rate, its 95% interval, the number of
    past windows counted, the 1-minute realised vol and z behind the lookup,
    and with `kalshi_ask`: the fee, the all-in price and the gap after fee
    (`gap_after_fee`, `gap_cents`, signed: positive means history is above
    the price). A small `windows_counted` means a weak answer.

Input Schema

Name	Required	Default
`side`	No	YES
`asset`	Yes
`strike`	Yes
`kalshi_ask`	No
`minutes_left`	Yes
`window_minutes`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the standard read-only annotations, the description adds critical behavioral traits. Most importantly, it explains the data quality of the output, warning that 'A small `windows_counted` means a weak answer,' which is vital for user expectation management.

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 structure is highly logical, first presenting the core concept and input requirements, followed by a detailed breakdown of all possible return values. The detail is extensive, though it requires a high level of patience from the agent.

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?

Given the complexity (multiple inputs and a list of 7 highly specific output parameters), the description is remarkably complete. It covers not just what is returned, but the meaning of specialized metrics like 'gap after fee' and the necessity of high `windows_counted` values.

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

Parameters5/5

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

Schema description coverage is 0%, meaning the description must carry all semantic weight. It succeeds by explaining the financial implication of the optional `kalshi_ask` (to get fee and all-in price) and clarifying what `window_minutes` signifies.

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 primary purpose: answering 'How often has a contract like this one settled in favour of side?' It immediately frames the tool's function in the context of historical settlement rates.

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?

While it describes the required inputs (strike, minutes left, etc.), it does not provide explicit guidance on when to use this specific tool versus related sibling tools like `get_lead` or `get_rate_table`. It implies usage through parameter description but lacks comparative context.

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

All Sardine: Kalshi crypto settlement history tools Inspect

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

Need Help?