Kalshi weather markets: live daily-high temperature edges, plus EV, Kelly and base-rate tools.
Scored across 6 tools
Each tool targets a distinct step in the prediction-market analysis workflow: base-rate comparison, Bayesian updating, EV calculation, odds conversion, alert feeds, and position sizing. No two tools have overlapping purposes, so an agent can select confidently.
All names use snake_case and combine a clear verb or noun (base_rate_gap, bayes_update, calculate_ev, convert_probability, edge_alerts, kelly_size). There is minor variation in verb placement (some noun-first, some verb-first), but the pattern remains predictable and readable.
With 6 tools, the surface is tightly scoped for its domain. Each tool covers a necessary analytical or decision-support function without redundancy or bloat, fitting comfortably in the ideal 3-15 range.
The set covers the full pipeline from raw market price analysis (base rate, EV, odds conversion) through evidence integration (Bayes) to actionable outputs (alerts, Kelly sizing). No obvious dead ends; an agent can chain these tools end-to-end for a well-informed trade decision.
Compare a market price against the historical base rate for a class of events and get the gap in percentage points plus a signal and sample-size quality. Pass either a known base-rate id (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) or your own baseRateValue. Use for "how does this price compare to history", "is the market ignoring the base rate", "historical frequency vs market".
| Name | Required | Description | Default |
|---|---|---|---|
| baseRateId | No | Known base-rate id to look up (includes sample size + source). | |
| marketPrice | Yes | 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%. | |
| 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 and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying the return components: gap, signal, and sample-size quality. It does not detail edge cases like what happens if both baseRateId and baseRateValue are supplied, but that is a minor 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?
The first sentence is front-loaded with the core action and output. The enum list is somewhat redundant with the schema but still useful for discoverability, and the use-case sentence earns its place. Overall it is organized and not padded.
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 no output schema, the description compensates by naming the result fields (gap, signal, sample-size quality). Inputs are well covered by the schema, and the description clarifies the either/or relationship between baseRateId and baseRateValue. Minor ambiguity remains about conflict or omission behavior, but the tool is simple enough that the description is essentially 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 repeats the enum list and the baseRateValue alternative but does not add new semantic meaning beyond the schema. No extra parameter guidance is provided, so it does not rise above baseline.
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-resource pair ('Compare a market price against the historical base rate') and enumerates the outputs (gap in percentage points, signal, sample-size quality). It clearly differentiates this tool from siblings like calculate_ev or convert_probability by focusing on historical base-rate comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use-case phrasing ('how does this price compare to history', 'is the market ignoring the base rate', 'historical frequency vs market') and explains the two input paths (baseRateId or baseRateValue). It does not name alternatives or exclusion conditions, but the context is clear enough for an agent to select it appropriately.
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 | Yes | 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%. | |
| evidence | Yes | One or more evidence items, applied in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explaining that it returns the posterior probability and a per-step chain, and that it can process multiple evidence items. The word 'update' refers to a mathematical calculation rather than a persistent state change, so there is no contradiction with the readOnly annotation.
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 cover the main operation, input/output mechanics, and usage triggers without redundancy. The description is front-loaded with the core Bayesian update purpose and each subsequent sentence adds a distinct, useful layer.
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 stateless calculator with a readOnlyHint and fully documented schema, the description gives enough to invoke correctly: what to pass, how evidence is modeled, and what comes back. It could detail the structure of the per-step chain, but that is secondary to calling the tool successfully.
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 input schema already fully documents prior formats, evidence structure, and likelihood semantics. The description repeats the evidence model at a high level but adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('update a prior probability') with a precise mathematical method (Bayes theorem) and clearly describes the input/output relationship. The 'Use for' phrases ('posterior probability', 'how does this news change the odds') make it easy to distinguish from the conversion and EV tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides user-intent triggers such as 'update my estimate with new information' and 'posterior probability', which helps an agent decide when to select this tool. It does not name specific sibling alternatives or state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the expected-value edge on a Kalshi or Polymarket prediction-market contract. Given the current market price (in cents, i.e. the implied probability) and your own probability estimate, returns the % edge and a BUY / SELL / SKIP signal with a plain-English read. Use for "is this contract mispriced", "what is my edge", "should I take this position". From the PredictionMarketsPicks desk, which publishes a settled per-engine record — every signal graded against the market that priced it, wins and losses both: predictionmarketspicks.com/track-record.
| Name | Required | Description | Default |
|---|---|---|---|
| marketPrice | Yes | 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%. | |
| yourProbability | Yes | 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%. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe, non-mutating calculation. The description adds useful output behavior—'% edge and a BUY / SELL / SKIP signal with a plain-English read'—but does not disclose internal assumptions or edge thresholds. This is adequate but 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?
The description is three sentences: function and outputs, use cases, and provenance/track-record context. It is front-loaded and every sentence earns its place, though the final track-record sentence is slightly promotional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only calculator, the definition is complete enough: it names the domain, inputs, outputs, and intended use cases. There is no output schema, but the description gives a reasonable picture of the return value. A bit more detail about how the BUY/SELL/SKIP thresholds are derived would be helpful but not necessary for correct invocation.
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 both marketPrice and yourProbability already have detailed descriptions including accepted formats (percentages, decimals, American odds). The description adds no parameter semantics beyond what the schema already provides, so 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?
The description opens with a specific verb and resource: 'Calculate the expected-value edge on a Kalshi or Polymarket prediction-market contract.' It names the inputs and the exact outputs (% edge and BUY/SELL/SKIP signal), making the function unambiguous and clearly distinct from siblings like convert_probability 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 description explicitly states when to use the tool: 'Use for "is this contract mispriced", "what is my edge", "should I take this position".' This gives clear context, though it does not name sibling tools or specify when not to use it.
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 | Yes | The numeric value to convert. Accepts a number or a numeric string ("+150", "62%", "2.5"). | |
| format | Yes | Format of `value`: probability (0–100 %), american (e.g. -200 / +150), or decimal (e.g. 2.5). One of: probability · american · decimal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint=true, so no side-effect warning is needed. The description adds useful behavioral context beyond annotations: it returns all three representations at once and specifies that American odds carry no commas (e.g., +441 or -200). This helps the agent set expectations about output formatting.
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 compact: one purpose sentence, one outcome sentence, and a short list of use-case examples. Every sentence earns its place, the main behavior is front-loaded, and there is no redundant restating of the tool name or 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?
For a simple two-parameter conversion tool with full schema coverage and a read-only annotation, the description is largely complete. It states inputs, output behavior, and formatting conventions. The only minor gap is that it does not specify the exact response structure or key names, but 'get all three back' is sufficient for most agent workflows.
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 value beyond the schema with concrete examples like '+150', '62%', and '2.5', and clarifies the American odds formatting constraint. This helps an agent understand accepted value forms without relying on enum hints alone.
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 opens with a specific verb and resource: 'Convert between implied probability, American odds, and decimal odds.' It also states the exact outcome—'get all three back'—and gives concrete user-phrase examples that remove ambiguity. No sibling tool overlaps with this conversion purpose, so it is clearly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage contexts: 'Use for "what is +150 as a probability"', 'convert 62% to American odds', and 'decimal to implied odds.' These examples tell an agent when to invoke the tool. It does not explicitly state when not to use it or name alternatives, but the sibling list contains no competing conversion tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the edge alerts our models generate on Kalshi — weather, bitcoin/silver/gold/oil, and mispricings — as a live feed. Each alert carries feed, tier (SPECULATIVE/MODERATE/STRONG), side, price in cents, model probability, edge in percentage points, and a Kalshi market link. A Pro key returns the feed in real time; without a key you get the same feed delayed 24 hours with the thesis stripped. Every subscriber receives the identical, impersonal feed at the same time — the signals are not tailored to any individual. Filters (feed, min_tier, since) SELECT which alerts you see; they never change the signal content. Use for "any edge on Kalshi", "weather trade signals", "latest mispricings". Impersonal market analysis for informational purposes only, not investment advice. Trade responsibly.
| 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). | |
| since | No | ISO-8601 timestamp — only alerts created after it. | |
| min_tier | No | Minimum confidence tier (returns that tier and above). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses significant behavioral traits: the Pro vs. delayed 24-hour feed, thesis stripping without a key, the identical impersonal nature of the feed, and that filters only affect selection, never signal content. It even adds a disclaimer that it is not investment advice.
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 information-dense and front-loaded with the main purpose, followed by return fields, access behavior, filter semantics, and use cases. It is slightly long and includes boilerplate like 'Trade responsibly,' but each substantive sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the fields each alert carries: feed, tier, side, price in cents, model probability, edge in percentage points, and a Kalshi market link. It also covers access tiers, delay, and filter semantics. Minor gaps remain around exact probability units and the sports_arb/nfl feeds mentioned only in the schema.
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 all four parameters. The description adds value by explaining that filters (feed, min_tier, since) only select which alerts are shown and never alter the underlying signal content, and it names several feed categories in the first sentence.
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 opens with a specific verb and resource: 'Read the edge alerts our models generate on Kalshi' and enumerates the covered feeds (weather, commodities, mispricings). It also clarifies that this is a live feed of pre-generated signals, which distinguishes it from calculation-oriented sibling tools like calculate_ev 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?
The description gives explicit use-case phrases: 'Use for "any edge on Kalshi", "weather trade signals", "latest mispricings".' It also explains the filter behavior and access-key implications. However, it does not explicitly state when to prefer a sibling tool or when not to use this feed, so it falls short of full alternative routing.
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. | half |
| 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%. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, so the safe, non-mutating nature is already covered. The description adds that the result is a dollar stake and a risk rating, but it does not disclose edge cases such as what happens when winProbability is below or equal to the market price, nor what the risk rating values actually mean. This leaves some behavioral ambiguity.
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 two sentences with no filler. It front-loads the core computation, then lists inputs and outputs, and ends with concrete query examples. Every sentence earns its place and the structure makes the tool easy to scan.
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 calculation tool with no output schema, the description does state the outputs ('dollar stake and a risk rating') and all inputs. However, it leaves the 'risk rating' undefined and does not explain behavior when no Kelly bet is warranted, which an agent would benefit from knowing before invoking the 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%, and the schema already documents each parameter, including accepted formats, defaults, and optionality. The description restates the key parameters but does not add significant new semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compute the optimal Kelly position size for a prediction-market contract.' It clearly lists the inputs (win probability, market price, bankroll, Kelly fraction) and outputs (dollar stake and risk rating), making the tool's function unmistakable even among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides user-intent triggers: 'Use for "how much should I stake", "what is my position size", "Kelly sizing for this trade".' This gives clear context on when to invoke the tool. However, it does not mention when not to use it or name any alternative tool, so it falls just short of full exclusion guidance.
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_gapbayes_updatecalculate_evconvert_probabilityedge_alertskelly_sizeLive Kalshi and Polymarket data: EV edges, cross-venue arbitrage, markets, and whale trades.
Matched Kalshi and Polymarket markets across sports, crypto, weather, and economics over MCP.
Prediction-market intelligence for conservative cross-market pricing edges and live signals.
Kalshi MCP — US-regulated prediction-market data (no auth on public reads).
Add one secure layer between your agents and this server.
