Kalshi weather markets: daily-high board beside the NWS forecast, live edges, EV, Kelly, base rates.
Scored across 7 tools
The calculators (base_rate_gap, calculate_ev, kelly_size, bayes_update, convert_probability) each target a distinct quantitative operation, and weather_board is clearly market data. The mild overlap is that calculate_ev, base_rate_gap, and edge_alerts all orbit the 'find my edge' theme, though one is a calculator, one a base-rate comparator, and one a live feed.
All names use snake_case, but the pattern mixes verb_noun (calculate_ev, convert_probability, bayes_update) with noun_phrases (base_rate_gap, kelly_size, edge_alerts, weather_board). It remains readable but is not a single predictable convention.
Seven tools is well-scoped for a prediction-market edge desk, with each tool earning its place across probability math, edge detection, sizing, and market data. Nothing feels padded or redundant.
The surface covers the analytical lifecycle well: base-rate comparison, Bayesian updating, EV, probability conversion, Kelly sizing, alerts, and weather market data. Minor gaps exist around portfolio-level tracking or historical market data beyond the weather board, but core workflows are covered.
Use for "how does this price compare to history" and "is the market ignoring the base rate". Compares a market price with the historical base rate for a class of events: the gap in pp, a signal, and sample-size quality. Pass a known baseRateId (the parameter lists them) or your own baseRateValue.
| Name | Required | Description | Default |
|---|---|---|---|
| baseRateId | No | Known base-rate id to look up (includes sample size + source). One of: incumbent_reelected · fed_hold_unemp_below_4 · fed_cut_cpi_above_3 · recession_called_12mo · sp500_positive_year · bitcoin_above_100k_eoy · gdp_growth_above_2 · cpi_above_3 · senate_incumbent_wins_primary · vix_below_20_eoy · interest_rate_cut_next_meeting · major_sports_upset. | |
| marketPrice | No | Current market price in cents / implied probability % (0–100). Needed for a real answer. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%. | |
| baseRateValue | No | Your own base rate in % (0–100), used when no baseRateId is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the return payload — gap in percentage points, a signal, and sample-size quality — which matters since no output schema exists.
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 sentences, front-loaded with the triggering questions before the mechanics, with no filler. The nested quotation marks are slightly awkward but don't impede parsing.
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 compute tool with no output schema, the description adequately covers inputs, the identifier-or-value choice, and the shape of the result. It doesn't clarify what happens when marketPrice is omitted despite zero required parameters, a minor gap.
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 baseRateId enums, marketPrice input formats, and baseRateValue ranges in more detail than the description. The only added meaning is the either/or relationship between baseRateId and baseRateValue.
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: 'Compares a market price with the historical base rate for a class of events,' and enumerates the outputs (gap in pp, signal, sample-size quality). That scope is clearly distinguishable from siblings like calculate_ev, kelly_size, or convert_probability, which handle different computations.
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?
Gives explicit user-phrasing triggers ('how does this price compare to history', 'is the market ignoring the base rate') that map a real question to this tool. It stops short of naming alternatives or stating when-not to use it, e.g. versus calculate_ev.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a prior probability with one or more pieces of evidence using Bayes theorem. Given a prior and a list of evidence items (each with P(evidence | true) and P(evidence | false)), returns the posterior probability and the per-step chain. Use for "update my estimate with new information", "posterior probability", "how does this news change the odds".
| Name | Required | Description | Default |
|---|---|---|---|
| prior | No | Prior probability the hypothesis is true, in % (0–100). Needed for a real answer. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%. | |
| evidence | No | One or more evidence items, applied in order. Each item needs likelihoodIfTrue and likelihoodIfFalse on the 0–100 scale, e.g. [{ "likelihoodIfTrue": 80, "likelihoodIfFalse": 20 }]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and a closed-world scope, so safety is covered. The description adds genuine behavioral context beyond that: evidence items are applied sequentially and the response contains the posterior plus the per-step chain, which matters because there is no output schema.
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 sentences, front-loaded with the computation and its return value, followed by trigger phrasing. Every clause carries information; nothing is padding.
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 correctly names what comes back (posterior and per-step chain), and the input schema fully documents both parameters. It does not address error or edge behavior (e.g. contradictory evidence, 0/100 likelihoods), which keeps it from a 5.
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 is unusually rich, documenting accepted formats (55, "55%", "55¢", "$0.55", 0.55, American odds) and the 0–100 scale. The description only restates the evidence likelihood semantics, so it adds little beyond the schema and the baseline of 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 (update) and resource (prior probability) plus the method (Bayes theorem) and the output (posterior plus per-step chain). This is clearly distinguishable from siblings such as convert_probability or calculate_ev, which do different math on different inputs.
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 'Use for...' clause supplies three concrete natural-language triggers that map cleanly onto this tool rather than its siblings. It gives no explicit exclusions or named alternatives (e.g. when to prefer base_rate_gap), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safe, side-effect-free nature is covered structurally. The description adds useful domain scope by tying the tool to Kalshi and Polymarket prices and previews the verdict output, but says nothing about rate limits, accuracy assumptions, or edge cases (e.g. price at 0/100).
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: the trigger/question framing is front-loaded, followed by the inputs and the returned outputs. No filler, no repetition of the schema.
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 need not explain the return payload, and with 100% schema coverage it need not document parameters. It covers purpose, trigger, and output shape. The remaining gap is cluster-level: no pointer to kelly_size for follow-on position sizing.
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 descriptions already enumerate every accepted input format (55, "55%", "55¢", "$0.55", 0.55, American odds). The description only paraphrases this as "in cents and your own probability", which is actually narrower than the schema. Baseline 3 is correct when the schema carries the semantics.
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 function: take a market price plus the user's own probability and return the % EV edge and a BUY/SELL/SKIP read. That is a clear verb+resource with an output preview. It does not distinguish itself from the related sibling kelly_size, which an agent might reasonably confuse it with.
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 'is this contract mispriced' and 'what is my edge'" gives an explicit when-to-use trigger in the user's own vocabulary. It offers no exclusions and never names the obvious downstream alternative (kelly_size for sizing once edge is known), so sibling routing is left to inference.
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. Accepts a number or a numeric string ("+150", "62%", "2.5"). | |
| 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, openWorldHint=false and destructiveHint=false, so the bar is low. The description still adds real behavioral context beyond them: the output always contains all three representations, and American odds use the no-comma convention (+441 or -200). It does not restate return format in detail, but an output schema exists so that is not required.
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 purpose, then output convention, then trigger examples. No filler, and the critical formatting caveat is parenthetical rather than buried. The quoted example phrases are slightly redundant with the purpose sentence, keeping this just below a 5.
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?
A pure two-parameter, read-only converter with an output schema, full schema description coverage and safety annotations. The description covers what it does, what comes back, the input convention quirk, and when to reach for it — nothing an agent needs in order 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 coverage is 100%, so the baseline would be 3. The description earns above baseline by explaining the no-comma American convention and illustrating accepted input strings ('+150', '62%', '2.5'), which clarifies the number-or-string typing in the schema. It does not, however, add anything not already implied about the range or enum semantics of `format`.
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 names a specific verb (Convert) and the exact resources (implied probability, American odds, decimal odds), and states the round-trip behavior (give one, get all three). An agent can immediately distinguish this from calculate_ev or kelly_size, which compute value or stake rather than reformat an odds figure.
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 concrete trigger phrasings ('what is +150 as a probability', 'convert 62% to American odds', 'decimal to implied odds'), which is strong positive routing. It stops short of naming a sibling as the alternative or stating when-not to use it (e.g. if you want expected value, use calculate_ev), so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for "any edge on Kalshi" and "weather trade signals". Our model alerts on Kalshi — weather, bitcoin/silver/gold/oil, mispricings — with feed, tier, side, price, model probability, edge and link. Real time with Pro; free is delayed 24h without the thesis. One identical, impersonal feed for every subscriber; filters only select. Informational, not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | Comma-separated feeds to include: weather, bitcoin, silver, gold, oil, mispricing, sports_arb, nfl. Omit for all. | |
| limit | No | Max alerts to return (default 25). Values above 100 are clamped to 100. | |
| since | No | ISO-8601 timestamp — only alerts created after it. | |
| min_tier | No | Minimum confidence tier (returns that tier and above). One of: SPECULATIVE · MODERATE · STRONG. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses tier-gated behavior (real time with Pro, free delayed 24h without the thesis), that the feed is identical and impersonal for every subscriber, that filters only select rather than personalize, and an informational-use disclaimer. These are exactly the behavioral traits annotations cannot carry.
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?
It is front-loaded with the usage trigger and packs payload, tiering, and disclaimers into a few compact sentences. The marketing-toned phrases ('any edge on Kalshi', 'One identical, impersonal feed') add some noise but are short.
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 compensates by enumerating the returned fields and explaining the real-time vs 24h-delayed access model and filter semantics. For a read-only feed with all four params documented in schema, 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 feed, limit, since, and min_tier are already fully documented in the schema. The description's list of 'feed, tier, side, price, model probability, edge and link' describes output fields, not parameter meaning, so it adds nothing to parameter interpretation. 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?
The description names the resource (Kalshi model alerts) and enumerates the covered categories (weather, bitcoin/silver/gold/oil, mispricings) plus the returned fields, so the agent knows this is a unified alert feed rather than a single-market board. It stops short of explicitly distinguishing itself from near siblings like weather_board, commodity_edge, or scan_mispricings.
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 opens with a direct usage trigger — 'Use for "any edge on Kalshi" and "weather trade signals"' — which gives the agent clear context for selection. However, it names no when-not conditions and does not route the agent to or away from the overlapping sibling tools.
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. Accepts a number or a numeric string ("1000", "$1,000"). | |
| 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that the tool is a pure computation returning a stake amount and a risk rating, which tells the agent there are no side effects. It doesn't discuss edge cases such as invalid probabilities or the meaning of the risk rating, keeping it short of a 5.
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 compact sentences, front-loaded with the core action and its inputs/outputs before the example triggers. Every sentence earns its place, though the trailing quoted-phrase list is slightly listy and could be trimmed.
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?
An output schema exists, yet the description still concisely previews the return ('dollar stake and a risk rating'), and it names all four inputs with the optional bankroll implication clear via the schema. For a stateless calculator this is fully sufficient to call 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 description coverage is 100%, so the schema already documents each parameter in detail (bankroll optionality, accepted price/probability formats, fraction values). The description restates the same inputs — 'win probability, market price (which sets the payout), your bankroll, a Kelly fraction (full / half / quarter / eighth)' — adding only the note that market price sets the payout. Baseline 3 is appropriate when the schema does the heavy lifting.
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 goes on to name the exact inputs and outputs, so it is clearly separable from siblings like calculate_ev and convert_probability. An agent knows immediately what this tool returns (dollar stake + risk rating).
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 concrete triggering phrases — "how much should I stake", "what is my position size", "Kelly sizing for this trade" — which give clear context for when to reach for this tool. It stops short of naming when NOT to use it or pointing to alternative siblings (e.g. calculate_ev for edge, not sizing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for "Kalshi NYC high temperature odds". Every open Kalshi daily-high strike in 13 cities: YES price, settlement station and source, the strict-comparison rule, close time, and the NWS forecast high beside it. Pass city ("nyc", "KXHIGHCHI"). Market data only.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | today · tomorrow · all (default). | |
| city | No | City name or series ("nyc", "KXHIGHTBOS"). Omit for all. |
| Name | Required | Description |
|---|---|---|
| rule | No | The strict comparison Kalshi settles on. |
| as_of | No | When the board was read. |
| cities | No | Per city and settlement day: NWS high, bias-adjusted high, close time, strikes with two-sided YES mids. |
| 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 readOnly/openWorld/destructive=false, so the safety profile is covered. The description adds real context beyond that: the strict-comparison settlement rule, the settlement station and source, and the close time — meaningful for interpreting the odds. No access requirements or throttling mentioned.
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: trigger phrase first, payload contents second, parameter hint and scope guard last. No redundant restatement of the title, and the "Market data only" fragment earns its place as a routing guard.
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 and both parameters fully documented, the remaining burden is scope and semantics — both covered (13 cities, settlement rule, market-data-only). An agent has everything needed to decide and call 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%, so both parameters (day, city) are already fully documented with examples and defaults. The description repeats the same city examples without adding syntax, format, or fallback behavior beyond what the schema provides, so baseline 3 is correct.
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 clear resource (Kalshi daily-high temperature markets across 13 cities) and enumerates exactly what each row contains: YES price, settlement station/source, strict-comparison rule, close time, and NWS forecast high. No sibling tool touches weather markets, so the agent can identify this as the weather-market board 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 'Kalshi NYC high temperature odds'" gives a direct trigger, and "Market data only" implicitly routes EV/edge/arbitrage needs to siblings like calculate_ev or find_arbitrage. It stops short of naming an alternative explicitly, so it lands just below 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.
base_rate_gap2 fields changedInput schema / properties / marketPrice / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / marketPrice / typeAdded value: +[
+ "number",
+ "string"
+]bayes_update6 fields changedInput schema / properties / evidence / items / properties / likelihoodIfFalse / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / evidence / items / properties / likelihoodIfFalse / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / evidence / items / properties / likelihoodIfTrue / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / evidence / items / properties / likelihoodIfTrue / typeAdded value: +[
+ "number",
+ "string"
+]Input schema / properties / prior / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "string"
- }
-]Input schema / properties / prior / typeAdded value: +[
+ "number",
+ "string"
+]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"
+]edge_alerts2 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"
+]bayes_update1 field changedInput schema / properties / evidence / descriptionPrevious value: -"One or more evidence items, applied in order. Each item needs likelihoodIfTrue and likelihoodIfFalse on the 0–100 scale, e.g. [{ \"likelihoodIfTrue\": 80, \"likelihoodIfFalse\": 20 }]. A single item may be sent as one object."New value: +"One or more evidence items, applied in order. Each item needs likelihoodIfTrue and likelihoodIfFalse on the 0–100 scale, e.g. [{ \"likelihoodIfTrue\": 80, \"likelihoodIfFalse\": 20 }]."base_rate_gap4 fields changedInput schema / properties / baseRateId / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "enum": [
+ "incumbent_reelected",
+ "fed_hold_unemp_below_4",
+ "fed_cut_cpi_above_3",
+ "recession_called_12mo",
+ "sp500_positive_year",
+ "bitcoin_above_100k_eoy",
+ "gdp_growth_above_2",
+ "cpi_above_3",
+ "senate_incumbent_wins_primary",
+ "vix_below_20_eoy",
+ "interest_rate_cut_next_meeting",
+ "major_sports_upset"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / baseRateId / descriptionPrevious value: -"Known base-rate id to look up (includes sample size + source)."New value: +"Known base-rate id to look up (includes sample size + source). One of: incumbent_reelected · fed_hold_unemp_below_4 · fed_cut_cpi_above_3 · recession_called_12mo · sp500_positive_year · bitcoin_above_100k_eoy · gdp_growth_above_2 · cpi_above_3 · senate_incumbent_wins_primary · vix_below_20_eoy · interest_rate_cut_next_meeting · major_sports_upset."Input schema / properties / baseRateId / enumRemoved value: -[
- "incumbent_reelected",
- "fed_hold_unemp_below_4",
- "fed_cut_cpi_above_3",
- "recession_called_12mo",
- "sp500_positive_year",
- "bitcoin_above_100k_eoy",
- "gdp_growth_above_2",
- "cpi_above_3",
- "senate_incumbent_wins_primary",
- "vix_below_20_eoy",
- "interest_rate_cut_next_meeting",
- "major_sports_upset"
-]Input schema / properties / baseRateId / typeRemoved value: -"string"edge_alerts4 fields changedInput schema / properties / min_tier / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "enum": [
+ "SPECULATIVE",
+ "MODERATE",
+ "STRONG"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / min_tier / descriptionPrevious value: -"Minimum confidence tier (returns that tier and above)."New value: +"Minimum confidence tier (returns that tier and above). One of: SPECULATIVE · MODERATE · STRONG."Input schema / properties / min_tier / enumRemoved value: -[
- "SPECULATIVE",
- "MODERATE",
- "STRONG"
-]Input schema / properties / min_tier / typeRemoved value: -"string"kelly_size5 fields changedInput schema / properties / fraction / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "enum": [
+ "full",
+ "half",
+ "quarter",
+ "eighth"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / fraction / defaultRemoved value: -"half"Input schema / properties / fraction / descriptionPrevious value: -"Kelly fraction to apply. Half-Kelly is the common sharp-money default."New value: +"Kelly fraction to apply. Half-Kelly is the common sharp-money default. One of: full · half · quarter · eighth."Input schema / properties / fraction / enumRemoved value: -[
- "full",
- "half",
- "quarter",
- "eighth"
-]Input schema / properties / fraction / typeRemoved value: -"string"weather_boardcalculate_ev3 fields changedInput schema / properties / marketPrice / descriptionPrevious value: -"Current contract price in cents (1–99), equal to the implied probability in %. Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."New value: +"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%."Input schema / properties / yourProbability / descriptionPrevious value: -"Your own estimate of the true 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%."New value: +"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%."Input schema / requiredRemoved value: -[
- "marketPrice",
- "yourProbability"
-]edge_alerts6 fields changedInput schema / properties / limit / anyOfAdded value: +[
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / limit / defaultRemoved value: -25Input schema / properties / limit / descriptionPrevious value: -"Max alerts to return (default 25)."New value: +"Max alerts to return (default 25). Values above 100 are clamped to 100."Input schema / properties / limit / maximumRemoved value: -100Input schema / properties / limit / minimumRemoved value: -1Input schema / properties / limit / typeRemoved value: -"integer"calculate_ev1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "data_freshness": {},
+ "edge_pct": {
+ "description": "Expected-value edge, %."
+ },
+ "edge_pp": {
+ "description": "Your probability minus the price, pp."
+ },
+ "example_call": {},
+ "interpretation": {
+ "description": "Plain-English read."
+ },
+ "market_price_cents": {
+ "description": "Price used, cents."
+ },
+ "needs_input": {},
+ "signal": {
+ "description": "BUY / SELL / SKIP."
+ },
+ "sources": {},
+ "tell_user": {
+ "description": "Show this sentence to the user first.",
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ },
+ "your_probability_pct": {
+ "description": "Probability used, %."
+ }
+ },
+ "type": "object"
+}convert_probability1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "american_odds": {
+ "description": "American odds, no commas."
+ },
+ "data_freshness": {},
+ "decimal_odds": {
+ "description": "Decimal odds."
+ },
+ "example_call": {},
+ "needs_input": {},
+ "probability_pct": {
+ "description": "Implied probability, %."
+ },
+ "sources": {},
+ "tell_user": {
+ "description": "Show this sentence to the user first.",
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}kelly_size1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "applied_fraction_pct": {
+ "description": "The fraction applied, %."
+ },
+ "data_freshness": {},
+ "example_call": {},
+ "full_kelly_pct": {
+ "description": "Full-Kelly fraction of bankroll, %."
+ },
+ "needs_input": {},
+ "rating": {
+ "description": "Qualitative read of the sizing."
+ },
+ "sources": {},
+ "stake_dollars": {
+ "description": "Suggested stake in dollars (when a bankroll was given)."
+ },
+ "tell_user": {
+ "description": "Show this sentence to the user first.",
+ "type": "string"
+ },
+ "timestamp": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}base_rate_gap2 fields changedInput schema / properties / marketPrice / descriptionPrevious value: -"Current market price in cents / implied probability % (0–100). Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."New value: +"Current market price in cents / implied probability % (0–100). Needed for a real answer. Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."Input schema / requiredRemoved value: -[
- "marketPrice"
-]bayes_update2 fields changedInput schema / properties / prior / descriptionPrevious value: -"Prior probability the hypothesis is true, in % (0–100). Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."New value: +"Prior probability the hypothesis is true, in % (0–100). Needed for a real answer. Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."Input schema / requiredRemoved value: -[
- "prior"
-]convert_probability2 fields changedInput schema / properties / value / descriptionPrevious value: -"The numeric value to convert. 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. Accepts a number or a numeric string (\"+150\", \"62%\", \"2.5\")."Input schema / requiredRemoved value: -[
- "value",
- "format"
-]bayes_update2 fields changedInput schema / properties / evidence / descriptionPrevious value: -"One or more evidence items, applied in order."New value: +"One or more evidence items, applied in order. Each item needs likelihoodIfTrue and likelihoodIfFalse on the 0–100 scale, e.g. [{ \"likelihoodIfTrue\": 80, \"likelihoodIfFalse\": 20 }]. A single item may be sent as one object."Input schema / requiredPrevious value: -[
- "prior",
- "evidence"
-]New value: +[
+ "prior"
+]base_rate_gapbayes_updatecalculate_evconvert_probabilityedge_alertskelly_sizeLive Kalshi and Polymarket data: EV edges, cross-venue arbitrage, markets, and whale trades.
Kalshi macro: Fed rate odds, gold, silver, oil and bitcoin edges, 15-min markets, Kelly sizing.
Matched Kalshi and Polymarket markets across sports, crypto, weather, and economics over MCP.
Free, no key: NFL prop board, Kalshi vs Polymarket gaps, 15-min crypto, Fed odds, NHL, EV/Kelly.
Add one secure layer between your agents and this server.
