Zensei Index

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuinely new context: the payload mirrors website FAQ wording (static, verbatim documentation) and should be fetched once, which tells the agent the content is stable and cacheable. It stops short of describing response size or 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?

Two short sentences, zero filler. The content summary is front-loaded and the call instruction trails as the operative takeaway.

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 compensates by enumerating the topics the response covers, so an agent knows what it will get back. Minor gap: no indication of payload length or whether the response is prose versus structured sections.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is nothing to document; the baseline of 4 applies. The description correctly implies a no-argument call.

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 the resource precisely: it returns explanatory content about the Zensei Index (what it is, how the score is read and built, free vs Premium tier). This clearly separates it from the sibling tools, which all return index data rather than documentation. It lacks a clean action verb, but 'about' content is 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?

'Call it once before interpreting any score' gives an explicit trigger condition and a usage constraint (once, not repeatedly). There is no explicit when-not or named alternative, but none is meaningfully needed for a static about tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: access-tier gating on history depth and, critically, the inverted scale ('LOWER IS HEALTHIER', 'a rising score means conditions are deteriorating'), which prevents a costly misinterpretation. It does not say what happens when `days` exceeds the free-tier cap (error vs. truncation), which is the remaining behavioral 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?

Three sentences, front-loaded with what is returned, then limits, then score interpretation. Every sentence carries information an agent needs; the scale explanation is essential rather than padding because the polarity is counterintuitive.

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 does supply the return shape (one score plus regime per day) and the semantics of the values, which is sufficient for correct interpretation. The one omission is edge-case behavior when the requested window exceeds the account tier's limit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents default 30 / max 3650, so the bar is baseline 3. The description earns above baseline by binding the `days` value to an access-tier constraint (31 free, 3650 premium), adding meaning the schema does not carry.

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?

States a specific verb+resource ('Daily Zensei Index scores ... with the regime of each day') for a bounded lookback window, which is clearly distinct from siblings like zensei_index_today and zensei_index_summary. It never explicitly names those siblings as alternatives, so differentiation is inferable rather than stated.

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 context is implied by the tier limits ('Free access covers the last 31 days; Premium covers up to 3650 days'), which tells an agent what range is obtainable. There is no explicit when-to-use-this-vs-another statement or exclusion relative to zensei_index_today / zensei_index_summary.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the return shape (ten indicators with status, layer, weight, explanation) and defining the full status taxonomy and what Calibrating/Unknown mean. Some operational context such as freshness or caching is not stated, keeping it short of a 5.

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?

Front-loaded with what the tool returns and then a single sentence of purpose, followed by the status legend. The legend costs several clauses but each one earns its place by preventing misreading of status values. Slightly dense but not padded.

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 and no parameters, the description carries the full burden of describing the return value, and it does so thoroughly: per-indicator fields plus the meaning of every status label, including edge cases like Calibrating and Unknown. Nothing an agent needs to interpret the response is missing.

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 there is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies a parameterless call returning today's fixed 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?

States a specific resource (the ten indicators behind today's Zensei Index) and enumerates exactly what each entry carries: status, layer, weight, and explanation. An agent can tell this is the 'why' companion to the index. However, it never distinguishes itself from the similarly named sibling zensei_view_indicators, which an agent could easily confuse it with.

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?

'Use it to explain why the index sits where it does' supplies a concrete use case, implying it complements summary/today tools. But it names no alternative and gives no exclusions (e.g., when to prefer zensei_index_summary or zensei_view_indicators), so the routing decision is left to inference.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds important semantics beyond that: summaries are rewritten only when indicators change, staleness fields must be checked, and the score is a risk score where lower is healthier. It also warns that a rising score means deterioration, preventing a likely misinterpretation.

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 purpose, then adds freshness guidance and score interpretation in a compact sequence. Every sentence earns its place by either distinguishing the tool, preventing stale quoting, or preventing score misinterpretation.

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?

There is no output schema, so the description carries the burden of explaining return content and does so effectively: it names the score, regime, `stale`, and `ageDays`, explains when the summary changes, and defines the score scale and direction. This is complete enough for correct selection and 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 there is no input parameter semantics to explain; the baseline for this situation is 4. The description still adds meaning about return fields like `stale`, `ageDays`, score, and regime, which is useful even though it is not strictly input-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?

States exactly what the tool returns: the latest written Zensei Index summary with its score and regime. It distinguishes itself from the sibling zensei_index_today by telling the agent to prefer that tool for the current number.

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?

Gives explicit routing guidance: use this for the written summary, check `stale` and `ageDays` before quoting it as today's view, and prefer zensei_index_today for the current number. This is a clear when-to-use/when-to-prefer-alternative instruction.

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

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

Annotations already establish this as a safe, idempotent, closed-world read. The description adds what annotations cannot: the inverted semantics ('LOWER IS HEALTHIER', 'a rising score means conditions are deteriorating'), which directly prevents an agent from misreading the output. It also supplies the band thresholds needed to interpret the number.

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?

Front-loads the return payload, then the directionality warning, then the escalation path to the indicators tool. Each sentence carries distinct and non-redundant information; nothing repeats the title or annotations.

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 takes on return-value disclosure and does it fully – score, regime label, and layer breakdown are all named. Combined with the risk-direction explanation, an agent has everything needed to call and interpret 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 takes zero parameters, so the baseline of 4 applies and there is nothing for the description to compensate for. Schema coverage is 100% regardless.

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?

States a specific resource and scope ('Today's Zensei Index for U.S. equities') and enumerates exactly what comes back: final score, regime label, and three named layer scores. Against siblings like zensei_index_history and zensei_index_indicators, the 'today' scoping makes the boundary obvious.

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 routes the agent to zensei_index_indicators to understand drivers, which is a genuine alternative-selection cue. It stops short of naming when to prefer zensei_index_history or zensei_index_summary, so the sibling routing is only partly covered.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: an account prerequisite and a Premium gating rule for named custom lists. It does not mention pagination or size limits, but nothing is contradicted.

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 short sentences, each earning its place: identity of the result, the selection/default rule plus constraints, and follow-up routing. The key scoping information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still conveys the return shape (symbols plus their pinned sector). For a single optional-parameter read tool with full annotation coverage, an agent has everything needed to decide and call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema documents `list` with its default. The description adds meaning beyond the schema by tying custom list names to the Premium tier and clarifying that the unnamed case resolves to "Favorites".

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?

States a specific verb+resource: the signed-in user's saved symbols, each with its pinned sector. It names the default list and explicitly routes figure lookups to zensei_stock_detail and zensei_sector_detail, so an agent can distinguish it from the sibling detail/scan tools without opening schemas.

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 conditions are given: reads "Favorites" unless `list` names another list, requires a Zensei account, and custom lists are Premium-only. It also names the follow-up tools to use for figures, which is concrete alternative routing.

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

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

Annotations already declare this read-only, idempotent, and non-destructive, so the bar is lower. The description still adds real value by disclosing the return shape (each stock plus the sector ETFs holding it, ordered largest weight first) and the Premium entitlement requirement.

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 tight sentences with no waste; the core search purpose is front-loaded and the return shape and entitlement follow in order of importance.

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 usefully describes the result structure and ordering, and flags the Premium gate. Only the absence of guidance on paging or result limits keeps it from 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 100% on a single required 'query' parameter, so the schema already carries the semantics. The description restates only that the query is a ticker or name, adding nothing beyond the schema's own example.

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?

States a specific verb (Find) and resource (sector ETFs and stocks), with the lookup keys (ticker or name). It is recognizably a search tool, though it does not name the sibling detail tools (zensei_stock_detail, zensei_sector_detail) that an agent might pick instead.

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?

Implies usage by saying it looks up tickers or names and notes 'Needs Zensei Premium' as a prerequisite, but it never states when to choose this over zensei_stock_detail, zensei_sector_detail, or zensei_sectors_scan.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety needs no restating. The description adds value annotations can't: the 25-holding cap, the entitlement gate that will block non-broad sectors, and the non-obvious semantic that holding quadrants are measured against the sector ETF rather than SPY. Only the absence of any mention of latency or payload size keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the purpose before the return detail and the tier rule. The holdings-field enumeration is dense but earns its place because there is no output schema; a tighter phrasing would drop the redundant '"quadrant against the sector ETF (not against SPY)"' restatement only slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so thoroughly: what top-level metrics appear, what each holding row contains, how many holdings max, and which symbols are gated. Combined with the one-parameter schema and read-only annotations, an agent has everything needed to call it correctly 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?

Schema coverage is 100% and the schema already gives examples (XLK, URA), so baseline is 3. The description earns an extra point by enumerating the 11 free tickers, which directly informs symbol choice and predicts whether a call will succeed or hit the paywall.

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 resource ("one sector ETF in depth") and enumerates exactly what comes back: quadrant, momentum, returns vs SPY, valuation, top holdings. "One ... in depth" implicitly contrasts with the sibling zensei_sectors_scan, which the description names as the symbol source. It does not differentiate against zensei_view_sector or zensei_stock_detail, which are the closest remaining 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?

It gives a concrete entry path ("Get symbols from zensei_sectors_scan") and an entitlement rule (11 named broad sectors are free, everything else needs Premium). It stops short of explicit "when not to use" guidance, e.g. whether zensei_view_sector is the lighter alternative to this deep-dive.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond those annotations by defining the quadrant methodology, listing the additional metrics returned, and disclosing that free access covers only 11 broad sectors while premium adds 104 thematic/industry sectors.

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 purpose, then efficiently defines each quadrant and coverage tiers before pointing to the single-sector alternative. Despite covering several concepts, every sentence supports correct tool selection or interpretation.

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 and no parameters, the description carries the burden of explaining what the tool returns. It describes the quadrant categories, the momentum/relative-strength/return fields, and the difference between free and premium sector coverage, which is sufficient for an agent to use 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 takes zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and nothing in the description introduces confusion about 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 states a specific resource and analysis: each sector ETF's performance versus SPY, organized into four named quadrants. It explicitly distinguishes this scan from zensei_sector_detail, which covers a single sector's holdings.

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 clearly indicates the tool is for a cross-sector overview and names the alternative for single-sector holdings: zensei_sector_detail. It also explains the free-versus-premium coverage boundary, which affects whether the agent should expect 11 or 115 sectors.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: tier-dependent default sector resolution and the fact that every tracked holding sector is returned with its own quadrant. It does not discuss rate limits, auth requirements, or what happens when a stock is held by no tracked sector.

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, with the payload contents front-loaded and the fallback behavior placed where it matters. The first sentence is a long multi-clause enumeration but every item listed is a distinct returned field that the agent otherwise could not know (no output schema exists), so little is wasted.

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 only two parameters, full schema coverage, and no output schema, the description correctly takes on the job of enumerating return contents and explaining tier-dependent defaults. The main remaining gap is edge-case behavior, such as what is returned if the stock is not held by any tracked sector ETF.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both `symbol` and `sector` with examples, and the baseline is 3. The description does add real meaning for `sector` by explaining it as the comparison 'lens' and describing the default resolution when it is omitted, but the `symbol` parameter gets no additional treatment 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 names the specific resource (one stock's performance measured against a sector ETF that holds it, called its 'lens') and enumerates exactly what is returned: 1w–1y returns, gap to sector, relative-strength trend, valuation, next earnings date, and per-sector quadrants. This is clearly distinguishable from the sibling zensei_sector_detail, which operates at the sector level rather than the stock-vs-sector level.

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 final sentence gives explicit, actionable context about the `sector` parameter: omit it and the free tier falls back to a broad S&P 500 sector holding the stock, while Premium uses the largest-weight sector. That is clear conditional behavior, but the description does not name alternatives (e.g., when to reach for zensei_sector_detail or zensei_view_indicators instead).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the non-obvious behavioral fact that this is an implicit rendering dependency of a view, which annotations cannot express. It does not mention return shape or any side effects of the render, a minor 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?

Two short sentences, purpose first, redirect second, with zero filler. Each sentence carries actionable 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 no-parameter, no-output-schema, annotation-covered internal helper, the description gives exactly what an agent needs: what it is, that it should not be called directly, and which sibling to call instead.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. It correctly implies no caller-supplied arguments by framing the tool as view-internal.

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?

States a specific verb/resource ('draw the ten indicator charts inside the view') and explicitly scopes it as an internal renderer used by the Zensei Index view. An agent can immediately tell this apart from the data-returning siblings like zensei_index_indicators.

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 'Not for direct use' and names the correct alternative, zensei_index_indicators, covering both when-not and the substitute. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context: this is an internal view-scaffolding endpoint that an agent should not invoke directly, which is behavioral information the annotations cannot convey. It stops short of saying what happens if called outside the view, keeping it from a 5.

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 short sentences with zero filler, and the critical routing instruction is front-loaded after the purpose statement. Every 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 single-parameter read-only tool with rich annotations and full schema coverage, the description covers purpose, routing, and the internal-only nature. Minor gap: it doesn't say what calling it outside the view context does, which matters slightly given there is 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 100% and the single symbol parameter is already documented in the schema with format, constraints, and an example (XLK). The description adds no further meaning about the parameter, so the baseline 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?

Names a specific verb and resource: opens one sector's holdings inside the sector map view. It also explicitly contrasts itself with the sibling zensei_sector_detail, so an agent can distinguish the two without opening schemas.

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 plainly that the tool is not for direct use and names the alternative (zensei_sector_detail). Both the when-not and the replacement are explicit, leaving nothing to inference.

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