VARRD — Statistically Validated Trading Edges + AI Research Engine

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

The description adds useful behavioral details beyond annotations: it returns a complete result (edge or no edge, stats, trade setup), each call tests one hypothesis, requires credits, and uses a knowledge graph. Annotations state openWorldHint=true, which aligns. Slight deduction because it doesn't describe failure modes or rate limits.

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 well-structured with a concise opening, a 'BEST FOR' section, and sibling guidance. It is slightly verbose but still clear and front-loaded with key 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?

Given no output schema, the description adequately explains what is returned (edge or no edge, stats, trade setup) and that each call tests one hypothesis. It could mention output format or limits, but overall it is fairly complete for a complex 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?

Input schema has 100% description coverage, so the description does not need to add much. The description does not explain parameters beyond what the schema provides. Baseline score of 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's purpose: to let the AI autonomously explore a topic and discover trading edges using a knowledge graph. It distinguishes itself from sibling tool 'varrd_ai' by specifying that this tool is for broad exploration while the other is for specific testing 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?

The description explicitly tells when to use this tool ('BEST FOR: Exploring a space broadly') and when to use the alternative ('Use 'varrd_ai' instead when YOU have a specific idea to test and want full control over each step.'). This provides clear guidance for tool 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?

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?

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?

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.

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

Annotations are limited, but the description richly discloses behavioral traits: session management, credit requirement, hypothesis testing constraints, edge verdicts, and terminal states. No contradictions 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 quite long and detailed, which is necessary for a complex conversational tool, but it could be better structured (e.g., bullet points). It is front-loaded with the main purpose but then becomes dense. Adequate but not 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?

Covers all necessary aspects for a complex multi-turn tool: workflow, hypothesis rules, edge verdicts, terminal states, and key capabilities. No output schema, but the description explains what to expect in context (edge verdicts, next_actions). Complete for the complexity level.

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?

Input schema covers both parameters with 100% description coverage. The description adds little beyond the schema: message is elaborated with examples from the schema, and session_id is similarly described. Baseline score of 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's purpose: 'Talk to VARRD AI' and explains it handles trading ideas end-to-end. It is a specific verb+resource description. However, it does not explicitly distinguish from the sibling 'autonomous_varrd_ai', leaving some ambiguity about when to use which.

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 step-by-step multi-turn workflow, hypothesis integrity rules (allowed vs. not allowed), and specific instructions for handling ELROND council outputs. Clearly states when to start new hypotheses and terminal states.

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 provides extensive context beyond annotations: it explains the statistical methodology (Bonferroni correction, K-tracking, out-of-sample validation) and the idempotent, read-only nature. Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description aligns perfectly 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 well-structured with clear sections ('THREE TIERS:'), bolded levels, and bullet points. Every sentence adds value—covering tiers, pricing, filtering, and methodology. It is succinct yet comprehensive, with 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?

Despite having no output schema, the description adequately explains what each depth returns (markets/status at depth 0, direction/stats at depth 1, full methodology at depth 2). It also covers filtering and statistical rigor. Minor gap: does not explicitly state the output is a list of edges, but this is implied. Overall, it 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 input schema already covers all parameters with descriptions (100% coverage), meeting the baseline. The description adds some context about the tiers but does not significantly enhance parameter meaning beyond what the schema provides. Thus, a score of 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's purpose: 'Browse VARRD's library of statistically validated trading edges'. It uses a specific verb ('Browse') and resource ('library of edges'), and distinguishes itself from siblings like 'autonomous_varrd_ai' (AI assistant) and 'buy_credits' (purchasing tool).

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 explains the three pricing tiers and what each depth returns, implying when to use each. It also mentions filtering options (market, status, edge_id). However, it does not explicitly state when not to use this tool versus alternatives like 'varrd_ai', leaving some ambiguity for an AI agent.

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