Foresea Forecasting

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: fetches live price, gathers evidence, forecasts, computes edge, and returns a recommendation. It mentions the output structure with sample fields. While it doesn't discuss rate limits or authentication, the non-destructive analysis nature and the listed steps provide sufficient transparency for an agent.

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 a single paragraph but well-structured: starts with when to call, lists triggers, describes the process, gives an example, and mentions alternative tool. It is informative without being overly verbose. Minor redundancy (e.g., 'good triggers' listing is slightly repetitive) but overall efficient.

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?

The tool has 13 parameters (none required) and an output schema exists externally. The description covers core purpose, usage guidance, and output structure, but leaves many parameters undocumented. Given the complexity, the description is adequate for basic use but not fully comprehensive; an agent would need the output schema to understand return values, and param details are lacking.

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 0%, but the description only explains a few parameters (platform, slug, ticker) in the example. Many parameters (skills, variant, tool_loop, builtin_skills, evidence_top_k, etc.) remain unexplained. The description does not add semantic meaning for the majority of the 13 parameters, leaving the agent to guess or rely on parameter names 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 clearly states the tool's purpose: analyze a specific prediction market by fetching live price, gathering evidence, forecasting, computing edge, and returning a recommendation. It specifies triggers like URL, slug, or ticker, and distinguishes from sibling tool foresea_forecast (used for general probability questions without a live market). The verb 'analyze market' is specific and 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?

The description provides explicit when-to-use guidance: when user mentions a specific prediction market by URL, slug, or ticker, or asks about over/underpricing. It lists good triggers and gives an example. It also specifies when not to use (use foresea_forecast instead for general questions). This clear differentiation aids correct agent selection.

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?

No annotations are provided, so the description fully bears the transparency burden. It discloses that the tool returns open markets ranked by model-vs-market disagreement, including direction, odds, significance, and multi-model comparison. While it omits data freshness or update frequency, the behavioral detail is adequate for a read-only tool with no parameters.

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 concise, using three front-loaded sentences. It starts with the core purpose and trigger examples, then succinctly lists output contents. Every sentence adds value without verbosity.

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 tool with no parameters and an output schema, the description provides complete context: it explains what the tool does, when to call it, and what the output contains (ranked markets, directions, odds, significance, comparison). No additional information is needed for an agent to use 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?

With zero parameters and 100% schema description coverage, the baseline score is 4. The description does not need to add parameter meaning since there are none, and it appropriately focuses on the output instead.

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 clearly states the tool returns top trading opportunities with explicit trade directions and historical backing. It provides specific trigger phrases like 'What are the best bets right now?' and 'Show me the edge board', making its purpose distinct from sibling tools such as foresea_analyze_market or foresea_forecast.

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 includes clear contexts for use with good trigger examples, but does not explicitly advise when not to use this tool or mention alternatives among siblings. However, the provided triggers offer sufficient guidance for appropriate invocation.

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?

With no annotations, the description fully covers behavior: it returns calibrated probabilities/rationale/evidence, handles multiple question types, and explains market edge analysis via parameters. No contradictions or omissions.

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 purpose and triggers, includes a helpful example, but the single paragraph is somewhat lengthy and could be more structured. Every sentence adds value, but brevity could be improved.

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 13 parameters and an output schema, the description covers core functionality well but fails to explain many parameters. Output schema provides return structure, so completeness is adequate but not exhaustive.

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 0%, and the description only explains three parameters (question, market_probability, market_url) despite 13 total. Other important parameters like options, categories, description, and resolution_criteria are not mentioned, leaving agents underinformed.

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 clearly states the tool is for probability/likelihood questions, provides explicit example triggers, and distinguishes itself from siblings by mentioning optional market analysis. The verb 'Call this whenever' and resource 'forecast' are specific and 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?

Gives explicit triggers ('Will X happen?', etc.) and explains when to pass market data for edge analysis. However, it lacks explicit when-not-to-use guidance or alternative tool references, which would improve decision-making.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns markets ranked by model-vs-market disagreement with model probability, market price, and edge. It does not mention any destructive effects or rate limits, but for a read-only scan tool this is sufficient. It could mention edge interpretation, but overall transparent.

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 and front-loaded with purpose and triggers. It includes an example and is structured efficiently, with every sentence adding value.

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?

The description covers the high-level function and output structure, and distinguishes from a sibling tool. However, it lacks detailed parameter explanations and does not fully compensate for the missing annotations and low schema coverage. The output format is hinted via example but not formally defined.

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 0% and the description only explains 'platform' and 'min_edge' via an example. Parameters like 'query', 'limit', and 'evidence_top_k' are not described at all, leaving the agent without guidance on their meaning or usage.

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 clearly states the tool's purpose: to find mispriced or interesting markets, not evaluate a specific one. It lists trigger phrases and distinguishes from foresea_analyze_market. The verb 'scan' and the resource 'markets' are specific.

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 when to use (trigger phrases like 'What should I bet on?') and when not to use (for a specific market, use foresea_analyze_market). This gives clear selection 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?

No annotations are provided, so the description carries the full burden. It discloses the return values (accuracy, Brier score, calibration, skill-vs-market) and mentions breakdown by time horizon. For a read-only tool with no side effects, this provides adequate transparency without contradiction.

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 extremely concise, consisting of two front-loaded sentences. Every word adds value: the first sentence defines when to call, the second lists return values. No wasted text.

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 zero parameters and an existing output schema (implied), the description provides sufficient context about the tool's behavior and return values. It mentions the key metrics and the time horizon breakdown, making it complete for an agent to decide and use.

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?

There are zero parameters, so the baseline score is 4 per the guidelines. The description does not add parameter semantics because none are needed; schema coverage is 100%.

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 clearly specifies the tool's purpose: returning reliability and accuracy metrics for Foresea. It lists specific triggers and states exactly what metrics are returned (accuracy, Brier score, calibration, skill-vs-market), distinguishing it from sibling tools that handle other tasks like forecasting or market analysis.

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 (when user asks about reliability or accuracy) and provides good trigger phrases. While it doesn't explicitly exclude other scenarios, the context is clear enough that an agent can infer when not to use it, especially given the distinct sibling tool names.

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