Veroq

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

While annotations establish readOnlyHint and openWorldHint, the description adds substantial behavioral context: credit costs (1-5 credits), caching durations (60s/30s), fallback behavior (web search for non-financial queries), auto-discovery constraints (1,061+ tickers), and detailed return structure (composite trade signals, confidence levels, follow-up suggestions). It does not mention rate limits or error handling patterns.

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 uses clear section headers (WHEN TO USE, RETURNS, COST, EXAMPLES, CONSTRAINTS) that front-load critical decision-making information. Despite substantial length, every sentence delivers unique value (cost structure, timing constraints, fallback behavior). The 'most important tool' claim at the start is slightly subjective but immediately establishes priority.

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 high complexity (NLP routing, 41 intents) and absence of an output schema, the description comprehensively compensates by detailing return values (structured data + LLM summary + composite signals + confidence levels), cost model, caching behavior, and coverage constraints. It could be improved by mentioning error handling or rate limit specifics.

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 3. The description adds quantitative performance semantics for 'fast' parameter ('~500ms vs ~3s', 'save ~2 seconds') and rich contextual examples for 'question' parameter ('NVDA full analysis', 'oversold tech stocks') that clarify expected input patterns beyond the schema's basic type definitions.

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 a natural language interface that routes to 41 specific intents (price, technicals, earnings, etc.), using active verbs ('ask', 'get', 'routes'). It explicitly distinguishes itself from the 40+ specialized sibling tools by stating 'Use this FIRST before reaching for specialized tools,' establishing its role as the default entry point.

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 'WHEN TO USE' guidance stating it is the 'DEFAULT tool for any financial, market, or economic question' and mandates using it 'FIRST before reaching for specialized tools.' This creates a clear hierarchy versus siblings like veroq_candles or veroq_screener, leaving no ambiguity about selection order.

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