Crypto Markets Desk

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new context beyond them: "Free, no key" (no authentication required) and the returned decision read (BUY/SELL/SKIP). The closing track-record sentence is promotional rather than behavioral, and no rate-limit or failure behavior is described.

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 front-load the trigger phrase and the input/output contract with no wasted words. The final marketing sentence about the public track record does not earn its place in a tool 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?

An output schema exists, so return values need no elaboration, and the two fully documented parameters plus annotations cover most of the surface. The one nuance it raises but does not resolve is that both parameters are technically optional while being "Required for a real answer" — it never says what degraded result appears if either is 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 both parameters already document the accepted formats (55, "55%", "$0.55", 0.55, American odds), so the baseline is 3. The description only restates that inputs are a price in cents and your own probability, adding no format or constraint 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 names a concrete operation (compute the % expected-value edge from a contract price and your probability) and states the output shape (edge plus BUY/SELL/SKIP). Naming Kalshi/Polymarket pricing implicitly separates it from commodity_edge and the perps tools, but it never explicitly differentiates from the closely related kelly_size or convert_probability siblings.

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 a clear triggering intent and a concrete input recipe (price in cents + your probability). It does not name alternatives or state when NOT to use it — e.g. that kelly_size is the follow-up for sizing a bet — so routing between siblings 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.

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

Annotations already establish readOnly/destructive=false and openWorld, so those add nothing here. The description goes beyond them by disclosing the Pro auth requirement (sign in with PredictionMarketsPicks or a Pro API key) and the not_covered fallback ('never a fabricated edge'), which are meaningful behavioral facts.

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 trigger phrasings and commodity list are front-loaded, and the auth caveat is placed last. It is slightly verbose in enumerating the ticket fields, but each clause carries useful 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 no output schema, the description carries the return-value burden and does so by listing the ticket fields (side, entry price, resolve criterion, probability, edge, tier, Kelly size). Auth and watchlist behavior are covered; only deeper edge/model detail is left out, which is acceptable.

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 both parameters are already fully documented in the schema, including the watchlist semantics and not_covered behavior. The description's restatement that commodity is 'needed for a real answer' adds little beyond what the schema provides, 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 resource (the Kalshi gold/silver/WTI/bitcoin strike with the largest PMP model edge) and enumerates the returned ticket fields, so an agent knows what it retrieves. It does not, however, name or differentiate from siblings like calculate_ev or kelly_size, leaving that to inference.

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 supplies trigger phrasing ('gold edge today', 'oil or bitcoin trade signal') and notes tickers[] for a watchlist, giving implied usage context. But it offers no when-not guidance and never names an alternative sibling tool, so routing is left implicit.

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, destructiveHint=false, and openWorldHint=false, so the safety and side-effect profile is fully covered and the barrage for extra behavioral detail is low. The description adds the return shape ('get all three back') and the no-comma formatting convention for American odds, but says nothing about invalid inputs or rounding behavior.

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: purpose first, then the I/O contract with the formatting caveat, then example phrasings. Front-loaded and free of filler, though the example queries partially duplicate what the schema already illustrates.

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 return values need not be spelled out, and annotations cover the safety profile; the description supplies the conversion set and input convention. It is essentially complete for a pure-function tool, with only edge-case behavior (invalid percentages, odds of 0) unaddressed.

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 both parameters are already documented in the schema, including accepted string forms ('+150', '62%', '2.5') and the enumerated format values. The description only restates 'give one value and its format' and adds the no-comma note, so baseline 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 verb and resource ('Convert between implied probability, American odds, and decimal odds') and defines the exact I/O contract: one value plus its format in, all three representations out. This is clearly distinguishable from siblings like calculate_ev and kelly_size, which consume odds rather than translate 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?

Gives concrete usage triggers via example phrasings ('what is +150 as a probability', 'convert 62% to American odds'), which tell the agent exactly which requests route here. It does not name exclusions or sibling alternatives (e.g. when to prefer calculate_ev or kelly_size), so it stops short of full routing guidance.

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 cover the safety profile (readOnly, openWorld, non-destructive). The description adds auth and cost context ('Free, no key') plus the shape of what comes back (window status, YES price, close time, target, settlement basis, 96-window up rate), which is genuinely beyond the annotations. It does not mention rate limits or clamping behavior (that lives in the 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 triggering questions before the content inventory. Dense but every clause carries information; the only slight redundancy is the field list, which the output schema already conveys.

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 annotations covering safety, a 100%-covered input schema, and an output schema, the description only needs to establish scope, trigger conditions and the free/no-key access model — all present. Nothing an agent needs to select or call this 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 the parameters (limit, series, open_only, asset_class) are already fully documented, including the 40-row clamp and enum values. The description only restates that series accepts an asset or ticker and that asset_class exists, adding no syntax or semantics 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+resource: every Kalshi 15-minute up-or-down series across crypto, metals, energy and FX, with the concrete fields returned. The scope ('15-minute') and the sibling boards (perps_board, market_pulse) are clearly separable, so an agent can pick this tool without opening the schema.

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 use-case phrasings ('what is the ETH 15-minute market doing', 'which Kalshi 15-minute markets are open'), which maps directly to the series/open_only parameters. No explicit when-not or named alternative among siblings, 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 this is a non-destructive, closed-world read (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds that the result includes a dollar stake and a risk rating, but its other behavioral details (omitting bankroll yields a % instead of dollars) duplicate the schema, and an output schema already exists to describe returns.

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 core action and the inputs, then closes with example user phrasings. Two tight sentences with no filler, though the quoted trigger list is somewhat verbose given the surrounding clarity.

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 full input schema, an output schema, and annotations covering the safety profile, the description needs only to state the computation and its inputs, which it does. Nothing an agent needs to call the tool 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 every parameter is already fully documented, including accepted formats and the half-Kelly default. The description restates the four inputs generically and adds no 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 gives a specific verb and resource ('Compute the optimal Kelly position size for a prediction-market contract') and names the exact inputs that drive it. It clearly separates this calculation from siblings like calculate_ev or bayes_update, which perform different math.

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 supplies concrete trigger phrasing ('how much should I stake', 'what is my position size', 'Kelly sizing for this trade'), giving the agent clear context for when to select it. However, it never states when NOT to use it or names an alternative tool for adjacent sizing/EV questions.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it is an estimate, the Kalshi app shows the exact value, it includes fees and expected funding, and it is free — disclosing accuracy limits and cost.

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 triggering use case, then result description, caveat, and coverage list — a logical flow. It is slightly padded by the asset enumeration that is already in the schema, but overall tight and well-structured.

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 estimator with 100% schema coverage and no output schema, the description tells the agent what is computed (liquidation price, % move, fees, funding), how accurate it is, and its cost — everything needed to invoke and interpret 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 description coverage is 100%, so the schema already documents all six parameters including defaults and formats. The description only restates the asset list, which duplicates the enum, and adds no param syntax beyond the schema. Baseline 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 verb (estimates) and resource (Kalshi perp liquidation price), and quantifies the output (% move to liquidation, fees, funding). The example query 'where does a 5x bitcoin long liquidate on Kalshi' makes the purpose unambiguous and distinguishes it from the perps_board sibling.

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' preface gives a concrete triggering question, which is clear usage context. However, it does not name an alternative tool (e.g. perps_board) or state when-not to use it, so it falls short of explicit routing.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuine extras: it is free, requires no API key, and discloses that funding history is measured "since launch" for a long — a non-obvious data-scope trait. It stops short of saying anything about freshness, pagination, or failure modes for an unknown asset symbol.

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 use case, then the return payload, then the filter. Every sentence carries content; only "Free, no key" is tersely telegraphic rather than a full clause, and it slightly overlaps with the title's field list.

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 two-param, no-required-argument read tool with an output schema, this covers what the agent needs: what the board contains, how to narrow to one perp, that no auth is required, and that the read is safe. Return-shape detail is legitimately delegated to the output 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 both parameters (asset, limit) are already documented in the schema, including the 30-row clamp and default 25. The description's only param-level addition is repeating the asset examples ("btc", "gold"), which the schema already provides. 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 specific resource (every Kalshi perpetual future) and enumerates exactly which fields the board returns — price, 24h volume, open interest, long/short max leverage, funding cadence, and cumulative funding cost since launch. The quoted query examples ("Kalshi perps funding rate", "how much leverage on Kalshi gold perps") make it immediately distinguishable from siblings like perp_liquidation or calculate_ev.

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 phrasing ("Use for ...") and states the single-asset mode ("Pass asset ... for one"), but it never names an alternative or an exclusion — nothing tells the agent when to prefer perp_liquidation, market_pulse, or commodity_edge instead. Clear context, no routing rules.

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