VARRD — AI Trading Research & Backtesting

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

Annotations indicate mutation (readOnlyHint=false) and external interaction (openWorldHint=true). The description adds valuable behavioral context: it explains the full pipeline (hypothesis generation → data loading → statistical testing), clarifies scope ('Each call tests ONE hypothesis'), and documents the return structure ('edge/no edge, stats, trade setup').

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?

Structured with clear visual sections (BEST FOR, Returns, explicit sibling comparison). Every sentence serves a distinct purpose: functionality explanation, use case guidance, output specification, or alternative routing. Slightly verbose but information-dense with zero redundancy.

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 6-parameter tool with no output schema, the description adequately compensates by detailing the return value structure and explaining domain-specific concepts (VARRD engine, event study vs backtest). Missing only minor details like error handling or credit consumption (relevant given 'buy_credits' sibling exists).

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%, establishing baseline 3. The description adds semantic value by illustrating parameter interactions with concrete examples ('momentum on grains' for topic, 'focused' vs 'explore' modes explained via 'tangential idea generation' vs 'seed idea'). This contextual mapping exceeds the schema's mechanical descriptions.

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 action statement ('Launch VARRD's autonomous research engine to discover and test a trading edge'). It distinguishes clearly from sibling 'research' via the explicit directive 'Use 'research' instead when YOU have a specific idea...', successfully differentiating autonomous exploration from controlled manual testing.

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?

Contains explicit 'BEST FOR' section stating when to use ('Exploring a space broadly'). Provides concrete usage pattern examples ('give it 'momentum on grains' and it might test wheat...'). Explicitly names sibling alternative and the condition for choosing it ('when YOU have a specific idea to test').

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?

Adds crucial context beyond annotations: identifies Stripe as processor, Base as network, USDC as currency, and notes 'Free — no credits consumed to call this'. Explains the two-phase commit pattern (deposit address generation vs confirmation) which annotations (readOnlyHint=false, openWorldHint=true) only hint at.

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?

Highly efficient structure: one sentence for purpose, numbered list for modes, final sentence for cost structure. Every clause provides actionable information with zero redundancy.

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, adequately explains return values implicitly ('get a Stripe deposit address', 'receive credits') and documents the external dependency chain (Stripe → Base). Minor gap: could explicitly document error states or timeout behavior for the pending transaction.

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?

While schema coverage is 100%, the description adds cross-parameter workflow semantics by framing usage as 'Two modes'—explaining the temporal relationship between amount_cents (applies to both) and payment_intent_id (absence=pending, presence=confirmation). This interaction logic isn't captured in isolated schema field descriptions.

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?

Description states specific verb (buy) + resource (credits) + payment method (USDC on Base). Clearly distinguishes from siblings like check_balance or research tools by focusing on payment acquisition.

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 documents the two-step workflow: 'Call without payment_intent_id' vs 'call again with the payment_intent_id'. Provides clear temporal sequencing for when to use each parameter state.

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 indicate read-only, non-destructive, idempotent behavior. The description adds valuable domain-specific context that no credits are consumed and describes what data is returned (balance and available packs), enhancing understanding beyond the structured annotations.

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 efficiently structured: purpose declaration, cost disclosure, and usage timing. Every clause earns its place with no redundancy or 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?

For a zero-parameter read operation, the description adequately explains what data is returned despite the lack of an output schema. It covers purpose, cost behavior, and usage timing, though it could specify the exact structure of returned balance information.

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?

Tool accepts zero parameters, meeting the baseline expectation for this dimension. No additional parameter documentation is required or present.

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?

Description clearly states the tool checks credit balance and shows available packs using specific verbs. It effectively distinguishes from siblings like buy_credits (checking vs. purchasing) and research/scan (viewing vs. consuming credits).

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 clear temporal guidance ('Call this before heavy operations') and cost context ('Free — no credits consumed'). While it implies prerequisites for expensive operations, it does not explicitly name alternatives or negative conditions.

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?

Beyond the annotations (readOnly, openWorld, non-idempotent), the description adds critical behavioral context: the credit cost, the minimum edge prerequisite, and the specific output format with ↳ lines connecting news to positions. It also clarifies the temporal nature by mentioning 'today's news', aligning with idempotentHint=false.

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 efficiently structured in three distinct paragraphs: core functionality, output format example, and constraints. Every sentence provides unique value without redundancy, and the content is front-loaded with the primary action.

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?

Despite the absence of an output schema, the description adequately describes the return value format (concise digest with ↳ lines linking to edges). Combined with the prerequisite and cost disclosures, it provides sufficient context for invocation, though explicit return type structure would improve it further.

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?

The input schema contains zero parameters. According to scoring rules, zero-parameter tools receive a baseline score of 4, as there are no parameters requiring semantic clarification 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 uses specific verbs ('profiles', 'searches', 'writes') and clearly identifies the resource as a 'personalized market news briefing based on your validated edge library'. It distinguishes itself from generic research siblings by emphasizing personalization tied to the user's specific trading positions and edge library.

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 clear prerequisites ('Requires at least 5 strong edges in your library') and cost implications ('Costs credits'), which act as usage constraints. However, it does not explicitly name alternative tools (like 'research' or 'search') for when the user lacks sufficient edges.

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 output schema provided, the description adds significant value by exhaustively listing return contents (formula, entry/exit rules, performance metrics, version history). This disclosure of data richness helps the agent anticipate the result structure. The annotations already establish safety (readOnly/idempotent), which the description does not contradict.

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 efficiently structured: purpose declaration, detailed return specification, and value proposition. The final sentence ('Everything an agent needs...') is slightly repetitive but justifies the comprehensiveness of the previous sentence. No significant waste.

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 the absence of an output schema, the description compensates well by enumerating specific return fields (Sharpe, profit factor, drawdown, etc.). With only one simple parameter and clear annotations, the description fulfills its burden, though it could mention error cases (e.g., invalid ID) for completeness.

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% (the hypothesis_id parameter is fully documented in the schema). The description mentions 'specific hypothesis/strategy' which aligns with the parameter purpose, but does not add syntax, format constraints, or semantic details beyond what the schema already provides. 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?

The description clearly states the verb (Get) and resource (hypothesis/strategy) and specifies scope as 'full detail' which distinguishes it from presumed summary/list siblings like 'search' or 'get_briefed'. However, it does not explicitly name sibling tools or explicitly contrast with 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?

The description provides clear context for when to use the tool: when the agent needs to 'understand and act on a strategy' and requires comprehensive data (formula, metrics, rules). The parameter schema further contextualizes this by noting the ID comes 'from search or scan results', implying a workflow. It lacks explicit 'when not to use' 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?

Beyond annotations (readOnlyHint:false, idempotentHint:false), the description richly discloses behavioral traits: stateful session management (session_id lifecycle), statistical methodology constraints (one hypothesis at a time), expected context fields (edge_verdict, has_edge, next_actions), and interpretation of edge verdict categories (STRONG EDGE, MARGINAL, PINNED, NO EDGE).

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?

While lengthy, the description is well-structured with clear headers (MULTI-TURN, HYPOTHESIS INTEGRITY, KEY CAPABILITIES) and front-loaded purpose. Every section is essential given the complexity of the stateful workflow and lack of output schema. Minor verbosity in the examples section prevents a perfect 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?

Given the absence of an output schema, the description comprehensively compensates by explaining exactly what to expect in context variables (edge_verdict types, next_actions, has_edge boolean) and detailing the complete lifecycle from session creation through terminal states.

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 100% schema coverage, the baseline is met. The description adds valuable semantics beyond the schema: it clarifies the session_id lifecycle (omit on first call, reuse thereafter) and provides concrete message examples ('test it', 'show trade setup', 'start new hypothesis') that illustrate the conversational protocol implied by the multi-turn design.

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 defines the tool as an interface to 'VARRD AI — a quant research system' with specific capabilities like ELROND council, backtesting, and pattern charting. It effectively distinguishes from the sibling 'autonomous_research' by emphasizing the interactive, multi-turn conversational nature ('Talk to', 'Your idea ->') and session-based workflow.

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?

Excellent explicit guidance on when and how to use the tool: it details the multi-turn sequence (1. idea -> 2. test -> 3. trade setup), strictly defines hypothesis integrity constraints (ALLOWED vs NOT ALLOWED testing patterns), instructs to use 'start a new hypothesis' between ideas, and specifies terminal states (stop when context.has_edge is true/false).

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 establish the destructive/idempotent profile, while the description adds complementary behavioral context: cost transparency ('Free — no credits consumed'), specificity about error states handled, and integration workflow with sibling tools. Does not contradict annotations.

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?

Four efficient sentences cover purpose, trigger conditions, cost policy, and next-step workflow without redundancy. Information is front-loaded with the destructive action declaration.

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 single-parameter destructive operation with rich annotations, the description is complete. It addresses purpose, prerequisites (broken state), side effects (free of charge), and subsequent workflow integration.

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 100% schema coverage, the input schema fully documents the session_id parameter. The description validates this by mentioning the parameter indirectly via the post-reset workflow instruction, but does not need to add syntax details 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 opens with the specific action 'Kill a broken research session and start fresh' - a concrete verb-resource combination that clearly distinguishes this cleanup/recovery tool from research-creation siblings like 'research' and 'autonomous_research'.

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 explicit trigger conditions ('when a session gets stuck, produces errors, or enters a bad state') and clear post-action workflow ('After resetting, call research without a session_id'), effectively guiding the agent through the full recovery lifecycle.

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?

Since annotations declare readOnly/idempotent/safe behavior, the description adds valuable output context: 'exact dollar entry, stop-loss, and take-profit prices' and methodology ('validated statistical model'). This compensates for the missing output schema by clearly stating what data structure users receive.

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 tightly structured sentences cover purpose, output specification, and differentiation. Every sentence earns its place with zero redundancy. Information is front-loaded with the core action in the first sentence.

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 comprehensively describes returned data (exact dollar levels for entry/stop/profit). Combined with complete parameter documentation and annotations covering side effects, the description provides sufficient context for 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 coverage is 100% with both 'market' and 'only_firing' fully documented. The description does not add parameter syntax or format details beyond the schema, 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?

Excellent specific verb ('Scan') plus clear resource ('saved strategies') and scope ('firing right now'). Distinguishes from research-focused siblings (research, autonomous_research, get_hypothesis) by emphasizing exact trade execution levels rather than directional analysis or hypotheses.

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 phrase 'Not a vague directional call' implicitly guides users to choose this over research tools when exact entry/exit prices are needed. However, it does not explicitly name sibling alternatives or state when to prefer research vs scanning.

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 safety (readOnly, idempotent, non-destructive). Description adds valuable behavioral context by specifying return format: 'ranked by relevance, with key stats (win rate, Sharpe, edge status),' compensating for the lack of 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?

Three distinct sentences with zero waste: purpose (sentence 1), return behavior (sentence 2), usage context (sentence 3). Well-structured and front-loaded.

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 the simple 3-parameter schema with full coverage and strong annotations, the description adequately covers tool behavior. It describes return values despite no output schema, though it omits error handling or empty result behaviors.

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%, establishing baseline 3. Description reinforces the 'query' parameter's purpose ('keyword or natural language') but does not add significant semantic detail beyond the schema for 'limit' or 'market' parameters.

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?

Description uses specific verb 'Search' with clear resource 'saved hypotheses' and distinguishes scope by specifying 'keyword or natural language query' and 'already validated,' differentiating it from sibling tools like 'research' or 'get_hypothesis'.

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?

Clear context provided by 'Use this to find strategies you've already validated,' implying when to use (retrieving saved work) versus creating new hypotheses. However, it does not explicitly name alternative tools for other scenarios.

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