tengu-firm

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

No annotations are present, so the description carries the burden. It implies a read-only statistics operation by using 'statistics', but does not explicitly disclose safety, return format, or any behavioral caveats. For a simple zero-parameter tool this is adequate but not rich.

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?

Two concise sentences front-load the core purpose and then give a clear usage trigger. No wasted words or redundant details.

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, simple stats tool, the description covers what and when. It does not describe the output format, and there is no output schema, but the intent is clear enough for an agent to select and invoke 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?

The tool has zero parameters, so the baseline is 4. The empty schema and description need not explain parameters; the description adds no parameter semantics, but that's expected here.

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 'Cache hit-rate statistics for the data layer', a specific verb+resource. It does not explicitly contrast with sibling health/status tools, but the focus on cache performance makes it distinct.

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: 'Call when the user asks whether the system/data pipeline is healthy or why data looks stale or slow.' It doesn't name alternative tools or exclusions, but the guidance is clear and actionable.

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 provided, the description carries the full burden of behavioral disclosure, and it excels. It details that the tool re-fetches the verdict shape, computes a delta, returns an enumerated thesis_status, includes a narrative, and returns 404 on expiry (90-day TTL) or missing records. This is unusually thorough and leaves very little hidden behavior.

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?

Every sentence in the description contributes meaningful information: purpose, input source, behavior, output enum, narrative, error case, TTL, and a concrete example use case. It is front-loaded with the core action and remains focused without any filler or redundant restatement.

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 only one parameter and no output schema, the description fully covers the needed context: how to obtain the input, what the output looks like (thesis_status and narrative), and failure modes (404 for expiry or missing record). The inclusion of the 90-day TTL and the example callback shape makes this complete for an agent to invoke and interpret results.

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 documents the only parameter, decision_id, at 100% coverage. The description adds valuable provenance by telling the agent to pass the decision_id returned by decision_track, which goes beyond the schema's generic 'Path parameter (required)' note. This extra context helps the agent correctly source the value.

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 'REVIEW A TRACKED DECISION,' a specific verb+resource combination that clearly distinguishes this tool from sibling tools like tengu_copilot_score_ticker or tengu_copilot_ticker_full. It further clarifies the purpose by explaining it computes a structured DELTA against the original snapshot and returns thesis_status, leaving no ambiguity about what the tool does.

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 gives an explicit prerequisite: 'Pass the decision_id returned by decision_track,' and a concrete use case: the 'your AAPL position you opened Tuesday is up X% — thesis is tracking' callback shape. It does not explicitly list alternatives or when-not-to-use scenarios, but the context is clear enough for an agent to choose this tool appropriately.

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 provided, the description fully carries the transparency burden. It discloses return contents (ic_ratio per horizon, drift status, plain-English narrative), provides actionable thresholds (ic_ratio < 0 = sign flip and halt new positions, < 0.3 = severe/retrain, > 1.0 = outperforming), and mentions performance ('Sub-second'). This gives the agent a clear behavioral model.

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 front-loaded with the core concept and 'CALL THIS' guidance, then gives return fields and thresholds. Each sentence adds distinct value—definition, use cases, return structure, frequency, and interpretive thresholds—without redundant fluff. It is dense but 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?

For a zero-parameter status tool with no output schema, the description is exceptionally complete. It explains the metric, what is returned, how to interpret the values, and the refresh cadence. The agent can confidently invoke this tool and interpret results without additional context.

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 tool has 0 parameters, so the baseline is 4. The empty schema fully documents that there are no inputs. The description adds no parameter-specific detail because none is needed; it focuses on the output and interpretation, which aligns with the 0-param baseline.

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 function: 'Live IC drift status — comparison of realised live IC vs training-time IC.' It identifies the resource (IC drift) and the specific comparison, and positions it as 'the canonical alpha-decay early warning,' distinguishing it from related tools like voter_ic_drift. The use-case phrases ('is the model still working?') further pin down its intent.

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 gives explicit trigger phrases: 'CALL THIS when the user asks...' and lists three concrete user intents. It also notes refresh cadence ('refreshed daily after the close'), which helps the agent decide if the data is fresh enough. However, it does not explicitly mention when not to use it or point to alternative tools (e.g., voter_ic_drift), so it lacks exclusion 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 adds useful context about what the tool returns (current regime and edge interpretation) but does not disclose how the regime is determined, data freshness, or any limitations. For a zero-parameter informational tool, this is adequate but not rich; it could mention that it's a snapshot or read-only operation.

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 core purpose, followed by explicit usage triggers. Every word earns its place, and it is neither verbose nor under-specified. Structure is exemplary for a simple query tool.

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 zero parameters, no output schema, and no annotations, the description covers the main aspects: what it does and when to invoke it. It does not explain the meaning of 'macro regime' or the output format, but for a zero-param tool with clear usage triggers, it is reasonably complete. The plain-English interpretation is highlighted, which addresses the user-facing value.

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 tool has zero parameters, and the schema coverage is 100% (empty schema). The baseline for zero parameters is 4, and the description correctly avoids mentioning parameters since none exist. There is no need to compensate for undocumented 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?

The description clearly states the tool provides 'Current macro regime + plain-English interpretation of how strong the model's edge is in this regime,' which specifies both the resource (macro regime) and the output type (interpretation). It distinguishes from likely sibling tools like tengu_macro or tengu_regime by emphasizing the plain-English interpretation of model edge, though it does not explicitly name alternatives. The purpose is specific and actionable.

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 gives explicit invocation triggers: 'CALL THIS when the user asks about market conditions, regime, "is it a good time to invest", or how confident the model is right now.' This provides clear context for when to use the tool. It does not mention when not to use it or name specific alternative tools, but the triggers are strong enough to guide 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?

With no annotations, the description carries the behavioral disclosure burden. It transparency discloses that passing asset_class=crypto results in a 404, that certain tickers carry a ticker_collision block, and explicitly warns against misrepresenting equity scores as crypto views. This exceeds typical transparency, though it does not explicitly state it is a read-only operation or describe error behavior for invalid tickers.

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 front-loaded with the most important information (purpose and trigger) and each subsequent sentence adds essential detail: output components, usage instructions, namespace, collision handling, and crypto caveat. No sentence is wasted, and the structure is logical.

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 moderate complexity (2 parameters), absence of annotations, and absence of an output schema, the description is exceptionally complete. It covers the full set of return fields, output usage, namespace scope, edge-case ticker collisions, and the crypto 404 behavior. The agent is well-equipped to select and invoke this 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 description coverage is only 50% and the ticker description is generic ("Path parameter"). The description adds substantial meaning: it gives concrete stock examples, lists the nine tickers that cause a collision block, and explains the asset_class parameter's behavior (default equity, crypto triggers a 404). This goes far beyond the structured 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 clearly states the tool's purpose with a specific verb ("Full per-ticker quant analysis") and provides an explicit trigger condition ("CALL THIS when the user asks about any specific stock"). It distinguishes itself from likely sibling tools by describing its comprehensive output (blended_score, decile, conformal interval, etc.) and its role as the go-to for individual stock queries.

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 gives explicit when-to-use guidance (stock-specific questions with examples) and when-not-to-use guidance (crypto assets 404, never present equity score as crypto view). It also instructs on how to use the output (narrative for summary, structured fields for follow-ups). While alternatives are not named, the strong trigger and warnings provide sufficient direction.

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 exist, so the description must carry full weight. It explains the closed-vocabulary statuses, the tradeable boolean, and the crucial nuance that 'unknown' is a real verdict with same instruction as red. It also discloses the trustworthiness check (not merely recency) by describing the drift-job re-stamping scenario. This is thorough, field-level behavioral detail.

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 dense and front-loaded with the question and call instruction. It is longer than strictly necessary due to the detailed explanation of 'unknown' and the drift-job scenario, but every sentence adds value by clarifying non-obvious contract behavior. Well-structured with clear separation of return fields, failure policy, and trustworthiness philosophy.

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?

With no output schema, the description must fully define what the tool returns and how to interpret it. It enumerates the statuses, the tradeable boolean, decile_convention, and per-horizon IC. It also explains the fail-closed semantics and why 'unknown' is not a placeholder. This is complete enough for an agent to confidently call this tool and correctly handle its response without guessing.

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 tool takes zero parameters, so the schema has nothing to explain. The baseline for zero-parameter tools is 4, and there is no additional parameter semantics needed. The description focuses on output semantics, which is the correct distribution of effort.

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 immediately answers the core question: it's a pre-trade health check for the alpha signal ('is the alpha signal fit to trade'). It explicitly ties itself to actions on /top-picks and /score, and details the return values (status, tradeable boolean, IC). This distinguishes it from sibling health tools like system_health or live_ic_drift.

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?

Direct instruction to 'CALL THIS BEFORE acting on /top-picks or /score' gives a clear trigger condition. It also defines the fail-closed behavior ('treat it as an empty candidate list'), telling the agent how to branch and what to do on non-healthy statuses. This is explicit, practical guidance with actionable when-to-use.

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 full burden. It discloses cache TTL (60s), cache bypass option, parallel execution of up to 12 underlying tools, and that it replaces an HTTP-burst fan-out. This provides useful context beyond what annotations would give, though it does not mention potential return size or data structure.

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, starting with the core purpose and then adding usage context and parameter notes. Each sentence provides useful information, though the 'Replaces Brain's 24-72 HTTP-burst fan-out' detail is somewhat marketing-oriented but still explanatory.

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 complex tool with no output schema, the description covers purpose, usage, caching, and flags. However, it does not explain what a 'verdict' looks like, what the cluster outputs contain, or clarify candidate_weight_pct. These gaps reduce completeness for an agent trying to interpret and use the response.

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 only 20%, so the description must compensate. It explains include_smartmoney and include_transparency flags and the cache bypass behavior for cache_max_age_s. However, candidate_weight_pct is not mentioned anywhere in the description or schema, leaving a gap. The ticker parameter is self-evident but not enriched.

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 this is an OMNIBUS aggregation for one ticker, pulling both the 5-layer transparency and 7-layer smartmoney clusters in a single call. It identifies the tool's primary role as Brain's single-stock verdict path and differentiates it from sibling tools that focus on individual clusters or other functionalities.

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?

Explicit use cases are provided ('should I buy X?', 'what do you think of Y?', 'verdict on Z'). The description explains that it replaces a 24-72 HTTP-burst fan-out and mentions flags to skip clusters for comparison views. However, it does not explicitly state when to use this vs. the individual cluster tools, though sibling names imply a choice.

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 carries the full burden and discloses key behaviors: it aggregates multiple sources, has a `degraded`/`missing_layers` contract (partial data possible), and has a cache TTL of 180s. It doesn't detail auth/rate limits, but for a read-only aggregation this is reasonable. The `missing_layers` contract and cache behavior add meaningful transparency beyond the 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?

Four sentences, dense with information: aggregation purpose, use-case trigger, efficiency benefit, error contract, and cache TTL. The most critical details are front-loaded (title/purpose first), and every sentence earns its place with no 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 moderate complexity (2 params, no output schema), the description explains what data it aggregates, when to use it, what failure states to expect (`degraded`/`missing_layers`), and caching semantics. It doesn't describe the return structure, but the absence of an output schema and the explicit contract reference make this acceptable. A fuller description of the response format would earn a 5.

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 50% (only `ticker` has a description, which is minimal). The description adds context for `cache_max_age_s` by mentioning 'Cache TTL 180s', hinting at cache-control semantics, but does not explicitly explain the parameter's purpose or effect. It partially compensates for the schema gap, but leaves interpretation to the agent.

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 exactly what the tool does: it aggregates smart-money data for one ticker by collapsing 7 specific data sources into a single call. The verb 'aggregates' plus the resource ('smart-money ... for one ticker') and the explicit list of underlying tools clearly distinguish it from individual data-source tools and sibling tools like ticker_full or ticker_transparency.

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 guidance on when to use: 'Use when Brain's verdict needs positioning context' with concrete example questions. It also names the alternatives (the 7 individual tools) and highlights efficiency ('Saves 6 HTTP calls per verdict'), implying when to prefer the composite over individual calls. This covers when/when-not/alternatives well.

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 payload structure ('5-layer payload + `degraded:bool` + `missing_layers:[...]`'), partial failure behavior ('partial failures still produce usable output'), and caching semantics ('Cache TTL 60s. Pass `cache_max_age_s=0` to bypass cache'). This is transparent beyond typical descriptions.

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?

Each sentence carries unique, high-value information: purpose, usage, benefit, return details, degradation handling, and cache control. The list of five collapsed tools is relevant for disambiguation. No filler or 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 and lack of output schema, the description provides a strong high-level contract: what it aggregates, returns, partial failure behavior, and cache semantics. It does not detail the internal structure of each of the five layers, but the names and the overall summary are sufficient for an agent to decide and invoke 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 description coverage is 50% (only `ticker` is described). The description adds valuable semantics for `cache_max_age_s` by explaining the bypass-cache behavior, which the schema does not. `ticker` is self-explanatory and already documented, so the addition is meaningful.

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 states a specific action ('collapses'/'aggregation') with a clear resource ('ML-transparency aggregation for one ticker') and explicitly names the five underlying tools, distinguishing it from sibling tools. The use case ('why is the model saying this?') further clarifies intent.

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 an explicit when-to-use: 'Use when Brain's verdict needs the model-transparency layer' and quantifies the benefit ('Saves 4 HTTP calls per verdict'). It lists the collapsed tools as a form of alternative but does not explicitly say when not to use this aggregate vs. individual tools.

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 each pick includes the same full quant analysis as score_ticker (score, interval, voter breakdown, narrative), which is useful behavioral context. However, it doesn't mention how picks are ranked, ordering, or any failure/edge-case behavior, leaving it at a minimally viable level.

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 three sentences with no fluff. It front-loads the purpose, then usage triggers, then output details. Every sentence adds value, and the structure is easy to parse.

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 complexity (2 optional params, no output schema), the description covers the essential aspects: what it returns, when to use it, and what each pick contains. It doesn't describe edge cases or ranking criteria, but those are not critical for making a selection decision here.

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%, so the description must explain the parameters. It does: 'top N picks' clarifies the n parameter, and 'long or short side' explains the side parameter. The schema already provides defaults and constraints, but the description adds semantic meaning beyond those.

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 today's top N picks with a long or short side, and explicitly provides example user queries that should trigger it. It distinguishes itself from single-ticker analysis by referencing score_ticker, making it clear this is a list-of-ideas 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 gives explicit when-to-use triggers ('CALL THIS when the user asks...') with concrete examples. It doesn't explicitly state when not to use it or name direct alternatives like tengu_ml_top_picks, so it lacks exclusions but provides 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?

With no annotations provided, the description carries the full burden. It discloses the tool's coverage (out-of-sample backtest, strict-OOS, conformal-validation, factor-decomposition) and refresh cadence ('refreshed weekly'), adding valuable context beyond the name. It does not, however, specify the output format or any potential side effects, though for a read-only performance report this is acceptable.

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 and well-structured. It opens with the core concept, then gives actionable trigger phrases in caps, and ends with coverage details and refresh frequency. Every sentence earns its place with no redundancy or 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?

For a zero-parameter tool with no output schema, the description is nearly complete. It covers what the tool does, when to use it, the specific metrics included, and the refresh interval. The only gap is that it does not explicitly describe the return format, but given the nature of a performance summary, this is a minor omission.

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 tool has zero parameters and an empty input schema, so schema coverage is trivially 100%. The description adds no parameter semantics because there are none to describe. Per the rubric, a zero-parameter tool gets a baseline of 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's purpose: 'Out-of-sample model performance — Sharpe, IC, conformal coverage, factor-decomp alpha.' It uses a specific noun phrase that identifies the resource and scope, and includes trigger phrases like 'how do I know this works' that pinpoint when an agent should call it. This differentiates it from sibling tools such as tengu_copilot_live_ic_drift or tengu_copilot_decision_review.

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?

Usage guidance is explicit: 'CALL THIS when the user asks...' followed by concrete example questions. This provides clear context for when to invoke the tool. However, it does not mention alternative tools or when not to use it, so it falls short of a 5.

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 burden. It discloses that limit=0 returns all ~13k names, that results are ranked/sorted, that each item includes both absolute suggested_position_pct and relative normalized_weight, and that normalized_weight sums to ~100% across the returned set. It clearly indicates the output structure and how to interpret weights, which is critical for the user. It does not discuss rate limits or performance degradation for large universes, but the core behavioral contract is well covered.

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 three sentences, dense with useful information, and front-loaded with the core purpose. Every sentence adds value: the first states what it returns, the second gives the two usage modes, the third tells the user which output field to use. No fluff or repetition of the tool name.

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 schema has no parameter descriptions, no annotations, and no output schema, the description is remarkably complete: it covers the two main use cases, the meaning of limit=0, the returned fields (absolute and relative weights), how to interpret normalized_weight, and the relationship between parameters and mode. The tool is more complex than typical list tools because it supports both screening and basket sizing, but the description covers both paths adequately. Minor gaps (e.g., max_weight semantics, sort direction) are acceptable given the constraints.

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 nothing is documented in the schema, so the description must compensate. It explicitly explains limit (0 = all ~13k names, meaning all), tickers (basket path), and implicitly explains min_decile and side via the screening/ranking mode. It also explains the meaning/purpose of normalized_weight as a rebalance target summing to ~100%. It does not explain max_weight, normalize, or min_decile in detail, but the major semantic gaps are filled.

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 a strong verb phrase ('return the ENTIRE scored universe'), specifies the resource (scored universe ~13k names), and distinguishes two distinct modes: with tickers (sizing a basket) vs without (screening/ranking). It also names sibling-like concepts (per-holding rebalance path vs screen/rank) which helps differentiate it from related 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 explicitly states when to use each mode: 'Pass tickers=AAPL,NVDA,… to score+SIZE a specific holdings basket (the per-holding rebalance path); omit it to screen/rank the universe (limit/min_decile/side).' It also explains the meaning of limit=0 (all ~13k names), giving concrete usage context and implicating the relevant parameters.

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 carries the full burden and does so thoroughly. It explains the key conceptual distinction between 'data_silent' (voter source offline, not the voter's fault) and 'real decay' (voter scores no longer predictive), and enumerates all returned fields including the capped ±0.05 weight delta. This prevents misinterpretation and gives the agent a solid mental model of the output.

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 four dense, information-rich sentences with no filler. It front-loads the core purpose, then covers differentiation, call triggers, and return fields. Every sentence earns its place, and the structure flows logically from what to when to what-you-get.

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 and no annotations, the description is complete for a zero-parameter analytical tool. It lists all key return fields, explains the critical data_silent vs real_decay semantics, and references the sibling tool for contrast. There is no significant missing context that would hinder correct invocation or result interpretation.

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 tool has zero parameters, so schema coverage is trivially 100% and the baseline is 4. The description adds context about the 12-voter ensemble and the per-voter granularity, which helps the agent understand what the no-parameter invocation returns, even though no parameter details are needed.

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 function: 'Per-voter IC drift breakdown' with a specific focus on identifying which of the 12 voters is decaying. It explicitly distinguishes itself from the blended-IC drift tool by contrasting 'IF the ensemble is decaying' versus 'WHICH voter', making the purpose unambiguous and well-differentiated from a key sibling.

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 call triggers with real user phrasing ('which voter is the problem?', 'why did the model decay?', 'should we re-weight?') and explicitly names the alternative blended-IC drift tool for the ensemble-level IF question. This gives clear when-to-use and when-not-to-use guidance, going beyond generic 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?

With no annotations provided, the description carries the full burden and excels: it discloses the real-time entitlement requirement, the 439 pair coverage, the honest as_of timestamp behavior, and error handling via a structured 404 for unknown symbols. It also clarifies the 24h change/volume is UTC-day based, providing essential behavioral context beyond any 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?

The description is two sentences, front-loaded with the core purpose ('Live crypto quote'), and every clause adds value: return fields, entitlement, pair count, symbol formats, vs currency, and error behavior. No filler or 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 simplicity, no output schema, and no annotations, the description is complete: it covers the data fields returned, supported inputs, optional bars, timestamp nuance, access entitlement, and error handling. The 'structured 404' note and 'honest as_of' are particularly useful for an agent to set expectations.

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 only 33% and the sole entry is unhelpful. The description compensates by explaining ticker formats (BTC/BTCUSD/X:BTCUSD) and the vs currency parameter with an example, while 'optional last-7 daily bars' hints at the series flag. It does not exhaustively describe every parameter behavior, but adds meaningful guidance 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 clearly identifies the tool as providing live crypto quotes from a market-data feed, listing specific return fields (last-trade price, 24h change/volume, OHLC, optional daily bars, as_of). It explicitly labels itself as the 'PRIMARY tool for what is BTC at?' which distinguishes it from the many sibling 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 states a clear primary use case ('PRIMARY tool for what is BTC at?') and provides accepted symbol formats and the vs currency example (EUR). It does not mention alternatives or explicit when-not-to-use conditions, but the 'PRIMARY' label strongly implies this is the go-to tool for current quotes.

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 provided, the description carries the full burden of behavioral disclosure. It defines the output conceptually ('names where multiple distinct insiders bought around the same time') but does not mention read-only nature, data freshness, limitations, or any side effects. This is adequate but not rich.

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 long, front-loaded with the core concept, and provides usage guidance without any waste. Every word earns its place.

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 simple zero-parameter tool with no output schema, the description gives a clear definition and usage context. It could elaborate on the exact return format or the definition of 'around the same time', but the current level is sufficient for an agent to select and invoke 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?

The tool has zero parameters and schema coverage is trivially 100%, so the baseline is 4. The description adds no parameter-specific information, which is acceptable since there are no parameters to clarify.

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 what the tool does: it clusters insider buying across companies based on multiple distinct insiders buying around the same time. It distinguishes itself from single-company insider tools by explicitly saying 'rather than one company's filings'.

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 trigger phrases for when to use this tool ('where are insiders buying?') and a clear exclusion ('rather than one company's filings'). However, it does not name specific alternative sibling tools, which prevents a perfect score.

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 of behavioral disclosure. It only says logs are 'recent service log lines' and gives a call trigger; it does not disclose output format, verbosity, time window, or any limitations. Since the tool reads logs, it is likely read-only, but that is not stated.

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 front-loaded substance: first what the tool returns, then when to use it. Every sentence earns its place, and there is no filler or repetition of schema 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?

The tool is simple—zero params and no output schema—but the description leaves operational details vague. It does not specify how 'recent' is defined, how many lines are returned, or whether output is raw text or structured. It provides enough to select the tool appropriately, but not full clarity on what the agent will receive.

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 has zero properties, so there are no parameter semantics to add. With 0 params, the baseline is 4, and the description's 'recent' implies a default time window without needing to document parameters that don't exist.

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 'Recent service log lines,' which clearly identifies the resource and what the tool provides. It also differentiates from sibling status/health tools by framing logs as the diagnostic next step when 'status alone doesn't explain it.'

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 call: when the user asks about system/data pipeline health or missing/stale data and status alone is insufficient. It does not name sibling tools or list explicit when-not scenarios, but the condition 'status alone doesn't explain it' implies that status tools should be tried first.

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 carries the transparency burden. It discloses the tool returns a dashboard of specific macro indicators and a regime read, implying a read-only, one-call aggregation. However, it omits details like data freshness, output format, or limitations of the regime calculation, leaving some behavioral aspects unexplored.

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, compact sentence that front-loads the key indicators and usage instructions. Every word adds value, and it avoids unnecessary elaboration or repetition of schema 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?

For a simple, no-parameter, no-output-schema dashboard tool, the description covers the main content and use cases. It explains what data is included and when to call it. It could add output format or interpretation guidance, but given the tool's low complexity, the description is sufficiently complete for selection and 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?

The tool takes zero parameters, so the schema is empty. The description doesn't need to explain parameter syntax; instead it clarifies what the tool returns, which is appropriate. The baseline for zero-param tools is 4, and the description provides sufficient context about the tool's scope without needing parameter details.

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 identifies the tool as a macro dashboard with specific indicators (VIX, DXY, treasury spreads, fear-greed, regime read) and positions it as the primary entry point for overall market/macro questions. It distinguishes itself from siblings by emphasizing the 'one-call' comprehensive nature and the 'Call it FIRST' prioritization.

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 it FIRST for any how is the overall market / macro backdrop? question, or to frame a single-name view.' This provides strong usage context. It does not name specific alternative tools or exclusions, but the prioritization instruction effectively guides 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?

With no annotations, the description must disclose behavior itself. It does list the return fields and implies a read-only probe, but it does not explicitly state safety, side effects, or interpretation of 'healthy' vs 'stale'. The term 'probe' hints at non-mutation, but deeper behavioral context is absent.

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: a concise definition with a colon-separated field list, followed by a clear call-condition. It is front-loaded, uses no filler, and every word earns its place.

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 simple no-parameter tool with no output schema, the description is fairly complete: it lists the output fields and gives the trigger context. It does not explain each field's meaning or how to judge health from the values, but the field names are self-descriptive and the tool is minimal.

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 tool has zero parameters, so the description carries no parameter burden. The baseline for 0 params is 4, and the description does not need to add parameter semantics. It does mention fields that are outputs, not inputs.

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 identifies the tool as an 'ML pipeline freshness probe' and lists its specific fields (has_predictions, has_weights_history, latest_as_of_ts, n_tickers). It also states exactly when to use it: 'when the user asks whether the ML pipeline is healthy or why predictions look missing/stale.' This distinguishes it from sibling tools like tengu_ml_predict or tengu_ml_weights.

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 gives explicit usage context: 'Call when the user asks whether the ML pipeline is healthy or why predictions look missing/stale.' This tells the agent when to invoke it, but it does not name alternative tools or specify when not to use it, so it falls short of the highest bar.

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 of disclosing behavior. It only states what is returned and that it is 'latest,' but gives no details about side effects, permissions, rate limits, error conditions, or data freshness. This is a significant gap for a tool with no annotation support.

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 concise sentences. The first states the tool's function and key outputs; the second gives usage context. Every word 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 single-parameter tool with no output schema, the description covers the essential components: what it does, what it returns, and when to use it. It lacks a deeper explanation of the output semantics (e.g., what conviction or decile rank mean) and does not clarify how it differs from numerous similar sibling tools, but it is sufficiently complete for simple lookup.

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 schema has 100% coverage for the ticker parameter, so the baseline is 3. The description does not add any meaning beyond restating 'ticker' (e.g., no format examples or constraints), so it neither enriches nor detracts from the schema. Thus, it stays at the baseline.

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 the latest ML ensemble prediction for a single ticker, naming concrete outputs (blended_score, conviction, decile rank, per-voter sub-scores). This makes the purpose unambiguous, but it does not explicitly differentiate from sibling tools like tengu_copilot_score_ticker or tengu_v3_intel_ml_prediction, so it falls short of a 5.

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 trigger phrases ('what does the model think of X') and a clear use case (quantitative score to weigh against fundamentals). However, it does not mention when not to use it or name alternative tools, so it misses the full 'when/when-not/alternatives' guidance required for a 5.

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 carries the full burden. It adds useful context: data comes from a 'snapshot' (implying not real-time) and mentions the optional min_conviction floor. However, it does not disclose the return format, whether conviction scores are included, or any staleness caveats, leaving important behavioral aspects unspecified.

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?

Two sentences, no filler. The first sentence precisely defines the tool, the second adds usage context and an alternative invocation. Every word earns its place.

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 is low-complexity and the description covers purpose, usage, and parameters. However, with no output schema, it would benefit from a brief note about the response structure (e.g., list of tickers with scores) to be fully complete. Still, the core context is adequately provided.

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%, so the description must compensate. It explains min_conviction as a floor and implies 'Top-N' relates to the limit parameter. This adds meaning beyond the raw schema, though it could be more explicit about limit's role and the meaning of 'conviction'.

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-N ranked tickers from the latest ML ensemble scoring snapshot' – a specific verb+resource+output combination. It distinguishes itself from the sibling tool by explicitly naming tengu_ml_predict as the alternative for single-ticker detail.

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 it is the PRIMARY tool for 'what are the model's top picks / best-ranked stocks right now' and directs users to tengu_ml_predict for one ticker's detail. This provides clear when-to-use and when-not-to-use 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 exist, so the description carries the transparency burden. It clearly implies a read-only operation ('Call it to know') and describes the current-live nature plus the per-regime breakdown. It doesn't cover potential limitations (e.g., no history, no sorting options), but for a parameterless getter the behavior is well conveyed.

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?

Two focused sentences: the first states what the tool returns, the second gives usage context and points to the history sibling. No fluff, front-loaded with critical 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?

For a zero-parameter read-only tool with no output schema, the description provides all needed context: what the tool returns, when to use it, and how to get related time-series data. It is sufficiently complete for an agent to select and invoke this 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?

The tool has zero parameters, so the description bears no obligation to explain parameters. The baseline for 0-param tools is 4, and the description adds useful context about what the returned weights represent (latest row, per market regime), which helps the agent interpret the response.

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 identifies the resource (live ML ensemble voter weights) and the specific scope (latest history row, per market regime). It distinguishes from the sibling tengu_ml_weights_history by pointing to that tool for drift over time, making the unique purpose immediately clear.

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?

States exactly when to use it: before interpreting a prediction, to know how the ensemble is blending voters. Explicitly names the alternative tool (tengu_ml_weights_history) for time-based drift, giving the agent 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?

With no annotations provided, the description carries the full burden. It discloses ordering (newest first), per-regime granularity, and valid day range (1-365, default 30). It does not explicitly state read-only behavior, but that's reasonably inferred. Misses potential return format or pagination details, but sufficient for this simple read-oriented tool.

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?

Two sentences, front-loaded with core purpose, then usage guideline. Every word earns its place with no redundancy or fluff. Ideal structure for quick agent comprehension.

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 low complexity (single optional param, no output schema), the description is nearly complete. It covers data type, ordering, scope, and usage distinction. Minor gap: it does not specify the return structure, but that is not essential for a time-series query and can be inferred from the description.

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 only parameter, 'days', is given a clear range (1-365) and default (30) in the description, which the schema lacks (only type and default). This adds meaning beyond the schema and fully compensates for the 0% schema description coverage.

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 provides a time series of ML ensemble voter weights per regime, with explicit ordering (newest first) and a days parameter. It distinguishes itself from the sibling tool tengu_ml_weights by specifying this is for historical drift/shifts while the sibling covers the current row.

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 instructs when to call this tool ('when the user asks how the model's weighting has drifted or shifted across regimes') and directs to an alternative (tengu_ml_weights for the current row). This provides clear usage context and a named alternative.

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 provided, the description carries the full transparency burden. It discloses that the output is a readiness flag set indicating subsystem up/serving status and that it can explain missing/stale data. This is useful context, though it could describe the output format or any potential stale-data caveats more explicitly.

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 long, front-loaded with the core purpose, and the second sentence adds practical usage context. Every word earns its place; no fluff or repetition.

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 simple zero-parameter tool with no output schema, the description covers the essentials: what it returns and when to use it. However, given the large number of sibling health/status tools, a brief note on how it differs from tools like tengu_status or tengu_v3_system_health would make it more complete.

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 tool has 0 parameters, so there is nothing to explain. The schema is empty with 100% coverage, and the description appropriately does not mention any parameters. This aligns with the baseline of 4 for zero-parameter tools.

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 provides 'readiness flags showing which subsystems are up and serving,' which identifies a specific resource and output. It is distinct from most siblings but does not explicitly differentiate from other health-related tools like tengu_status or tengu_v3_system_health, preventing a perfect score.

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 tells the agent when to call: 'when the user asks whether the system/data pipeline is healthy or why data looks missing/stale.' However, it does not mention when not to use it or offer alternative tools, so it lacks the full explicitness of a 5.

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 transparency burden. It discloses what the tool returns (label and probabilities) and that it is a current state, but does not describe any additional behaviors such as data freshness, error conditions, or return structure. For a zero-parameter read tool, this covers the basics but lacks depth.

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 the core purpose in the first sentence and usage guidance in the second. 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's simplicity (no parameters, no output schema), the description covers what it returns and when to use it, with explicit alternatives. It's sufficient for an agent to select and invoke 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?

The tool has zero parameters, and the schema shows no required fields. The description doesn't need to explain parameters; the baseline score of 4 applies.

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 identifies the tool as providing the current market regime label and model regime probabilities. It also distinguishes from sibling tools by explicitly referencing tengu_v2_regime_forecast and tengu_v2_regime_history for different temporal scopes.

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 provides explicit when-to-use guidance: call when the user asks 'what regime are we in?' or before positioning advice. It also names the alternatives for forward and historical views, giving clear selection criteria.

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 of behavioral disclosure. It says nothing about read-only vs. mutating behavior, return format, prerequisites, or side effects. The phrase 'Research knowledge base' offers zero transparency about what invoking this tool does.

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 short at three words, but this is under-specification rather than appropriate conciseness. It does not earn its place because it provides no useful information beyond the tool name. The structure is minimal but not front-loaded with actionable content.

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?

With no annotations, no output schema, and a description consisting only of 'Research knowledge base', the tool is almost entirely unexplained. Given the massive sibling tool set, the description is completely inadequate for an agent to understand what the tool does, what it returns, or when to use it.

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 schema has 0 parameters, so there is no parameter information to document. The baseline for 0 parameters is 4, and the description inevitably adds nothing about parameters because there are none. The schema already fully covers the (empty) parameter set.

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 'Research knowledge base' is a noun phrase that merely restates the tool name 'tengu_research_knowledge' without specifying any action or operation. There is no verb indicating what the tool does (e.g., search, retrieve, query), and it does not distinguish itself from the many sibling 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 provides no guidance on when to use this tool versus alternatives, no context, no exclusions, and no examples. With over 200 sibling tools, an agent has no information to decide when to select this one.

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 provided, the description discloses that the endpoint is heavy and should be used for one ticker at a time, which adds behavioral context. However, it doesn't specify what 'basic trading stats' include or the exact return structure, leaving some ambiguity.

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, with two sentences and a warning, front-loading the core purpose. No filler words; every clause adds 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?

For a simple tool with no output schema and no annotations, the description covers purpose, usage timing, and a performance warning. It lacks specifics on the exact trading stats returned, but given the simplicity, it's largely complete.

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 schema already documents the single 'ticker' parameter at 100% coverage. The description reinforces the single-ticker constraint ('fetch one ticker per call'), which adds minor semantic clarity 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 clearly defines a live price snapshot for a single ticker with latest price and trading stats, using a specific verb and resource. It distinguishes from siblings by emphasizing one-ticker scope and the current-quote use case.

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 when to call: when the user asks where a ticker is trading or needs a current quote before single-name analysis. It also warns that the endpoint is heavy and supports only one ticker per call, implicitly advising against batch calls.

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?

There are no annotations, so the description must disclose behavior. It only says it provides 'system status' without explaining what that includes, response format, or that it is a read-only operation. Minimal behavioral transparency.

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?

Two concise, front-loaded sentences convey purpose and usage without 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?

The description covers purpose and usage but lacks output details and clear differentiation from similar status tools (tengu_ready, tengu_v3_system_health). Since no output schema exists, the agent gets no guidance on what the response will contain.

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 tool has zero parameters; the schema is empty. With no params, the baseline is 4, and the description doesn't need to add parameter semantics.

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 identifies the tool as providing system status for the service and gives specific trigger examples (health checks, missing/stale data). However, it lacks an explicit verb and does not distinguish from sibling health/status 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?

It explicitly states when to call: when the user asks about system/data pipeline health or missing/stale data. No exclusions or alternatives are given, but the context is clear.

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 bears the full burden. It discloses key behavioral traits: filtering by min_ir, capping by limit, and default values. However, it does not explain the output format, ordering, pagination, or any potential side effects, leaving notable gaps in behavioral transparency for a tool with no annotation support.

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 consists of two sentences, both highly informative. It front-loads the core purpose and then specifies usage context without any wasted words or repetition of schema details.

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 is simple (2 optional parameters, no output schema), and the description covers purpose, parameters, and usage context. It lacks explicit details about the return value structure, which could be helpful given no output schema exists, but the description is otherwise complete for its complexity.

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 schema description coverage at 0%, the description compensates by clarifying the meaning of both parameters: 'minimum information ratio (min_ir, default 0.5)' and 'capped at `limit` (default 25)'. This adds semantic value beyond the schema's type and bounds, though it does not fully describe all behavioral nuances of these 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?

The description clearly states the tool's function: 'Mined alpha expressions from the research pipeline' with specific filtering and capping parameters. It distinguishes itself from sibling tools by explicitly mentioning alpha signals/factor expressions discovered by the research engine, a unique scope among the listed siblings.

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 a clear when-to-use directive: 'Call this when the user asks what alpha signals or factor expressions the research engine has actually discovered.' It does not name specific alternatives or provide when-not-to-use guidance, so it falls short of a 5, but the usage context is unambiguous.

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 present, so the description carries the full burden. It clearly indicates historical replay, implying a read-only operation, but lacks detail on output format or limitations; however, the core behavior is disclosed.

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?

Two sentences, front-loaded with purpose, then usage guidance; no 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 zero-parameter tool with no output schema, the description is sufficient for selection and invocation, but could mention what the result looks like to be fully complete.

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 tool takes zero parameters, and the schema is empty (100% coverage trivially). Baseline for zero-param tool is 4; description adds no parameter-specific info but none is needed.

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 a specific verb ('replay') and resource ('past market crash episodes'), clearly distinguishing it from hypothetical stress testing via tengu_v2_stress.

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 trigger phrases ('how would this have held up in previous crashes?') and names the alternative tool for hypothetical 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?

No annotations are provided, so the description carries the full burden. It mentions the rolling window default but does not disclose whether the call is read-only, what the response format is, or any side effects. The description lacks depth on behavior and output.

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 no fluff. The first sentence states the core functionality, the second provides usage scenarios. Text is front-loaded and 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 is simple with one optional parameter and no output schema. The description covers purpose, usage, and parameter default, but does not explain the response content or edge cases. Given the lack of annotations and output schema, it is adequate but not fully complete.

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 schema's only parameter window_days has no description. The description adds meaning by mentioning the rolling window and default of 30 days, but it doesn't explain the effect of varying the window or mention min/max bounds. The schema already provides the numeric constraints.

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 provides 'feature and prediction drift' over a rolling window, which is a specific resource. It does not explicitly distinguish from sibling drift-related tools like tengu_copilot_live_ic_drift or tengu_copilot_voter_ic_drift, but the scope is clear.

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 three concrete user questions that should trigger this tool: model calibration, predictions looking off, and shifted inputs. This gives clear usage context, though it does not explicitly state when not to use it or name alternatives.

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 explains what the tool does (decay measurement) but does not disclose output format, data scope (e.g., all factors vs. a selected set), or any limitations. This is adequate but not deeply 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?

Two sentences, front-loaded with the core function and immediately followed by usage triggers. Every word earns its place; no fluff or repetition.

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-only tool with no output schema, the description covers the essential information: what it computes and when to call it. It does not specify the exact response structure, but given the simplicity, it is reasonably complete.

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 tool has zero parameters, and the schema coverage is trivially 100%. Baseline for 0 params is 4. The description correctly implies no input is needed, so it does not need to elaborate on 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?

The description clearly states the tool's purpose: 'IC/IR half-life per factor — how fast each factor's predictive power decays.' This verb-resource pairing (reports decay) is specific and differentiates it from siblings like tengu_v2_feature_importance or tengu_v2_drift.

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 three explicit scenarios: 'when the user asks which signals are going stale, how long a factor's edge lasts, or before weighting factors in a strategy.' It lacks explicit 'when-not' or alternative tool names, but gives clear context for use.

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 carries the full behavioral disclosure burden. It explains the default top 50 and the optional model filter, but does not describe what happens when no model is specified, the format of the returned importances, or whether results are ordered. This is adequate but not rich.

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 no filler. The action, default behavior, and usage trigger are all front-loaded, making it highly scannable and useful for an AI agent.

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 simple tool with two optional parameters and no output schema, the description covers the main elements: purpose, defaults, and when to call it. It does not describe the return shape, but the tool name and context make that reasonably inferable. Minor gaps like model filtering behavior are not fully addressed, but overall the description is complete enough for most use cases.

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 has no descriptions at all, so the description must compensate. It does explain the top_n default and the model parameter as an optional filter, but it does not clarify what valid model values are or how top_n interacts with the maximum. The schema provides constraints (min/max/default) but the description adds only partial semantic meaning.

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-N feature importances for prediction models, with a specific default (top 50) and an optional model filter. It also provides concrete user-intent phrases ('what is the model actually looking at?') that help distinguish it from generic tools. However, it does not explicitly distinguish itself from sibling tools like tengu_ml_weights or tengu_v3_intel_factor_importance, which may serve similar purposes.

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 says 'Call it when the user asks...', giving clear context for when to use this tool. It lacks when-not-to-use guidance or alternatives, but the provided trigger phrases are strong enough to guide an AI agent in 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?

With no annotations, the description carries the full transparency burden. It discloses that intervals are calibrated, describes the band output, and explains the alpha default and meaning. However, it does not mention potential failure modes, required preconditions (e.g., existing forecast), or any additional behavior like caching or error handling, leaving some ambiguity for a tool with no structured safety 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 core function and immediately followed by usage guidance. No redundant phrases, every word earns its place, and it is appropriately sized for the tool's simplicity.

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 (2 params, no output schema, no annotations), the description is mostly complete: it states output (lower/upper band), key parameter semantics, and usage triggers. It lacks explicit return field names or error conditions, but the 'lower/upper band' phrasing provides a sufficient mental model for an agent. This is adequate but not exhaustive, earning a 4.

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 schema covers 50% of parameters (ticker has a basic path description, alpha lacks description). The description compensates by explaining alpha as 'miscoverage alpha (default 0.1 = 90% interval)' and clarifies ticker's role via 'one ticker's forecast'. This adds meaningful context beyond the schema, though it does not go into detailed format or edge cases.

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 conformal prediction intervals (calibrated lower/upper band) for a single ticker's forecast, with specific reference to the miscoverage alpha. It explicitly contrasts with point estimates, distinguishing it from prediction tools, and specifies scope (one ticker). This is a specific verb+resource description that effectively communicates the tool's 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?

The description provides explicit when-to-use guidance: 'Call it when the user asks how confident is the model? or wants an uncertainty range around a prediction rather than just a point estimate.' This is clear context, but it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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 clearly states the tool's behavior (forecasting probabilities for a future horizon) and implies that it is a read-only operation via the verb 'forecast.' It also provides the default horizon and explicitly contrasts with the current-read sibling, but does not elaborate on output format or additional behaviors. Still, for a simple forecast tool, the description is adequately 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 two sentences long, front-loaded with the core purpose, and every sentence contributes useful information: the first states what the tool does, the second provides usage guidance and names the alternative. There is no redundant or unnecessary 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?

For a tool with one optional parameter, no output schema, and no annotations, the description covers the essentials: what it does, when to use it, and what the parameter means. It also differentiates it from a key sibling. The main minor gap is that it does not describe the exact return shape beyond 'regime probabilities,' but this is sufficient for the tool's simplicity.

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 schema has 0% description coverage, so the description must compensate. It fully explains the meaning of the sole parameter: 'N days ahead' and provides the default '21-day horizon.' This adds significant semantic value beyond the raw schema (type, min, max, default), making the parameter's purpose and optionality clear.

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 a specific verb and resource: 'Forecast regime probabilities N days ahead' with a clear scope (default 21-day horizon). It also explicitly distinguishes itself from the sibling tool tengu_regime, which provides the current label. This makes the tool's purpose unmistakable and differentiates it from related 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 gives explicit when-to-use guidance: 'Call it when the user asks "is the regime about to change?" or wants the forward market-state outlook.' It also names the alternative for the current read: 'use tengu_regime for the current read.' This is exactly the kind of contextual direction an agent needs to choose between the two regime tools.

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 carries the burden of disclosing behavior. It clearly states it returns historical labels and defaults to 180 days, but does not explicitly confirm it is a read-only operation, describe the output format, or mention any limitations or prerequisites. The nature of the tool implies safety, but the description adds no explicit safety or side-effect context.

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 concise sentences. The first states the core functionality and default, the second enumerates concrete use cases. Every word earns its place with no fluff or repetition.

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 (one optional parameter, no output schema) and the rich sibling context, the description covers the essential aspects: purpose, default behavior, and trigger questions. It does not describe the return structure, but the phrase 'regime labels' gives a reasonable hint. Overall, it is adequate and well-scoped for an agent to invoke 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?

The schema has a single parameter 'days' with full validation (default 180, min 1, max 3650), so the schema itself is informative. The description mentions 'last N days (default 180)', which aligns with the parameter but does not add detail beyond what the schema already provides. Since schema description coverage is 0%, the description only partially compensates, but for this simple parameter it is sufficient.

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 identifies the tool as returning 'Historical regime labels over the last N days', specifying both the resource (regime labels) and scope (historical time range). It implicitly distinguishes itself from sibling tools like tengu_v2_regime_forecast by emphasizing 'historical' and from tengu_regime by implying current vs. historical context. The example use cases further nail down 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 explicitly states when to use the tool: when the user asks about current regime duration, last regime shift, or past behavior by regime. It does not explicitly mention when not to use it or point to alternatives, but the clear trigger conditions provide strong guidance for an agent.

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 carries the transparency burden. It discloses that the tool lists available datasets and notes the current state of not_ingested ('currently empty'). However, it does not explicitly state that the tool is read-only or side-effect-free, nor describe the return format. For a catalog tool, this is adequate but not rich.

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 one dense catalog sentence followed by a short usage directive, packing extensive category detail without filler. The em-dash list structure keeps the long enumeration scannable, and the actionable 'Call FIRST' instruction is clear. It is slightly long, but appropriate for listing 39 datasets.

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 discovery tool with no output schema, the description covers the essential ground: it names the dataset categories, ties them to the research-dataset reader, and instructs when to invoke the tool. It does not describe the exact return shape or explain how slugs map to tengu_v2_research_read, which would strengthen completeness. Overall it is adequate for its simple interface.

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 tool takes zero parameters, so the description cannot add parameter-level detail; the baseline for 0 parameters is 4. The mention of 'slug' and not_ingested adds useful context about how dataset identifiers are resolved and how to determine availability. No contradiction with the empty 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 the specific verb 'Discover' and names the exact resource: the 39 licensed research datasets servable via the research-dataset reader. It enumerates categories, making it unmistakably a catalog/discovery tool rather than a data-read tool. The closing instruction 'Call FIRST when unsure of a slug' further distinguishes it from sibling tools like tengu_v2_research_read.

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 tells agents to 'Call FIRST when unsure of a slug,' giving a clear trigger condition for when to use this tool. It also mentions the not_ingested feature for checking pending slugs. It does not explicitly name alternative tools or state when not to use it, but for a zero-parameter discovery tool, the guidance is practical and sufficient.

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 carries the full burden and delivers significant value: server-side ticker pushdown, ticker-ignored fallback for internal-id-keyed datasets, required ticker for implied_vol_by_ticker, full history for cds_composites, and the unfiltered read cap. It does not cover auth/rate limits or response format, but the most critical behavioral traits are disclosed.

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 dense sentences with zero filler; the main purpose is front-loaded and each subsequent clause adds a distinct, useful behavioral detail. The description is appropriately sized for the tool's complexity and does not waste 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?

For a heterogeneous dataset reader with no output schema, the description covers the essential operational context: discovery path, filtering behavior, special-case slugs, and row cap. It omits output shape and explicit limit semantics, but the most likely causes of agent error are addressed, making it reasonably complete.

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 low (33%) and the dataset description is purely tautological ('Path parameter'), so the description compensates effectively: 'dataset' is explained as a slug, 'ticker' gets extensive behavioral semantics, and 'limit' is implied by the 5000-row cap. The limit parameter still lacks a one-line explanation, but its schema constraints (min/max/default) partially fill that gap.

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 'Read any licensed research dataset by slug' – a specific verb and resource that clearly defines the tool's function. It also distinguishes itself from the sibling discovery tool tengu_v2_research_datasets by explicitly referencing it for discovery, making the read-vs-discover boundary unmistakable.

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 concrete usage context: discover datasets via tengu_v2_research_datasets, use ?ticker= for filtering, and be aware of special slugs (implied_vol_by_ticker, cds_composites) and the 5000-row cap. It does not explicitly list alternative read tools, but the guidance is sufficient for an agent to know when this tool is appropriate.

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 of behavioral disclosure. It lists the data fields returned (shares short, DTC, FTD), which is helpful, but it does not mention data freshness, source, or any limitations. For a retrieval tool, this is a moderate transparency gap.

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 exactly two sentences: the first defines the tool's output, the second gives usage guidance. It is front-loaded, efficient, and contains no filler. Every word earns its place.

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 simple one-parameter tool with no output schema and no annotations, the description covers the essential context: what data is returned and when to use it. It does not specify output format or caveats, but given the low complexity, this is largely sufficient.

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% for the single 'ticker' parameter, but the schema description only says 'Path parameter ‘ticker’ (required).' The tool description adds only 'one ticker', which does not meaningfully enhance understanding of the parameter format or expected values. Baseline of 3 applies due to high schema coverage.

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 identifies the tool as providing short interest data for a single ticker, listing specific metrics (shares short, DTC, FTD). It also distinguishes itself by instructing to 'Call it FIRST' for squeeze-related questions. However, it lacks an explicit action verb like 'Retrieve' or 'Get', which prevents a perfect score.

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 second sentence provides explicit guidance on when to use this tool: 'Call it FIRST for any ‘is X heavily shorted / squeeze candidate?’ question or before evaluating short-side risk in a position.' This is clear contextual usage, but it does not mention alternative tools or any when-not-to-use 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?

With no annotations, the description carries full behavioral disclosure. It specifies the output (correlation matrix) and adds interpretive meaning, but does not disclose details like data source, freshness, or any side effects. This is adequate but not rich.

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 long, with each sentence serving a clear purpose: defining the tool and providing usage guidance. No filler or 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 zero parameters, no output schema, and no annotations, the description covers the essential aspects: what the tool does, when to use it, and how to interpret the result. It could be slightly more specific about the matrix format, but is complete enough for this simple 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?

The tool has zero parameters, and the baseline for such cases is 4. There is nothing to document beyond what the empty schema already conveys.

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 produces a correlation matrix across voter signals, which is a specific and distinct resource. It also provides interpretive context (high pairwise correlation means vote count overstates conviction), which disambiguates it from sibling signal 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?

It provides an explicit usage trigger: "Call it when the user asks whether the model's signals are independent or redundant". This gives strong contextual guidance, though it stops short of naming alternative tools or explicit when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses the limit-based result size and the nature of the data (genealogy, OOS scores), but does not explicitly state whether this is a read-only operation, how results are ordered, or what happens if no data exists. It adds some context beyond the schema but is not exhaustive.

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 long, front-loaded with the key concept, and every word adds value. It covers the core behavior, the limit parameter, and usage guidance without 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 the tool's simplicity (one parameter, no output schema) and lack of annotations, the description provides sufficient context: what the tool returns, how it's scoped by limit, and when to use it. It could mention returned fields but the essence is covered.

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 schema has one parameter 'limit' with 0% description coverage, but the description compensates by explaining 'up to `limit` entries (default 50).' This clarifies the parameter's purpose and provides default behavior, though it does not mention the min/max constraints (already in 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 clearly states the tool's function: 'Strategy genealogy with out-of-sample (OOS) scores' and elaborates on how each variant descends from parents and is validated OOS. This specific verb-noun pairing ('genealogy') distinguishes it from sibling tools like tengu_v3_strategies_list or tengu_v3_strategy_metrics.

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 call the tool: 'Call this when the user asks how strategies were developed, mutated, or which generations survived validation.' This is clear context, though it does not mention when not to use it or name alternatives.

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 provided, the description carries the full burden of behavioral disclosure, but it only states the purpose and usage trigger. It does not explain what the stress-test does (e.g., whether it runs simulations, returns risk metrics, or modifies any state), nor does it mention any prerequisites or side effects. The lack of behavioral detail leaves an agent uncertain about the tool's execution model, especially since there is no output schema or parameter documentation to compensate.

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 core purpose and immediately followed by actionable usage guidance. Every sentence earns its place—no fluff or redundancy—making it easy to scan and process.

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 no output schema, the description covers purpose, usage timing, and distinguishes an alternative. It would be slightly more complete if it hinted at what the stress-test yields (e.g., a risk assessment or scenario breakdown), but given the tool's simplicity and the strong usage context, it is largely sufficient.

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 tool has zero parameters, so the schema coverage is trivially 100%. With no parameters to clarify, the description does not need to add parameter-level detail. The baseline for a 0-parameter tool is 4, which is appropriate here; the description could have mentioned that the tool runs predefined scenarios without additional inputs, but its absence does not hinder parameter understanding.

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 a specific verb ('stress-test') and identifies the resource ('scenarios from the risk engine'), clearly stating the tool's purpose. It also distinguishes itself from the sibling tool tengu_v2_crash_scenarios by explicitly contrasting 'stress-test scenarios' with 'replay specific historical crashes', preventing ambiguity.

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 ('Call it when the user asks "what happens if things go bad?" before sizing risk') and names the alternative tool (tengu_v2_crash_scenarios) for a different use case. This is exactly the kind of contextual direction an agent needs to select between closely related tools.

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 carries the full transparency burden. It explains the core output (VaR/CVaR) and defaults but does not disclose return format, methodology, or what portfolio data is used. The description does not contradict any annotations and is harmless but lacks depth on behavior.

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 the core purpose and defaults front-loaded, followed by one sentence of usage guidance. Every word earns its place; 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?

For a simple tool with two optional params and no output schema, the description covers purpose, defaults, and a usage signal. It does not explain the output format or whether a portfolio is pre-configured, but those are minor gaps given the tool's simplicity and the extensive sibling list.

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 schema description coverage is 0%, so the description must clarify the parameters. It does so by mapping 'horizon' to horizon_days, 'confidence' to confidence, and stating defaults (1-day, 99%). This gives additional context beyond the raw names, though it stops short of describing ranges or interpretation.

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 provides portfolio VaR and CVaR with configurable horizon and confidence, giving concrete defaults. It includes a specific call signal ('how much could the portfolio lose?') that distinguishes it from the broad sibling list. The verb is implied but the resource and output metric are 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 explicitly states when to invoke the tool ('when the user asks "how much could the portfolio lose?" or needs a tail-risk number before sizing or hedging decisions'), providing clear context. It does not mention alternatives or exclusions, but the guidance is direct and actionable.

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 carries the full burden. It explains the output structure (severity + reason + evidence rows), the types of flags covered, and the interpretation of an empty result as 'genuinely clean'. However, it doesn't disclose behavior for uncovered or invalid tickers, potential errors, or any rate limits, leaving gaps in edge-case handling.

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 dense sentences with no filler. The first sentence is a long, comma-separated list that front-loads the flag types, which is efficient but visually heavy. Overall, each sentence earns its place and the structure follows a logical flow: what, output shape, when to use.

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?

Since there is no output schema, the description does a good job explaining the return format ('severity + reason with the evidence rows attached') and the meaning of an empty list. It also gives usage timing and a named example. Missing are specifics about ticker coverage and error handling, but for a read-oriented data tool this is fairly complete.

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 50%: only 'ticker' gets a bare description in the schema. The description adds real context for the ticker via the SMCI example, but says nothing about the 'limit' parameter, its default, or its meaning. The description only partially compensates for the schema's lack of detail.

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 identifies the resource ('Forensic accounting red flags with plain-language reasons') and covers specific flag types, which distinguishes it from sibling tools. However, it lacks an explicit verb like 'retrieves' or 'lists', so the purpose is conveyed through a noun phrase rather than a direct action statement.

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 gives explicit usage context: 'Call it before trusting reported financials on any name with earnings-quality doubts' and provides a concrete example (SMCI/EY-resignation cluster). It doesn't state when not to use it or name alternative tools, so it misses the exclusion/alternative guidance for a 5.

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 provided, the description must carry the full burden of behavioral disclosure. It does mention the rolling-window behavior and default window size, which is useful, but it does not state whether this is a read-only operation, describe any side effects, or explain the output format. It provides the core behavior but lacks additional context.

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 no filler. It packs in the core definition, parameter semantics, usage trigger, and an alternative tool reference. Every clause earns its place.

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 one optional parameter and no output schema, so the description should clarify the return value. It explains the metric and when to use it, but it does not specify whether the output is a single accuracy figure, a time series, or the units (e.g., percentage). This is a notable gap for a tool where the output format is not otherwise 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?

The input schema has no parameter descriptions (0% coverage), so the description must compensate. It does so by explaining that 'window_days' controls the rolling window and noting the default of 90. This gives the parameter meaning beyond the raw schema, though it could go further by explaining allowed ranges or effects of different values.

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 identifies the tool's function: 'Realised-vs-predicted accuracy over a rolling window' and explicitly differentiates it from the sibling tool 'prediction_tracker' by stating 'use prediction_tracker for individual predictions'. This makes the purpose unambiguous and distinct.

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: 'Call this when the user asks how accurate the system has been or wants a track record before trusting a new call'. It also names the alternative for individual predictions, giving clear usage boundaries.

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 absent, so the description alone should disclose behavioral traits. It only says 'Recent outputs' with no details on pagination, return structure, whether it is a read-only operation, rate limits, or any other runtime behavior. The description provides essentially no additional behavioral insight beyond the tool's name.

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 short but not effectively concise—it is a fragmented noun phrase that under-specifies the tool. It lacks a complete sentence structure, and while there is no wasted content, the low information density makes it insufficient for the reader to understand the tool's purpose.

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 a 3-parameter tool with no output schema and no annotations, the description should explain what the output is, how limit and ticker affect results, and what 'outputs' actually refer to. None of this is provided. This falls far short of being complete enough for an AI agent to select and invoke 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?

The description adds minimal meaning: 'named agent' hints that agent_name selects the agent, but this is only partially helpful. The other parameters, limit and ticker, have no descriptions in the schema and are not explained in the tool description. Schema description coverage is only 33%, and the agent_name description itself is tautological ('Path parameter (required).'), so the description does not compensate for the lack of parameter semantics.

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 'Recent outputs from a named agent' is a noun phrase with no verb, so it does not explicitly state the action (e.g., retrieve, list). It identifies the resource (recent outputs, named agent) but lacks procedural clarity. It does not differentiate from sibling tools like tengu_v3_agent_status or tengu_v3_agents_list, which could also relate to agent outputs.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions. It fails to point to related tools such as tengu_v3_agents_list for discovering agents or tengu_v3_agent_status for status checks, leaving the AI agent without any direction on appropriate usage.

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 carries the burden. It discloses that the tool returns a catalogue with one entry per agent, which is a complete behavioral description for a zero-parameter list operation. It could mention output fields or ordering, but for a simple list, this is sufficient.

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?

Two sentences, front-loaded with the core purpose. Each sentence adds value: the first defines the output, the second gives usage context. 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?

For a zero-parameter list tool with no output schema, the description adequately explains what it returns (catalogue of every agent, one entry per agent) and when to call it. It could specify entry fields, but the stated purpose ('resolve an agent's name') implies enough structure for selection.

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 is 4. The description correctly omits parameter details; there is nothing to add beyond the empty 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 a specific verb ('Catalogue') and resource ('every agent in the swarm'), clearly stating what the tool returns. It also distinguishes itself from sibling tools by noting it is the swarm-wide list, ideal for resolving an agent's name before drilling into its output.

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 when to use ('when the user asks which agents exist, what the swarm is composed of, or to resolve an agent's name') and implies sequencing ('before drilling into its output'). It lacks named alternatives or explicit when-not-to-use, but the context is clear.

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 carries full responsibility for behavioral disclosure. It states the tool returns 'heartbeat + stats', but does not clarify whether it is read-only, what a heartbeat signifies, what kind of stats are included, or how errors are handled (e.g., unknown 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 ultra-concise, using only six words to convey the essential purpose. It is front-loaded with 'Latest heartbeat' followed by scope. However, it may be underspecified for a complex tool, but for a simple status retrieval it is well-sized.

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 no output schema, so the description should explain what the returned data includes. 'Heartbeat + stats' is vague, not specifying which stats or how they are structured. Additionally, with many sibling tools, this description lacks the context needed to choose it correctly without further investigation.

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% for the single required parameter, agent_name, which already provides a basic description. The tool description adds 'for one agent' which aligns with agent_name but does not add syntax, format, or edge-case 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 clearly states the resource (agent status) and scope (one agent), using 'Latest heartbeat + stats' to convey a retrieval operation. It somewhat distinguishes from siblings like tengu_v3_agents_list (which lists all agents), but does not explicitly differentiate from tengu_v3_agent_latest, which could be similar.

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?

No guidance is provided on when to use this tool versus alternatives. The phrase 'for one agent' implies a use case, but there is no explicit mention of exclusions or related tools such as tengu_v3_agents_list or tengu_v3_agent_latest.

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 provided, the description carries the full burden of behavioral disclosure, but it offers none. It does not mention read-only behavior, response format, pagination, rate limits, or any side effects. The phrase 'Currently-active alerts' merely states the nominal output without explaining what the tool actually does or returns.

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 only two words long, but this is under-specification rather than effective conciseness. It lacks any structure such as a sentence with a verb or clear definition. The extreme brevity means it fails to convey necessary information, earning a low score for structure.

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 no output schema, no annotations, and only a single optional parameter, yet the description is still grossly incomplete. It does not specify what constitutes an 'active' alert, the structure of the returned data, or any limits or filters. Given the large sibling set, the lack of contextual detail makes this tool nearly unusable for an agent.

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 schema has one optional parameter 'severity' with enumerated values, but schema description coverage is 0%. The description does not mention the parameter at all, so the agent learns nothing about how to filter alerts by severity. While the enum labels themselves are self-explanatory, the description fails to compensate for the missing parameter documentation.

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 'Currently-active alerts' essentially restates the tool name 'tengu_v3_alerts_active' without adding specific detail. It fails to clarify what 'alerts' refers to (e.g., system alerts, market alerts, copilot alerts) and does not distinguish this from sibling tools like tengu_v3_stream_alerts or tengu_v3_news_alerts. This is a tautology-level restatement.

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 no guidance on when to use this tool versus alternatives. There are no hints about context, prerequisites, or exclusions. The agent is left without any information to decide between this and other alert-related tools in 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?

No annotations are provided, so the description carries the burden. It implies a read-only diagnostic check but does not explicitly state side effects, output format, or that it does not mutate anything. The link to data missing/stale adds some context.

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?

Two sentences, front-loaded with purpose and followed by usage guidance. No wasted words; every part earns its place.

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 tool with no output schema, the description covers what it does and when to use it. It could briefly mention what 'cap status' entails or output fields, but overall it is sufficiently complete.

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 0 parameters, the baseline is 4. The description adds the 'per-feed' scope, clarifying what the data covers, which is helpful despite no parameters existing.

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 reports per-feed external API quota usage and cap status, naming the specific feeds (news, news-analytics, market-data, alt-data). This is specific and distinguishes it from status/health tools like tengu_status or tengu_system_health by focusing on API quotas.

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 'Call when the user asks whether the system/data pipeline is healthy or why data looks missing/stale.' This provides clear context but does not mention alternatives or exclusions, stopping short of a full 5.

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?

There are no annotations, so the description must convey behavioral traits such as read-only nature, output format, error conditions, or side effects. It discloses nothing beyond the fact that it returns detail for one run, leaving the agent unable to infer safety or expected behavior.

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 only one sentence, yet it is under-specified rather than concise. It restates the name and offers no actionable information, so it does not earn its place despite its brevity.

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 detail-fetch tool with a single parameter, a complete description should mention what 'detail' includes (e.g., performance metrics, status, etc.) or any usage caveats. The description omits all such context, leaving the agent guessing about the response and overall utility.

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% for the single parameter 'run_id' (with a minimal description 'Path parameter run_id (required)'), so the baseline of 3 applies. The tool description adds no extra meaning about what run_id represents or how to format it, but the schema is present and adequate enough to avoid a lower score.

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 'Detail for a single backtest run' is essentially a tautological restatement of the tool name 'tengu_v3_backtest_run_detail'. It does not specify what kinds of details are returned or the exact scope, and it does not differentiate this tool from closely related siblings like tengu_v3_backtest_runs.

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?

No guidance is provided on when to use this tool versus alternatives. The description offers no comparison to sibling tools, no context for selection, and no mention of prerequisites or complementary tools.

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 full responsibility for behavioral disclosure. 'List recent backtest runs' gives minimal information: it does not specify what 'recent' means, sorting order, pagination behavior, or what fields are returned. This is a significant gap for a tool with no annotation safety profile.

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, short sentence with no filler words. It is front-loaded and every word earns its place, making it highly concise and well-structured.

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 list tool with no output schema and no annotations, this description is incomplete. It does not explain what a backtest run is, what fields are returned, how the limit parameter affects results, or how this relates to the detail tool. The 'recent' qualifier is vague, leaving the agent uncertain about the response format and tool behavior.

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 sole parameter 'limit' is not mentioned in the description, and the schema provides no descriptive text (0% coverage). While the schema gives type, default, min, and max, the description adds no meaning. The parameter name is somewhat self-explanatory, but the description does not compensate for the lack of 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 'List recent backtest runs' clearly states a specific action (list) and resource (backtest runs), with a temporal qualifier ('recent'). It distinguishes from sibling tools like tengu_v3_backtest_run_detail, which presumably retrieves details of a single run.

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 does not explicitly mention when to use this tool versus alternatives such as tengu_v3_backtest_run_detail. However, the verb 'list' and the resource name imply enumeration, and the sibling name suggests detail retrieval. This is implied usage rather than explicit 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 must carry the full burden. It discloses nothing about behavior: no pagination, rate limits, side effects, return format, or operational constraints. 'Calibrated trust' hints at a score but lacks any behavioral detail.

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 short, but under-specification is not conciseness. It is a fragment without a sentence structure, lacking the minimal details needed to be useful. It does earn slight credit for brevity but fails to provide substance.

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?

With no output schema, no annotations, and zero parameter descriptions, the description is wholly inadequate for an agent to safely invoke the tool. It does not clarify whether this is a read operation, what data it returns, or how to use the source parameter.

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%, meaning the schema only gives types (integer/string) and a default. The description does not explain what 'source' refers to, what 'limit' controls, or any expected value formats. It adds no meaning 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 'Calibrated trust per signal source' is a noun phrase, not a clear verb+resource statement. It vaguely suggests a metric or rating related to signal source trust, but does not specify what action the tool performs (e.g., retrieve, calculate, list) and does not distinguish it from similar sibling tools like tengu_v3_intel_model_calibration.

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 no guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or alternative tools. It is a bare label with no contextual instructions.

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 provided, the description carries the full burden of behavioral disclosure. It reveals the cache vs on-demand behavior (~5ms vs ~3s), the absence of LLM calls during on-demand builds, the presence of a '_source' field in responses, and the 404 behavior for precompute_only when the cron hasn't run. These are non-obvious behaviors that an agent needs to understand for correct invocation and response interpretation.

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 somewhat long but every sentence carries meaningful information: content list, cache behavior, response marker, and special parameter guidance. It is front-loaded with the core purpose and then supplies necessary behavioral details. The length is justified given the tool's complexity, though it could be slightly tightened.

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 essential invocation context: what the tool returns, the two execution paths, response disambiguation, and when to use the special parameter. However, it leaves gaps around the 'date' and 'fallback_build' parameters, and does not mention any potential error cases beyond the 404. Given the lack of an output schema, this is still a fairly complete picture for an 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?

The input schema has 0% description coverage, so the description must compensate. It provides detailed meaning for precompute_only and implies user_id is the target user for the briefing. However, it does not explain the 'date' or 'fallback_build' parameters at all, leaving their purpose ambiguous. The description adds value for some parameters but not all, so a middle score 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 identifies the tool as a daily briefing for a given user_id and enumerates the exact contents (regime, overnight futures, earnings_today, macro_today, watchlist_signals, news_highlights, risk_exposure, top_movers). This is a specific verb+resource combination and distinguishes the tool from siblings like tengu_v3_briefing_status by focusing on the briefing content rather than status.

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 (daily briefing for a user) and provides clear usage constraints for the precompute_only parameter: 'Pass precompute_only=true ONLY when you specifically need to know whether the cron has already run (e.g. monitoring scripts)'. This gives concrete when-to-use and when-not-to-use guidance, and also explains the two serving modes (cache vs on-demand) without needing to consult alternatives.

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 must carry the behavioral disclosure burden. 'Presence check' implies a read-only boolean-like query, but it does not specify the exact output (e.g., true/false, payload object), error behavior, or whether side effects are absent. It adds some context but is not fully 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 two sentences, front-loaded with the core purpose and then a clear usage direction. Every word 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 simple presence-check tool with 2 parameters and no output schema, the description covers the primary use case but leaves the return format and behavior on missing payloads undefined. It does not explain what a negative presence result looks like or how to interpret 'why it looks missing', which could be ambiguous.

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%, so the description must compensate. It mentions 'for a user/date', identifying the two parameters conceptually, but it does not explain formats, defaults, or that user_id is required. The parameter names are simple enough to infer, but the description does not fully annotate their semantics.

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 function as a 'Presence check for today's briefing payload', using a specific verb (check) and resource (briefing payload). It also distinguishes itself from the sibling tool tengu_v3_briefing_daily by focusing on status/availability rather than generation or retrieval.

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 usage context: 'Call when the user asks whether the daily briefing was generated or why it looks missing.' This gives a clear when-to-use scenario, though it does not explicitly name alternative tools to avoid or state when-not-to-use 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?

With no annotations, the description carries full behavioral disclosure. It explains that rows are appended only on state change (deduped), the monitor runs 2x/day, and it details the alert_type enum and row fields. This gives the agent a clear model of what the tool returns and avoids false outage reports.

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 dense, multi-clause paragraph that covers many aspects but lacks clear sectioning. It is front-loaded with a surprising 'EMPTY UNTIL FIRST USE' notice before stating the core purpose, and the structure could be improved with bullet points or short sentences. Still, every sentence contains useful 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 the absence of an output schema and annotations, the description compensates by listing the alert types, row fields, filter parameters, and the empty-state behavior. It is comprehensive enough for an agent to invoke the tool and interpret results 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 0%, so the description must explain parameters. It clarifies ticker and since_hours as filters and provides the default for since_hours, but it does not mention limit. The schema itself provides default/min/max for limit, so the gap is minor.

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 identifies the tool as alert output from the tracked-decision monitor, listing specific alert types (status_change, earnings_imminent, interval_breach, stale_decision) and describing the data rows. This clearly distinguishes it from other alert tools like tengu_v3_alerts_active or tengu_v3_stream_alerts by scoping it to thesis transitions.

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 tells the agent to poll after decision_track (when the underlying decisions are updated) and instructs how to handle an empty result ('EMPTY UNTIL FIRST USE — not broken... Say that to the user rather than reporting an outage'). It does not name alternative tools but gives enough contextual cues for when 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?

With no annotations, the description carries the full burden. It discloses that the tool produces an estimate (not a guarantee), names the cost components, and implies a read-only, pre-trade nature. It could add context about data sources or units, but for a simple estimator this is adequate. It does not contradict anything.

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?

Two sentences, front-loaded with the core purpose, followed by a usage tip. No filler, every clause adds value. This is a model of concise, structured description.

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 no output schema, so the description must convey return value and workflow context. It lists the three cost components (spread, impact, commission) and states when to call it ('before sizing or routing'). It doesn't specify units or return format, which would be nice, but for its simplicity the coverage is strong. It also complements the execution-plan siblings.

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 only 33% (only ticker has a description). The description compensates by explaining qty (default 100) and side (buy/sell), including defaults and the meaning of the side parameter. It does not add detail on qty bounds beyond defaults, but the schema covers those. The description adds meaningful semantic context beyond the bare 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 clearly states the tool computes 'pre-trade expected execution cost' for a ticker, listing specific components: spread, market impact, and commission. This is a specific verb+resource with a clear output scope. It also distinguishes itself from sibling tools twap_plan/vwap_plan, which is exemplary.

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 'Call it to know what a trade will actually cost before sizing or routing it' and directs to 'use twap_plan/vwap_plan for the execution schedule itself.' This gives both when-to-use and alternative tools, making the decision boundary crystal clear.

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 carries the full burden. It discloses that blocks degrade independently and that missing data returns an error field instead of failing the call—a valuable behavioral trait. It doesn't mention authentication or side effects, but for a read-only snapshot this is less critical, and the degradation behavior adds significant transparency.

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 three sentences, front-loaded with the purpose, then lists contents, behavioral nuance, and related tools. Each sentence 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 single-parameter snapshot tool with no output schema, the description communicates the return content, use case, degradation behavior, and related tools. It could slightly elaborate on the output envelope (e.g., response structure), but it is sufficiently complete for an agent to call and interpret the result.

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 only parameter is 'ticker', whose schema description merely says 'Path parameter (required)'. The tool description doesn't elaborate on the ticker format or examples, but the phrase 'for a company' makes its meaning obvious. Baseline of 3 applies because schema coverage is 100%, even though the schema description is thin.

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 it provides a 'credit snapshot' and enumerates precisely what data it returns (CDS spread, default probability, S&P rating, bond yield/volume, loan count). It is clearly positioned as the first call for credit risk questions, and the 'Drill down' sentence distinguishes it from the more specific credit_bonds/cds/ratings/loans 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 gives an explicit usage trigger ('call FIRST for any how risky is this company's debt? question') and names the alternative drill-down tools. It doesn't explicitly state when NOT to use it, but the 'call FIRST' framing strongly implies it is the entry point and that more granular tools are for follow-up.

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 key behavioral traits: the maximum 90-day window, potential data lag of months, the fallback to 'latest_available' when the default window is empty, and the need to page backwards. This is beyond what the schema provides and is highly actionable.

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 packs dense, relevant information into three tightly structured sentences: purpose/content, matching/window, and lag/paging behavior. Every clause adds value; no filler or 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 there is no output schema and no annotations, the description is remarkably complete: source (FINRA TRACE), scope (one issuer), content (price, yield, volume, side), matching logic, time window, data lag, fallback, and pagination guidance. An agent can reasonably invoke this tool and interpret responses without additional external knowledge.

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 low (25%), with only 'ticker' described. The description compensates by explaining the matching mechanism (FINRA bond-symbol prefix), the window span (at most 90 days), and the paging behavior ('page backwards from latest_available'). This adds meaningful context for start/end and limit, though it doesn't detail exact date formats.

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: it provides FINRA TRACE corporate-bond trade prints for one issuer, with specific data fields (price, yield, volume, buy/sell side). It distinguishes itself from sibling credit tools by emphasizing realized credit spreads on actual OTC trades rather than quotes, and the matching mechanism via FINRA bond-symbol prefix.

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 when to use this tool: when you need actual bond trade prints and realized credit spreads for a specific issuer, contrasting with 'not quotes'. It also provides operational guidance on the 90-day window and lag, but it doesn't explicitly name alternative tools or state explicit exclusion criteria, so a slight gap remains.

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 carries the disclosure burden. It lists returned metrics and coverage, but does not describe output structure, pagination, or handling of missing data. It adds useful context but leaves notable behavioral aspects undisclosed.

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?

Two sentences, each carrying distinct value: first lists data contents, second provides usage, coverage, and ticker guidance. No redundancy or fluff, and it is front-loaded with the most important 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?

The description is sufficient for tool selection but incomplete for correct invocation. It does not specify date formats, whether start/end are inclusive, the meaning of the limit parameter, or the exact response shape. More detail would be expected given 4 parameters and no output schema.

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 only 25% (ticker only). The description mentions the default coverage range but does not explain how start/end or limit parameters behave, their format, or defaults (beyond limit's schema default). This is a significant gap for a history tool with a date range.

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 identifies the tool as a daily 5Y single-name CDS spread history, listing specific output fields (par spreads, default probability, rating). It explicitly distinguishes itself from the snapshot sibling by noting 'tengu_v3_credit is the one-call snapshot', which eliminates ambiguity.

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 gives explicit usage guidance: 'Call it for how default risk has trended' and provides the alternative snapshot tool. It also includes coverage details (2005 to end-2025, 5Y tenor) and ticker matching rules for liquid US names, which informs when the tool is applicable.

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 provided, the description carries the full burden. It discloses a key non-obvious behavior: data is T-2 daily composite and must never be presented as realtime. This is essential to prevent agent errors. It does not cover other behaviors like output format or pagination, but the most critical caveat is explicitly highlighted.

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 three dense sentences: what the tool is, when to use it, and a key caveat. The freshness warning is effectively highlighted with capital letters. Every sentence adds value and there is no 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?

The description covers the main purpose and the most important caveat, which is good given the absence of an output schema. However, it leaves parameter usage vague (especially days and limit) and does not specify what the response will look like. For a simple data retrieval tool this is acceptable but not fully complete.

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%, so the description must compensate. It partially explains the family parameter by connecting CDX/iTraxx to geographies, but it does not explain the days, limit, or index_ticker parameters. The phrase 'by series/version/tenor' hints at index_ticker meaning but lacks concrete syntax or defaults. This is insufficient for a 4-parameter tool with no 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 identifies the resource as 'Credit-index composites' and specifies the exact components (CDX NA IG/HY, iTraxx Europe/Asia/SovX), data type (daily composite spreads and prices), and date range (2018 to T-2). This distinguishes it from sibling tools like credit_bonds or credit_cds_history, with a specific verb 'Call it for' and clear scope.

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: 'Call it for credit-market risk appetite, spread-widening episodes, or cross-asset stress context.' It also provides a critical usage caution about freshness ('never present as realtime'). However, it does not name alternative tools or explicitly state when not to use it, so it falls just short of a 5.

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 carries the full burden. It adds meaningful behavioral context by describing the data content and explaining that include_lenders adds syndicate allocations. It stops short of explicitly addressing read-only status, pagination, or output format, but the static 'loan book' phrasing and safe data-query nature are reasonably conveyed.

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 dense, relevant information. The first sentence front-loads the core resource and fields; the second provides positioning and usage. Every clause earns its place, with no filler or repetition.

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 does a good job telling the agent what data to expect (facility-level details, covenants, optional lender allocations). It also supplies context about how it fits with the bond tape. Minor gaps exist around API-specific behaviors like limit semantics and possible empty results, but overall it is substantially complete.

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 low (only ticker has a tautological description). The description compensates by clarifying that ticker is a borrower ticker and explaining that include_lenders adds recent-facility allocations. However, the limit parameter is left entirely undocumented, meaning the agent receives no semantic guidance for it.

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 identifies the resource as a syndicated loan book for a single borrower, enumerating the specific data fields (facility size, type, maturity, security/seniority, spreads, covenants). It distinguishes itself from sibling credit tools by explicitly positioning as a private-credit complement to the TRACE bond tape, making its scope 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 explicitly states when to use this tool ('call for leverage, facility or covenant questions') and contrasts it with the bond tape (tengu_v3_credit_bonds). It also specifies the matching mechanism ('match on borrower ticker'), giving the agent clear criteria 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?

With no annotations, the description carries the transparency burden. It discloses sorting (newest first), issuer resolution via CUSIP-6, instrument-level actions that can share dates, and the licensed-action scope. It doesn't describe response shape or limit/pagination behavior, but it provides meaningful non-obvious context.

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 dense, front-loaded sentences cover purpose, use cases, and resolution mechanics without filler. Each sentence earns its place.

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 low-complexity two-parameter tool with no output schema, the description covers purpose, trigger, ordering, scope, and non-obvious resolution logic. Remaining gaps are output-field detail and explicit limit semantics, but these are minor for correct 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 only 50%; `ticker` has a tautological schema description and `limit` has no prose. The description adds real meaning to `ticker` by explaining equity-ticker-to-CUSIP-6 resolution, but it never clarifies `limit` behavior or its default. Partial compensation for the schema's weak coverage.

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 names a specific resource—'Full S&P rating-action history for one issuer's debt'—and lists the exact event types (new rating, upgrade, downgrade, outlook/creditwatch change) with from/to symbols and ordering. This clearly distinguishes it from credit-related siblings like bond, CDS, or calendar 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?

Provides explicit trigger guidance: 'Use when asked what a company is rated or when/why it was up/downgraded.' It does not name alternative tools or state when not to use it, but the use cases are concrete enough to guide an agent.

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 present, so the description carries the full burden. It discloses multi-source fan-out, reconciliation via primacy-weighted majority, per-source breakdowns, deduplicated citations, vendor_coverage_alert, confidence level definitions, the projection-only flag, and 15-min caching. This is exemplary transparency.

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 dense but front-loaded with usage guidance, and every clause in the two sentences adds value. There is no repetition or filler; it efficiently packs operational detail into a compact form.

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?

It thoroughly covers the return structure (summary, per-source breakdown, citations), confidence semantics, data quality alert, caching, and the low-confidence edge case with projection-only flag. This equips an agent to both invoke and interpret results without an output schema.

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 schema has a single parameter 'ticker' with a trivial description ('Path parameter'). The description adds no additional meaning about ticker format or examples. Schema coverage is 100%, so the baseline of 3 applies.

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 'Use when' and explicitly defines the query intent ('next earnings date', 'when a company reports'), followed by a clear statement that it returns a single canonical answer. It distinguishes itself from siblings by labeling itself the 'CANONICAL multi-source consensus tool' and specifying the exact resource (next earnings date for a ticker).

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 provides concrete usage triggers, including the natural language form 'when is X's next earnings?', and positions itself as canonical. However, it does not explicitly name alternative tools or state when not to use it, though the canonical label implies preference over other earnings-related tools.

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?

Even though no annotations are present, the description compensates well by disclosing key behavioral details: it emits partial and result events, first paint latency (~500ms with is_projected=false and confidence=high), the 2-3s verified result timing, and the vendor_coverage_alert flag when web consensus disagrees. It doesn't cover all potential failure modes or stream teardown behavior, but the core event-driven behavior is clearly disclosed.

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 yet information-dense, covering purpose, transport, event types, timing, confidence semantics, use cases, and a comparative alternative in two sentences. No filler or redundant restatement of the schema. Highly effective front-loading with the STREAMING variant headline.

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 streaming variant with one simple parameter and no output schema, the description fully explains the event contract, latency characteristics, and alternative tool. It tells the agent everything needed to decide between streaming and synchronous calls and interpret the two events. Complete for its complexity class.

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 schema has 100% coverage for the single required ticker parameter, so the baseline is 3. The description adds contextual meaning beyond the schema by implying the parameter is used to scope the earnings next consensus stream for a specific ticker. While it doesn't elaborate on validation or formatting, the parameter's purpose is obvious from the tool's description.

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 'STREAMING variant of tengu_v3_earnings_next' and states it delivers earnings consensus via Server-Sent Events. It clearly names the two emitted events (partial and result), their semantics, and timing, making the tool's purpose and scope unmistakable. This distinguishes it from its sibling tengu_v3_earnings_next while preserving the shared consensus contract.

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 this streaming variant — 'when a consumer can render incrementally and wants the fastest possible first paint' — and specifically cites chat surfaces and live tickers. It also provides a direct exclusion: 'Synchronous consumers should keep using tengu_v3_earnings_next', naming the alternative and explaining the cost-aware tradeoff.

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