Weather Markets Edge Desk

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

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds real value on top: it discloses the tool is free with no key and describes what the result contains (gap in pp, signal, sample-size quality). It stops short of noting limitations or how the signal is derived.

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?

Front-loads the usage cue, then the action, then the parameters, then the free/no-key note. Every sentence carries information; the only slight cost is the somewhat chatty opening quoted phrasings.

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 naming the return contents, and it covers cost/auth ('Free, no key') and the two input paths. An agent has enough to call it correctly, though it doesn't explain the signal's scale or the sample-size quality grades.

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, but the description adds the either/or relationship the schema does not state explicitly: use a known baseRateId (listed in the enum) OR supply your own baseRateValue. That mutual-exclusivity guidance is genuinely additive.

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 names the concrete outputs (gap in pp, a signal, sample-size quality). This distinguishes it clearly from siblings like bayes_update or calculate_ev, 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 trigger phrasings ('how does this price compare to history', 'is the market ignoring the base rate') that tell the agent when to reach for this tool. It does not name alternatives or state when NOT to use it, 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.

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's main added value is behavioral: it discloses the return payload (posterior probability plus the per-step chain) and that evidence is applied in order, which matters for multi-item chaining. It omits edge-case behavior such as prior at 0/100 or zero likelihoods, which would be the remaining useful disclosure.

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 core operation before inputs and use cases; nothing is padded. The trailing quoted trigger list is slightly list-like and overlaps the usage-guideline role, but it stays short and earns its place as intent matching.

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 compensates by naming the return value (posterior and per-step chain), and the schema fully documents inputs. The gap is behavioral edge cases (degenerate priors/likelihoods, failure modes) for a numeric computation tool where a division-by-zero or 0/100 prior is plausible.

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 parameters are thoroughly documented there, including accepted input formats ('55%', '$0.55', American odds) and the 0–100 scale. The description only restates this at a high level, adding no syntax or constraint detail beyond the schema, 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?

States a specific verb+resource (update a prior probability with evidence via Bayes theorem) and enumerates both the inputs (prior, evidence with P(evidence|true)/P(evidence|false)) and the outputs (posterior plus per-step chain). This cleanly distinguishes it from siblings like convert_probability and calculate_ev, which do not perform evidence chaining.

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?

Supplies concrete trigger phrasing ('update my estimate with new information', 'posterior probability', 'how does this news change the odds') that maps user intent to this tool. However, it never names an alternative or a when-not-to-use condition — e.g., pointing to convert_probability for pure odds conversion or base_rate_gap for base-rate reasoning — so routing among siblings is still partly inferred.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description usefully adds cost/auth context ("Free, no key") plus the decision shape (BUY/SELL/SKIP). It does not go beyond that into rate limits, staleness, or interpretation caveats, so it is adequate rather than 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 core is front-loaded and tight, but the closing track-record promotion ("Every PMP engine signal is graded in public: predictionmarketspicks.com/track-record") is marketing that does not help an agent select or invoke the tool, diluting an otherwise two-sentence definition.

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 covering the return values, annotations covering safety, and full parameter documentation in the schema, the description supplies everything else an agent needs: when to reach for it and what decision it yields. Only the sibling-routing and edge-case guidance are absent.

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 parameters document accepted input formats (cents, percent, dollars, American odds) in detail. The description only restates 'price in cents' and 'your own probability', adding no format or edge-case semantics beyond the schema, so the 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 states a specific verb (calculate expected-value edge) and resource (contract price vs. your probability), and anchors it with concrete user questions ("is this contract mispriced", "what is my edge"). It only implicitly distinguishes itself from siblings like kelly_size or edge_alerts rather than naming them, so it falls short of a 5.

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 a clear trigger context (you have a market price and your own probability estimate) and states the decision output expected. No explicit when-not or named alternatives, so not a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds behavior beyond that: it discloses that all three representations are returned and specifies the American-odds formatting convention (no commas, e.g. +441 or -200), which an agent would otherwise get wrong.

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 conversion scope, then the input/output contract, then concrete usage examples. No filler or repetition.

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 return values, and it correctly focuses on the input contract and format conventions. Parameters, enum options, and usage triggers are all covered, so nothing needed to call this tool 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%, and the schema already supplies the enum values and the same example inputs ("+150", "62%", "2.5") used in the description. The description restates the format/example contract rather than adding new semantics, 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?

States a specific verb (Convert) and resource (implied probability, American odds, decimal odds) with the exact transformation direction. An agent can immediately distinguish this from siblings like calculate_ev, bayes_update, or kelly_size, which perform analysis rather than unit conversion.

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 trigger phrases ("what is +150 as a probability", "convert 62% to American odds", "decimal to implied odds") and the input contract ("Give one value and its format"). It stops short of naming when NOT to use it or which sibling to prefer for derived calculations, so it is clear context without exclusions.

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

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

Annotations only cover read-only and open-world, but the description adds consequential behavior: real-time data requires Pro while free access is delayed 24h and withholds the thesis, the feed is identical and impersonal for every subscriber, and filters only select rows rather than personalize them. It also discloses the informational/not-advice framing. This is exactly the kind of context 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?

Front-loaded with the use case, then the payload, then the access/latency caveats — a sensible order with no filler sentences. The quoted marketing-style trigger phrases and the final disclaimer slightly dilute density, so not 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?

With no output schema, the description carries the return-shape burden and does so by listing feed, tier, side, price, model probability, edge and link, plus the free-vs-Pro delay. Combined with full schema coverage on inputs, an agent has enough to call and interpret it; only pagination/cursor behavior around limit and since goes unstated.

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 four parameters (feed, limit, since, min_tier) are already fully documented with enum values and defaults; baseline is 3. The description's 'filters only select' adds a useful semantic hint (filtering narrows, never alters content) but does not add syntax or format detail 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?

The description states a specific resource (model-generated Kalshi alerts across weather/crypto/metals/oil/mispricing) and enumerates the payload fields, which clearly separates it from the calculator siblings (calculate_ev, kelly_size, bayes_update). The trigger phrases ('any edge on Kalshi', 'weather trade signals') are quoted rather than described, so the statement of purpose is a bit scattered but still unambiguous.

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 conditions ('Use for "any edge on Kalshi" and "weather trade signals"'), so an agent knows the query shape that should route here rather than to the deterministic calculators. It never names a sibling or states when not to use it, which keeps it 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.

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 still adds value by disclosing the return shape (dollar stake plus a risk rating) and the conditional behavior that omitting bankroll yields a percentage rather than a dollar figure. It does not discuss edge cases like negative-edge contracts.

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, all load-bearing: purpose, input/output contract, and usage triggers. The most important scoping information is front-loaded and there is 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 a 100%-covered schema, an output schema, and annotations covering the read-only profile, the description supplies everything an agent needs: what it computes, what it accepts, what it returns, and when to invoke it. No meaningful gap remains.

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 including accepted formats (percent, cents, dollar, American odds) is already documented. The description restates the parameter list and hints that market price 'sets the payout', but adds little syntax or interpretation 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?

The description opens with a precise verb+resource: 'Compute the optimal Kelly position size for a prediction-market contract.' It enumerates the inputs (win probability, market price, bankroll, Kelly fraction) and the outputs (dollar stake, risk rating), making it trivially distinguishable from siblings like calculate_ev or bayes_update.

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 user-intent triggers ('how much should I stake', 'what is my position size', 'Kelly sizing for this trade'), which clearly defines when to reach for it. It stops short of naming alternatives or stating when NOT to use it (e.g. for EV calculation use calculate_ev).

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