VARRD — Statistically Validated Trading Edges + AI Research Engine

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

Discloses key behaviors: each call tests one hypothesis, returns complete result (edge or no edge, stats, trade setup), costs ~$0.25 per idea, and can be called again for another idea. No contradiction with 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?

The description is information-dense but well-structured with clear sections (purpose, best for, output, alternative). Every sentence adds value, though it could be slightly more concise.

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 6 parameters, output schema, and annotations, the description provides sufficient context: explains the tool's innovative approach, cost, and when to use alternatives. Lacks edge-case guidance but overall complete for agent 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?

Although schema coverage is 100%, the description adds meaningful context: explains how 'topic' acts as a seed idea, that 'context' uses prior queries as inspiration, and that 'search_mode' controls creative freedom. This goes beyond the schema 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 clearly states the tool's purpose: 'let it discover edges for you' by autonomously exploring a topic. It distinguishes from the sibling tool 'varrd_ai', which is for testing a specific idea with full control.

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 says 'BEST FOR: Exploring a space broadly' and provides a direct alternative: 'Use varrd_ai instead when YOU have a specific idea.' This gives clear guidance on when to use and when not.

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?

Discloses that calls are free (no credits consumed), that card returns a Stripe Checkout link requiring user action, and that crypto is fully autonomous. It also explains the two-step crypto process. This adds value beyond annotations, which only indicate mutability and non-destructiveness.

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?

Well-structured with bullet points for payment methods, each paragraph serves a distinct purpose. The description is comprehensive yet concise, front-loading the core action and default, then detailing the two flows efficiently without 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 the tool's complexity (multi-step payment, two methods), the description covers all necessary steps, links to the sibling check_balance for card confirmation, and explains the crypto autonomous flow. An output schema exists, so return values need not be detailed here. The description is complete for effective 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?

The description adds significant meaning to the schema parameters by explaining the payment flow: for card, the tool returns a checkout link; for crypto, it returns a deposit address and payment_intent_id, then the tool is called again with that ID. This clarifies the lifecycle of each parameter beyond the schema's brief 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 clearly states the tool buys credits for the edge library and AI research, distinguishes between two payment methods, and sets expectations with a default minimum. It effectively differentiates from sibling tools by focusing solely on purchasing 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?

Explicitly guides when to use each payment method: card for user-interactive payment (Stripe Checkout) and crypto for autonomous machine-to-machine flow. It advises calling check_balance after card payment, and provides step-by-step instructions for crypto, including prerequisites and follow-up actions.

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, idempotentHint, and destructiveHint. The description adds context: it's free, no credits consumed, auto-detects completed payments, and response includes recovered_cents. This goes beyond annotations 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?

Three sentences, all valuable. First sentence states main purpose, second emphasizes it's free, third adds secondary use case. No wasted words.

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 parameters and an existing output schema, the description covers the main function and a specific use case (payment confirmation). It is complete for a simple check 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?

No parameters exist, so schema coverage is 100%. The description adds meaning about the response (recovered_cents) but parameter semantics are not applicable; baseline for 0 params is 4.

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 checks credit balance and available credit packs, with the verb 'check' and resource 'credit balance'. It distinguishes from siblings by noting it's free and no credits consumed, setting it apart from buy_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?

Explicitly states when to use: 'call this after your user pays via a checkout link to confirm credits were added'. Implies it's safe to call anytime due to being free, but no explicit when-not-to-use or alternatives are provided.

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?

Description adds substantial detail beyond annotations: it explains the process (profiles, searches, writes digest), output format (with ↳ lines), requirement for strong edges, and credit cost. No contradiction with annotations (readOnlyHint, openWorldHint).

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 sentences with clear front-loading: first sentence states main action, second adds process detail, third provides example, fourth lists requirements. No fluff.

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 output schema (assumed to exist), the description covers purpose, process, output format, prerequisites, and cost. It is self-contained and informative.

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?

Although there are no parameters (100% schema coverage), the description explains that it uses the user's validated edge library, providing context on what the tool acts upon.

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 'get a personalized market news briefing' with specific actions: profiles strategies, searches news, writes digest. It distinguishes itself from sibling tools like search and varrd_ai by focusing on personalized briefing based on 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?

It explicitly states prerequisites ('at least 5 strong edges in your library') and cost ('Costs credits'), but does not explicitly explain when to use this vs. alternatives or 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.

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

The description aligns with annotations (readOnlyHint, idempotentHint) and adds behavioral detail about returned data (performance metrics, version history, trade levels), fully disclosing what the tool does beyond safety properties.

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 clear front-loading. The second sentence is somewhat general ('Everything an agent needs...') but not overly verbose. Minor improvement possible.

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 low parameter count, full schema coverage, presence of output schema, and comprehensive annotations, the description fully covers what the agent needs to know about this simple retrieval 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 coverage is 100%, and the description adds the context that hypothesis_id comes from 'search or scan results,' which is helpful for correct invocation. However, no additional parameter-specific details are given.

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 explicitly states 'Get full detail for a specific hypothesis/strategy' and enumerates specific content (formula, entry/exit rules, performance metrics, etc.), making the purpose very clear and distinguishing it from siblings like 'search'.

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 implies the tool is used after discovery via search/scan ('from search or scan results'), providing clear usage context. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling list.

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 idempotentHint=true and destructiveHint=true. The description adds value by stating 'free — no credits consumed' and implying session termination. No contradiction with 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 with clear progression: action (kill session), usage (when to use), and follow-up (call research). No redundant words.

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 tool's simplicity, the description covers purpose, usage, and post-action steps. Output schema exists, so return values are pre-documented. Complete for decision-making.

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 covers the single parameter session_id with description 'The session_id to reset.' The description does not add meaning 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?

The description clearly states the tool kills a broken research session and starts fresh. It specifies the verb 'reset' and the resource 'session'. It distinguishes usage from other tools by defining its purpose.

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: when a session gets stuck, produces errors, or enters a bad state. It also includes a post-reset recommendation to call research without session_id. Absence of when-not or alternative tools is minor given clear context.

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 readOnlyHint and idempotentHint. The description adds that results are ranked by relevance and include key stats (win rate, Sharpe, edge status), providing valuable behavioral context beyond 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?

The description is two sentences, front-loaded with the purpose, and every sentence adds value. No wasted words.

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 tool has an output schema (not shown), the description sufficiently explains what the tool returns. All parameters are covered, and the context is complete for an AI agent to use the tool 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 coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema parameter descriptions. It mentions 'keyword or natural language query' which matches the schema, and 'optional market filter' also matches.

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 'search' and the resource 'saved hypotheses/strategies'. It specifies it returns ranked results with key stats, distinguishing it from siblings that are not search 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 says 'Use this to find strategies you've already validated', providing clear context for when to use. It does not explicitly state when not to use or mention alternatives, but no conflicting siblings exist.

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?

The description discloses behavioral traits beyond annotations: cost per turn ($0.25), session creation, multi-turn conversation flow, statistical testing process, edge verdict definitions, and terminal states. Annotations only indicate openWorldHint=true, while the description adds critical context like cost and hypothesis constraints.

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 long but well-structured with headings, bullet points, and clear sections. It front-loads the purpose and cost. While slightly verbose, every section adds unique value. Could be condensed slightly but still effective.

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 tool's complexity (multi-turn, hypothesis integrity, edge verdicts), the description covers all necessary context. It explains session lifecycle, allowed/forbidden actions, edge outcome interpretation, and references context fields like next_actions and has_edge. The output schema likely defines return values, so description focuses on usage.

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%, baseline 3. The description adds significant context: message can be specific commands like 'test it' or 'show me the trade setup', and session_id usage for multi-turn. This elevates beyond the basic schema 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 explicitly states the tool's purpose: 'Talk to VARRD AI... Describe any trading idea in plain language'. The verb 'talk/describe' combined with 'VARRD AI' clearly identifies the action and resource. It distinguishes itself from siblings like autonomous_varrd_ai (likely autonomous version) and varrd_edges (edge results).

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 extensive usage guidelines including multi-turn process, hypothesis integrity rules, allowed/not allowed actions, key capabilities, and terminal states. Explicitly states when to use (testing ideas) and when not (e.g., combining setups). This is comprehensive and leaves no ambiguity.

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 significant context beyond annotations: pricing tiers, safety, statistical methodology (Bonferroni-corrected, K-tracking), and that depth=0 is free. No contradiction with 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?

Well-structured with headings and bullet points, front-loaded with key message. Slightly verbose but every sentence adds value. Could be trimmed slightly.

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?

Thorough coverage for a complex tool with 8 parameters, no output schema, and pricing. Explains tiers, costs, filtering, statistical rigor, and drill-down sections.

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%, but the description adds crucial meaning to the depth parameter (tiers and costs) and other parameters, far exceeding basic schema 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 clearly states it's a live feed of statistically validated trading edges, calls it 'THE PRIMARY TOOL — start here', and distinguishes from siblings like varrd_ai by its specific function.

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 says 'start here' and 'FREE at depth=0, always safe to call', outlines three tiers with costs, and explains when to use each depth. Lacks explicit when-not-to-use or alternative tools, but coverage is strong.

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