Kalshi 15-minute crypto markets, perps funding, liquidation math and bitcoin model edges.
Scored across 7 tools
Most tools target distinct questions: EV math (calculate_ev), odds conversion (convert_probability), position sizing (kelly_size), 15-minute boards (fifteen_min_board), and perp data (perps_board, perp_liquidation). The main overlap is commodity_edge, which bundles an EV edge read, a quarter-Kelly size, and a market ticket — functionality that also lives in calculate_ev and kelly_size, so an agent could plausibly route there incorrectly. Descriptions largely resolve this, but the boundary is not crisp.
All snake_case, and there is a readable split between action tools (calculate_ev, convert_probability, kelly_size, perp_liquidation) and board/overview tools (fifteen_min_board, perps_board). Minor deviations: noun-first vs verb-first conventions coexist, and 'perp_liquidation' (singular) vs 'perps_board' (plural) is inconsistent.
Seven tools is well within the ideal 3-15 range and each one covers a distinct analytic step of a trading desk workflow. Nothing appears redundant enough to be dead weight.
The surface covers the analytics lifecycle well: EV, edge discovery, odds conversion, sizing, market boards, and perp liquidation/funding. Gaps remain around portfolio/position tracking, order execution, and a general lookup for arbitrary Kalshi/Polymarket markets outside the covered 15-minute, commodity, and perp universes.
Use for "is this contract mispriced" and "what is my edge". Give a Kalshi or Polymarket price in cents and your own probability; returns the % expected-value edge and a BUY / SELL / SKIP read.
| Name | Required | Description | Default |
|---|---|---|---|
| marketPrice | No | Current contract price in cents (1–99), equal to the implied probability in %. Required for a real answer. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%. | |
| yourProbability | No | Your own estimate of the true probability the contract resolves YES, in % (0–100). Required for a real answer. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%. |
| Name | Required | Description |
|---|---|---|
| signal | No | BUY / SELL / SKIP. |
| edge_pp | No | Your probability minus the price, pp. |
| sources | No | |
| edge_pct | No | Expected-value edge, %. |
| tell_user | No | Show this sentence to the user first. |
| timestamp | No | |
| needs_input | No | |
| example_call | No | |
| data_freshness | No | |
| interpretation | No | Plain-English read. |
| market_price_cents | No | Price used, cents. |
| your_probability_pct | No | Probability used, %. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only, non-destructive, closed-world profile is already fully carried by annotations, so the description only needs to add what annotations cannot. It adds the output shape (percent edge + BUY/SELL/SKIP verdict), which is useful, but says nothing about whether SKIP means missing inputs, whether inputs are meaningful for real-money decisions, or any caveats. Adequate, not rich.
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?
Two tight sentences: intent triggers first, then inputs, then output. Nothing is repeated and nothing wastes space.
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 an output schema exists and inputs are fully documented, the description covers what an agent needs to call it. The one gap is the unexplained mismatch between "Required for a real answer" and required=false in the schema — the description hints at a degraded path without saying what happens when inputs are omitted.
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% and the schema already enumerates every accepted price format (cents, "55%", "$0.55", decimal, American odds). The description only restates "price in cents and your own probability," adding no format or edge-case meaning beyond the schema; baseline 3 applies.
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?
States a specific verb and resource (calculate expected-value edge from a market price and your own probability) and names the exact return (percent EV edge plus a BUY/SELL/SKIP read). The quoted user intents ("is this contract mispriced", "what is my edge") let an agent match it against sibling tools like kelly_size or convert_probability without ambiguity.
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?
"Use for ..." plus the required inputs (Kalshi/Polymarket price in cents and your own probability) gives clear triggering conditions. It never names an alternative or states when NOT to use it, so an agent choosing between this and kelly_size or convert_probability must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for "gold edge today" and "oil or bitcoin trade signal". The Kalshi daily gold, silver or WTI strike, or hourly bitcoin strike, with the largest PMP model edge, as a ticket: side, entry price, resolve criterion, model probability, edge, tier and quarter-Kelly size. Pass tickers[] to check a watchlist. Pro — sign in with PredictionMarketsPicks, or a Pro API key.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | No | Optional Kalshi ticker watchlist (up to 25), market or event tickers. Unmodeled tickers return not_covered. | |
| commodity | No | Which commodity edge to read (needed for a real answer). One of: silver · bitcoin · gold · oil. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context beyond them: Pro authentication via PredictionMarketsPicks or a Pro API key, and the ticket fields the caller receives. It does not discuss rate limits or unmodeled-ticker behavior in prose, though the schema covers the latter.
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 dense and front-loaded, moving from use cases to output shape to watchlist mode to auth. It earns most of its length, though the long middle sentence listing ticket fields could be tightened.
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 read-only tool with no output schema and only two parameters, the definition is complete: it explains what the tool returns, how to use the optional watchlist parameter, and the authentication prerequisite. Nothing an agent needs to call it correctly is missing.
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%, so parameter documentation is already strong. The description adds only marginal guidance—pass tickers[] for a watchlist and commodity is needed for a real answer—which largely mirrors the schema descriptions.
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 states a specific resource and output: the Kalshi commodity strike with the largest PMP model edge, returned as a ticket with side, entry price, resolve criterion, model probability, edge, tier, and quarter-Kelly size. This clearly distinguishes it from generic calculator/board siblings like calculate_ev or perps_board.
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?
It gives explicit trigger phrases ("gold edge today", "oil or bitcoin trade signal") and explains the watchlist mode via tickers[]. It does not name a sibling alternative or state when not to use it, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between implied probability, American odds, and decimal odds. Give one value and its format and get all three back (American odds carry no commas, e.g. +441 or -200). Use for "what is +150 as a probability", "convert 62% to American odds", "decimal to implied odds".
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | The numeric value to convert. Needed for a real answer, with format. | |
| format | No | Format of `value`: probability (0–100 %), american (e.g. -200 / +150), or decimal (e.g. 2.5). One of: probability · american · decimal. |
| Name | Required | Description |
|---|---|---|
| sources | No | |
| tell_user | No | Show this sentence to the user first. |
| timestamp | No | |
| needs_input | No | |
| decimal_odds | No | Decimal odds. |
| example_call | No | |
| american_odds | No | American odds, no commas. |
| data_freshness | No | |
| probability_pct | No | Implied probability, %. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description correctly frames this as a pure computation. It adds real behavioral value by specifying that all three representations are returned and by stating the American-odds formatting convention (no commas, e.g. +441 or -200).
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?
Three tight sentences with zero filler: purpose, then round-trip behavior, then invocation examples. The core capability is front-loaded before the examples.
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?
With an output schema present, the description needn't enumerate return values, and it appropriately just says all three are returned. Minor gap: the accepted ranges/edge cases (e.g. invalid probability bounds) aren't touched, but that's largely covered by the schema's own range note.
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 the baseline is 3; the description earns above that by explicitly documenting the accepted American-odds notation ('+441 or -200' with no commas), which the schema does not spell out. It does not otherwise add detail beyond the schema's own format explanation.
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?
States a specific verb (convert) and resource (implied probability / American odds / decimal odds), and makes the bidirectional nature explicit ('give one value... get all three back'). This clearly separates it from siblings like calculate_ev or kelly_size, which consume odds rather than convert them.
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?
Three concrete user-intent examples ('what is +150 as a probability', 'convert 62% to American odds', 'decimal to implied odds') make it obvious when to reach for this tool. It stops short of explicitly naming alternatives or exclusion conditions, so it lands just below the top mark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for "what is the ETH 15-minute market doing" and "which Kalshi 15-minute markets are open". Every Kalshi 15-minute up-or-down series (crypto, metals, energy, FX): window status, YES price, close time, target, settlement source and the up rate over the last 96 windows; the same window on Polymarket international for BTC/ETH/SOL/XRP; and our live Bitcoin top-of-hour strategy with its record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows (default 30). | |
| series | No | One series: ticker (KXETH15M) or asset ("eth", "gold", "euro"). | |
| horizon | No | 15m (Kalshi, default) or 5m (Polymarket US BTC/ETH/SOL/XRP; Kalshi lists none). One of: 15m · 5m. | |
| open_only | No | Only series with a window open right now (default false). | |
| asset_class | No | crypto · commodity · currency · all (default all). |
| Name | Required | Description |
|---|---|---|
| rows | No | Kalshi 15-minute series: window status, YES price, close time, target, settlement source, up rate; for BTC/ETH/SOL/XRP the same window on Polymarket (international, live book: price_source, as_of), and on the Bitcoin row venue_record — the two venues graded on the same windows. |
| as_of | No | When the board was read. |
| sources | No | |
| our_model | No | Bitcoin only: our published top-of-hour strategy — version and status ("current version": it stays until it breaks), live_record (our own Kalshi account, after fees), paper record, last_call (the bot's newest decision for a closed window; source bot or paper), next decision time, and current_call: the bot's own :55 decision for the open window (PLAY = live, WATCH = paper). |
| tell_user | No | Show this sentence to the user first. |
| timestamp | No | |
| needs_input | No | |
| example_call | No | |
| data_freshness | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-destructive, so the description sensibly spends its words on payload behavior instead: that it blends Kalshi with Polymarket international data and includes a live strategy record, which explains the openWorld hint. It omits freshness/refresh cadence and result ordering, so it's strong but not complete.
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 use-case triggers are front-loaded and the description is essentially one dense but readable sentence with no filler. The payload enumeration is long enough that some readers will skim, but every clause carries real information.
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?
With an output schema present, the description needn't document return shapes, and it still tells the agent the scope (all 15-min series plus Polymarket and the BTC strategy), that data is live, and the historical depth (96 windows). Nothing an agent needs before calling is missing.
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%, so every parameter's meaning is already spelled out structurally. The description adds only indirect hints (the asset families covered, the 15m vs 5m split), and never explains limit, open_only, or series selector behavior beyond the 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?
States a concrete verb+resource: a live board of every Kalshi 15-minute up-or-down series, and enumerates exactly what each row carries (window status, YES price, close time, target, settlement source, up rate over 96 windows). It also names the non-obvious extra content (Polymarket international comparison, Bitcoin top-of-hour strategy record), which no sibling covers.
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?
Opens with two explicit trigger questions ('what is the ETH 15-minute market doing', 'which Kalshi 15-minute markets are open'), which gives clear usage context. It does not name an alternative tool or a when-not-to-use condition, so the top mark isn't earned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the optimal Kelly position size for a prediction-market contract. Given your win probability, the market price (which sets the payout), your bankroll, and a Kelly fraction (full / half / quarter / eighth), returns the dollar stake and a risk rating. Use for "how much should I stake", "what is my position size", "Kelly sizing for this trade".
| Name | Required | Description | Default |
|---|---|---|---|
| bankroll | No | Total bankroll in dollars (e.g. 1000). Optional — omit it and the result is the % of bankroll to stake, without a dollar figure. | |
| fraction | No | Kelly fraction to apply. Half-Kelly is the common sharp-money default. One of: full · half · quarter · eighth. | |
| marketPrice | Yes | Contract price in cents (1–99). Sets the payout ratio. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%. | |
| winProbability | Yes | Your probability the contract resolves YES, in % (0–100). Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%. |
| Name | Required | Description |
|---|---|---|
| rating | No | Qualitative read of the sizing. |
| sources | No | |
| tell_user | No | Show this sentence to the user first. |
| timestamp | No | |
| needs_input | No | |
| example_call | No | |
| stake_dollars | No | Suggested stake in dollars (when a bankroll was given). |
| data_freshness | No | |
| full_kelly_pct | No | Full-Kelly fraction of bankroll, %. |
| applied_fraction_pct | No | The fraction applied, %. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds the meaningful behavior that omitting bankroll switches the output from a dollar stake to a percentage of bankroll. It doesn't state edge-case behavior (e.g. zero or negative Kelly implying no bet), leaving a small gap.
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?
Three sentences, front-loaded with the verb+resource, then inputs, then return values, then routing phrases. No sentence restates the title or wastes space.
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?
With an output schema present, the description needn't spell out return structure, and it still names the two returned values. Annotations plus 100% schema coverage leave little burden, though a note on zero/negative-edge outcomes would fully close the loop for a numeric advisory 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?
Schema description coverage is 100%, so the baseline is 3; the schema already documents the flexible price/probability formats, the fraction enum values, and bankroll optionality. The description only reinforces that market price sets the payout and lists the fraction tiers, adding little beyond the structured fields.
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?
States a specific verb and resource — 'Compute the optimal Kelly position size for a prediction-market contract' — and the returned artifacts (dollar stake, risk rating). It is clearly distinguishable from siblings like calculate_ev and convert_probability, which handle EV math and odds conversion rather than sizing.
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?
Three quoted user intents ('how much should I stake', 'what is my position size', 'Kelly sizing for this trade') give concrete routing signals. It stops short of naming when NOT to use it or pointing to calculate_ev as the alternative for edge-only questions, so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for "where does a 5x bitcoin long liquidate on Kalshi". Estimates a Kalshi perp's liquidation price and the % move to it from Kalshi's risk parameters (a 5x BTC long is about 8% away, not the 20% the 100÷leverage rule implies), plus fees and expected funding. An estimate; Kalshi's app shows the exact one. Assets: btc, eth, sol, xrp, doge, hype, link, gold, silver, platinum, palladium. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | Direction. One of: long · short. | |
| asset | No | The perp. | |
| entry | No | Entry price (default: the live price). | |
| margin | No | Margin in dollars (default 1000). | |
| leverage | No | Leverage, e.g. 5 or "5x". Capped at Kalshi’s maximum for the size and side. | |
| hold_days | No | Days held, for the funding estimate (default 7). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds meaningful behavioral context beyond that: it is an estimate, Kalshi's app shows the exact value, it includes fees and funding, leverage is capped at Kalshi's maximum, and the tool is free. The exactness caveat is particularly useful for a read-only estimator.
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 front-loaded example query immediately anchors the tool's use case, followed by the core estimate, caveat, supported assets, and cost. Every sentence earns its place and there is no redundant restatement of schema fields.
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?
With no output schema, the description must indicate what comes back. It does so at a high level: liquidation price, % move, fees, and expected funding. It does not specify units or response structure for fees and funding, but for a read-only estimator this is close to complete.
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%, so the baseline is 3. The description adds conceptual meaning by explaining that a 5x BTC long is about 8% away rather than the 20% implied by 100÷leverage, which clarifies how leverage and entry interact with the liquidation estimate. It also notes funding depends on hold_days, though not each parameter in detail.
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 states a specific verb and resource: 'Estimates a Kalshi perp's liquidation price and the % move to it,' plus fees and expected funding. It also distinguishes its result from the naive 100÷leverage rule, making the purpose concrete and separable from generic calculators like calculate_ev or kelly_size.
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 example query 'where does a 5x bitcoin long liquidate on Kalshi' gives a clear when-to-use signal. However, it does not explicitly name or exclude alternatives like perps_board, so the agent must infer that this tool is for liquidation distance rather than broad perp exploration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for "Kalshi perps funding rate" and "how much leverage on Kalshi gold perps". Every Kalshi perpetual future: price, 24h volume, open interest, max leverage long and short, funding cadence, and what funding has cost a long since launch. Pass asset ("btc", "gold") for one.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | One perp: symbol or name ("btc", "gold", "XAG"). | |
| limit | No | Max rows (default 25). |
| Name | Required | Description |
|---|---|---|
| rows | No | Kalshi perps: price, 24h volume, open interest, max leverage, funding. |
| as_of | No | When the board was read. |
| sources | No | |
| tell_user | No | Show this sentence to the user first. |
| timestamp | No | |
| needs_input | No | |
| example_call | No | |
| data_freshness | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that it aggregates derived metrics (funding cost since launch) but says nothing about data freshness, rate limits, pagination, or what happens when asset doesn't match — modest added 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?
Three short sentences, front-loaded with the search phrasings an agent would map to this tool, then the payload contents, then the narrowing parameter. No filler.
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?
With an output schema present, return values needn't be spelled out, yet the description still summarizes the payload well. Minor gaps around freshness and interaction with limit/pagination keep it from a 5, but an agent has everything needed to invoke it 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?
Schema coverage is 100% and the schema already names both parameters with examples ("btc", "gold", "XAG") and a default of 25. The description's "Pass asset (\"btc\", \"gold\") for one" restates what the schema documents, so baseline 3 applies.
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?
States a specific resource (every Kalshi perpetual future) and enumerates exactly what it returns — price, 24h volume, open interest, max leverage long/short, funding cadence, cumulative funding cost to a long. An agent can immediately tell this is a board/screener rather than a single-perp query like perp_liquidation.
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?
Opens with two concrete example queries ("Kalshi perps funding rate", "how much leverage on Kalshi gold perps") that anchor when to reach for it, and says passing asset narrows to one entry. It stops short of naming a sibling alternative or an explicit when-not condition, so it lands just under the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fifteen_min_board1 field changedInput schema / properties / horizonAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "enum": [
+ "15m",
+ "5m"
+ ],
+ "type": "string"
+ }
+ ],
+ "description": "15m (Kalshi, default) or 5m (Polymarket US BTC/ETH/SOL/XRP; Kalshi lists none). One of: 15m · 5m."
+}calculate_ev2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"commodity_edge2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / tickers / descriptionPrevious value: -"Optional Kalshi ticker watchlist (up to 25) — e.g. paste the tickers from your Kalshi Pro screener or Canvas to get PMP's edge on exactly those markets. Full market or 3-segment event tickers both work. Tickers PMP doesn't model are returned as not_covered (never a fabricated edge)."New value: +"Optional Kalshi ticker watchlist (up to 25), market or event tickers. Unmodeled tickers return not_covered."convert_probability3 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / value / descriptionPrevious value: -"The numeric value to convert. Needed for a real answer, with format. Accepts a number or a numeric string (\"+150\", \"62%\", \"2.5\")."New value: +"The numeric value to convert. Needed for a real answer, with format."Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"fifteen_min_board3 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / limit / descriptionPrevious value: -"Max rows (default 30). Values above 40 are clamped to 40."New value: +"Max rows (default 30)."Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"kelly_size3 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / bankroll / descriptionPrevious value: -"Total bankroll in dollars (e.g. 1000). Optional — omit it and the result is the % of bankroll to stake, without a dollar figure. Accepts a number or a numeric string (\"1000\", \"$1,000\")."New value: +"Total bankroll in dollars (e.g. 1000). Optional — omit it and the result is the % of bankroll to stake, without a dollar figure."Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"perp_liquidation4 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / asset / descriptionPrevious value: -"The perp. One of: btc · eth · sol · xrp · doge · hype · link · gold · silver · platinum · palladium."New value: +"The perp."Input schema / properties / entry / descriptionPrevious value: -"Entry price (default: the live price). Accepts a number or a numeric string (\"+150\", \"62%\", \"2.5\")."New value: +"Entry price (default: the live price)."Input schema / properties / margin / descriptionPrevious value: -"Margin in dollars (default 1000). Accepts a number or a numeric string (\"+150\", \"62%\", \"2.5\")."New value: +"Margin in dollars (default 1000)."perps_board3 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / limit / descriptionPrevious value: -"Max rows (default 25). Values above 30 are clamped to 30."New value: +"Max rows (default 25)."Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"fifteen_min_board2 fields changedOutput schema / properties / our_model / descriptionPrevious value: -"Bitcoin only: our published top-of-hour rule — status (WATCH = the current version), paper record, last graded call, next decision time, and current_call: the bot's own :55 decision for the open window (PLAY = live, WATCH = paper)."New value: +"Bitcoin only: our published top-of-hour strategy — version and status (\"current version\": it stays until it breaks), live_record (our own Kalshi account, after fees), paper record, last_call (the bot's newest decision for a closed window; source bot or paper), next decision time, and current_call: the bot's own :55 decision for the open window (PLAY = live, WATCH = paper)."Output schema / properties / rows / descriptionPrevious value: -"Kalshi 15-minute series: window status, YES price, close time, target, settlement source, up rate."New value: +"Kalshi 15-minute series: window status, YES price, close time, target, settlement source, up rate; for BTC/ETH/SOL/XRP the same window on Polymarket (international, live book: price_source, as_of), and on the Bitcoin row venue_record — the two venues graded on the same windows."fifteen_min_board1 field changedOutput schema / properties / our_model / descriptionPrevious value: -"Bitcoin only: our published top-of-hour rule — status (WATCH until it passes), paper record, last graded call, next decision time, and current_call: the bot's own :55 decision for the open window (PLAY = live, WATCH = paper)."New value: +"Bitcoin only: our published top-of-hour rule — status (WATCH = the current version), paper record, last graded call, next decision time, and current_call: the bot's own :55 decision for the open window (PLAY = live, WATCH = paper)."calculate_ev4 fields changedInput schema / properties / marketPrice / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / marketPrice / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / yourProbability / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / yourProbability / typeAdded value: +[
+ "number",
+ "string"
+]convert_probability2 fields changedInput schema / properties / value / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / value / typeAdded value: +[
+ "number",
+ "string"
+]fifteen_min_board2 fields changedInput schema / properties / limit / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "string"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / limit / typeAdded value: +[
+ "number",
+ "string",
+ "null"
+]kelly_size6 fields changedInput schema / properties / bankroll / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / bankroll / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / marketPrice / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / marketPrice / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / winProbability / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / winProbability / typeAdded value: +[
+ "number",
+ "string"
+]perp_liquidation6 fields changedInput schema / properties / entry / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / entry / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / leverage / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / leverage / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / margin / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / margin / typeAdded value: +[
+ "number",
+ "string"
+]perps_board2 fields changedInput schema / properties / limit / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "string"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / limit / typeAdded value: +[
+ "number",
+ "string",
+ "null"
+]fifteen_min_board1 field changedOutput schema / properties / our_model / descriptionPrevious value: -"Bitcoin only: our published top-of-hour rule — status (WATCH until it passes), paper record, last graded call, next decision time."New value: +"Bitcoin only: our published top-of-hour rule — status (WATCH until it passes), paper record, last graded call, next decision time, and current_call: the bot's own :55 decision for the open window (PLAY = live, WATCH = paper)."fifteen_min_board1 field changedOutput schema / properties / our_modelAdded value: +{
+ "description": "Bitcoin only: our published top-of-hour rule — status (WATCH until it passes), paper record, last graded call, next decision time."
+}calculate_evcommodity_edgeconvert_probabilityfifteen_min_boardkelly_sizeperp_liquidationperps_boardKalshi macro: Fed rate odds, gold, silver, oil and bitcoin edges, 15-min markets, Kelly sizing.
Perp funding rates, open interest, futures basis, IV, liquidations, order books on 8 exchanges
Live Kalshi and Polymarket data: EV edges, cross-venue arbitrage, markets, and whale trades.
Live perp funding rates across 6 venues (Hyperliquid, Binance, Bybit, Lighter...) and arbitrage.
Add one secure layer between your agents and this server.
