jawz

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

The annotations already mark the operation as read-only and non-destructive, and the description adds further behavioral context: it does not log invocations, entitlement is required for non-open loops, and all published loops are currently open and free. This goes meaningfully beyond the structured annotations.

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

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

Three concise sentences, each carrying distinct value: the action, the entitlement caveat, and the logging distinction from run_chapter. No filler or redundant restatement of the schema.

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 two-parameter read-only tool with an output schema, the description covers the essential context: what is fetched, how chapters are identified, entitlement rules, and the relationship to the logging variant. Nothing critical 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 input schema already covers both parameters fully, including an enum for node with descriptions. The description repeats 'loop slug and node' but adds no additional semantic detail, 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?

Description uses a specific verb ('Fetch') with a clear resource ('full content of a chapter') and identifies the two required identifiers ('loop slug and node'). It also distinguishes itself from run_chapter and get_loop by framing chapter-level content 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?

Explicitly states when the tool is appropriate: fetching chapter content without logging an invocation. It names run_chapter as the alternative for running the framework and logging, and mentions entitlement conditions. This gives clear routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by calling it a 'Public read' and indicating the data is Mako-curated and auditable, which helps the agent understand access and provenance.

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 compact sentences, with the core purpose first and the sibling distinction second. There is no redundant wording, and the parenthetical field list efficiently conveys the return contents without bloating the 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?

For a zero-parameter read-only tool with an output schema present, the description fully covers purpose, access level, data provenance, and the relationship to a sibling tool. Nothing needed for correct invocation or selection 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 has zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description adds no parameter confusion and even lists output fields ('CNY trillions + source URL + as_of_month + note'), which indirectly clarifies what the no-argument call returns.

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 ('Read') and a specific resource ('latest Mako-curated PBoC balance-sheet publication'), then enumerates the contained fields. It also distinguishes itself from get_financial_conditions by noting the same value is embedded there, which prevents confusion among 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 explicitly states when to use this tool ('suitable for surfacing directly when explaining the China leg of global liquidity') and names the alternative path (get_financial_conditions.pillars.global_liquidity.components.china) with the reason to prefer this tool ('direct/auditable access'). This is clear routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description fully aligns by calling itself a read-history. It adds valuable behavioral detail beyond annotations: provenance tags ('observed' vs 'reconstructed'), default windows, response structure with presentation/display_markdown, event/delta summaries, and the distinction between point-in-time and live data.

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 every clause contributes: return contents, rate-leg nuance, tool differentiation, use-case motivation, response layout, and provenance. It could be trimmed slightly without losing meaning, but it is well organized and front-loaded with the core purpose before diving into 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?

Despite having an output schema, the description still explains the response's important structural aspects: presentation.display_markdown, data.rows, summary.deltas, events, and provenance tags. It also covers defaults, depth, and interpretation guidance, making the tool fully callable and interpretable by an agent with no prior 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?

Schema coverage is 100%, so the description carries no heavy burden for parameter meaning. It reinforces defaults ('Defaults to the last 12 weeks, weekly') already present in the schema, and adds no new parameter-level semantics beyond what the schema documents.

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 a specific verb and resource: 'Financial-conditions read-history — a timeseries of how conditions have moved over recent weeks.' It enumerates exactly what is returned (composite, direction, pillar values, rate legs), and differentiates itself from sibling history tools by positioning itself as 'the price of risk' alongside get_regime_history and get_liquidity_history.

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 clear usage context: it is the historical complement to point-in-time reads, and it names sibling history tools and their distinct purposes ('the judgment' vs 'the flow'). It does not explicitly name a point-read alternative or state when NOT to use it, so guidance is strong but slightly implicit.

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=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: it reports pipeline health, staleness, unavailability, and plain-language notices for missed scheduled updates, which goes beyond a generic 'get status' phrasing. No contradictions with annotations.

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

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

The description is rich but every sentence earns its place: the first defines the resource and its contents, the second adds pipeline and notice behavior, the third clarifies when to use it. It is front-loaded with the most identifying phrase and contains no filler or tautology.

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 parameters, a read-only annotation, and an existing output schema, the description fully covers what an agent needs: what is returned, the scope ('every data source'), and the decision context. Nothing essential is missing 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?

There are zero parameters and the schema is empty, so the description has no parameter burden. The description instead explains what the output covers, which is the relevant semantic content for a no-argument health-check tool. The no-parameters baseline 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 names a concrete resource ('Freshness status for every data source Jawz reads') and a specific verb/action implied by reporting status. It enumerates concrete artifacts (per-source release date, latest observation date, expected cadence, age in days) that clearly distinguish it from sibling data-retrieval tools. The 'Applies when...' clause further anchors 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 gives an explicit applicability condition: use when the reliability of a figure depends on how current its underlying data is. It does not explicitly contrast with sibling tools or name when not to use it, but the stated context is enough to guide selection among the many get_* siblings.

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 only declare readOnlyHint and destructiveHint, so the description carries the load for behavior. It discloses that the tool iterates Decision Records, calls score_position_drift per record, returns specific fields, and explains the nuanced semantics of each flag type (e.g., fit_low_structural is low by design, not decay). This far exceeds what annotations provide and adds no contradictions.

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 every sentence earns its place: the first sentence front-loads the core purpose and return values, and the flag-type list provides essential interpretation context. No filler or redundancy; the structure makes a complex behavioral contract digestible.

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 read-only scanner with an output schema, the description is complete: it explains the input (portfolio of Decision Records), the process (iterating and scoring), the output semantics (flag types and accompanying fields), and the operational context (backing Mode 4.3 and feeding Mode 4.2). Nothing critical for correct invocation or interpretation 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?

Schema description coverage is 100% and the schema already defines portfolio as an array of Decision Records with field-level descriptions. The description adds some contextual meaning by saying it iterates and calls score_position_drift, but the parameter semantics themselves are largely already documented in the schema, 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?

The description states a specific verb ('portfolio-wide drift scan'), a clear resource (Decision Records), and the output (flagged positions with severity + why_flagged + review_questions). It also enumerates the exact flag types, making the tool's function unambiguous and easily distinguishable from its sibling score_position_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 clearly frames this as the portfolio-wide scan and references Mode 4.3 (Thesis Status Sweep) as its use case, plus mentions it calls score_position_drift on each record, implying the single-position alternative. However, it does not explicitly state 'use score_position_drift for a single position' or provide a when-not-to-use exclusion, so it stops 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?

Annotations mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: data can be 'live' or a dated 'catalog' snapshot, holdings are TOP-N so exposure is a floor, bond/commodity ETFs return no holdings by design, and unknown tickers are surfaced in unknown_tickers. This is rich, accurate, and non-contradictory.

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, each carrying distinct value: the use case, the source/data freshness distinction, the TOP-N limitation, and edge-case behavior. The most important information is front-loaded and the description is efficient without being terse.

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 read-only tool with a single parameter and an output schema, the description covers the essential operational details: purpose, data provenance, freshness semantics, coverage limitations, and unknown-ticker behavior. Nothing critical is missing for an agent to invoke and interpret 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 schema already documents the sole parameter (tickers) with examples, so the baseline is 3. The description adds meaningful semantic value by explaining how unknown tickers are handled, that only top-N holdings are returned, and that certain ETF types yield no holdings—all directly relevant to using the parameter correctly.

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: ETF look-through that returns top holdings and weights for concentration checks. It distinguishes itself from the broad set of sibling 'get_' tools by specifically targeting Chapter 2 Mode 2.2 and by explaining why it exists.

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: this is for the Concentration Check in Chapter 2 Mode 2.2, and explains how the AI should use it to overlay holdings with direct positions. It does not explicitly name alternatives or when-not-to-use, but the context is strong and no sibling tool competes directly.

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=true and destructiveHint=false, and the description adds substantial behavioral detail: consensus: null means unpublished rather than zero, results carry provenance fields, unsupported event types return empty lists with a staleness flag rather than silence, and coverage ends at a fixed date with a flag. No contradiction exists.

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

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

The description is long but information-dense, with the core purpose front-loaded in the first sentence. Some redundancy with the schema and heavy use of caveats make it less crisp, but each behavioral note earns its place given the tool's edge cases.

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 an output schema present, the description covers the non-obvious behavioral context: null consensus semantics, provenance fields, fixed coverage horizon, unsupported event types, and deferred pricing. An agent has enough context to invoke the tool correctly and interpret surprising empty or flagged 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?

Schema description coverage is 100%, so the schema already documents both parameters and defaults. The description reinforces event_types semantics and explains the empty-list behavior, but adds little new meaning for lookahead_days. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 verb and resource: getting scheduled US macro events (FOMC, CPI, NFP, PCE) with dates and consensus. It clearly differentiates the tool through explicit coverage constraints, so an agent understands what this calendar does and does not contain.

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 name sibling alternatives, but it gives clear selection guidance by specifying which event types are tracked and which are accepted-but-empty, and by noting that market-implied pricing is a separate deferred quantity. This tells an agent when to expect meaningful results and when not to use the 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: conditional PBoC inclusion, G4 vs G3 basis, US net liquidity sub-component, and Mako-curated provenance fields. This gives an agent a realistic picture of how the result may vary by data availability without contradicting the 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 dense but every sentence earns its place: it lists components, explains conditional behavior, states the return shape, clarifies scope fields, and gives parameter guidance. It is front-loaded with the core purpose and packs necessary nuance without 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 complex read tool with one optional parameter and an output schema, this description is complete. It explains the data composition, the G4/G3 conditional logic, provenance reporting, the composite/driver return shape, and the summary_only behavior. Nothing critical is missing for an agent to 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 schema already documents summary_only with 100% coverage, so the baseline is 3. The description adds value by explaining why summary_only matters as the lightweight one-line read used in regime composition, and by contrasting it with the full read. This is useful contextual semantics beyond the schema's boolean definition.

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 verb and resource: a 'full financial conditions read' encompassing liquidity, yields, spreads, DXY, and VIX. It goes well beyond the title by enumerating exact components and the G4/G3 distinction, making it clearly distinguishable from financial siblings like get_china_liquidity and get_macro_regime.

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 clear context on when to use the lightweight summary variant ('used in regime composition'), but it does not explicitly say when to prefer this tool over related siblings or when not to use it. Usage context is implied by the feature description rather than explicitly carving out 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds behavioral nuance: GDPNow is reported, not scored, and does not affect classification; missing data yields status 'unavailable' in staleness_flags, which is distinct from zero. These are valuable behavioral details beyond the annotation hints.

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. It front-loads the indicator list, then explains the GDPNow quirk and the unavailable status. Every sentence adds value, and there is no redundant or filler content. The structure is logical: main content first, then edge cases.

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 parameterless read-only tool with an output schema (signaled), the description covers the returned indicators, the classification, and the special handling of GDPNow and missing estimates. Nothing an agent needs to decide whether to call it or interpret results is missing, given the output schema presumably provides field structure.

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%. There are no parameter descriptions needed. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not 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 states exactly what the tool returns: a specific set of growth indicators (industrial production, consumer sentiment, yield curve, initial claims, GDPNow) and a classification. This is specific and distinguishes it from siblings like get_inflation_indicators, which are not mentioned but clearly different. The verb 'returns' is implied but the resource is precisely enumerated.

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 usage for growth-pillar analysis by naming the indicators, and the sibling list confirms alternatives exist. It does not explicitly say 'use this for growth questions, not for inflation' but the content makes the appropriate context clear. There is no explicit exclusion or alternative routing, but the specificity compensates.

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=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by stating that the tool returns a classification (supportive/neutral/headwind), which is not derivable from structured fields alone.

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 deliver a scannable list of contents and a note on the returned classification. Every word earns its place, and the key scope phrase 'Inflation pillar indicators' 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?

For a zero-parameter, read-only retrieval tool with an output schema, the description covers the input context and return behavior sufficiently. It does not explain classification semantics or data vintage/caveats, but the output schema likely covers return structure and the annotations cover safety.

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 provides no parameter semantics to cover. The description meaningfully fills the void by enumerating exactly which indicators are included, which is the relevant information for invoking this no-arg tool.

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 verb-and-resource purpose: get inflation pillar indicators. It enumerates concrete sub-indicators (CPI, PCE, breakevens, wage growth), distinguishing it from siblings like get_growth_indicators and get_financial_conditions.

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 usage when inflation data is needed and names the exact coverage, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or alternatives are named, so the guidance is clear but implicit.

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

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

The description goes far beyond the readOnlyHint annotation. It explains subtle behaviors: the basis flip (g4↔g3) that changes the headline total, the China-leg publication step that causes a one-time jump, and the provenance tagging (observed vs reconstructed). It also discloses the response structure (presentation object with display_markdown, data.rows, summary), making the tool's behavior fully transparent. No contradiction with annotations.

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

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

The description is extremely verbose, with repetitive explanations about basis flips and China-leg steps that appear multiple times (e.g., 'Reading note, enforced by the artifact' and then again in the same paragraph). While each sentence adds some nuance, the redundancy and long, clause-heavy sentences could be trimmed for clarity. It is structured logically, but not concise.

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

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

Given the complexity of the data (vintage handling, basis flips, provenance), the description covers all necessary context: what the data represents, how it's structured in the response (presentation, data.rows, summary), edge cases (China publication step), and defaults. The output schema is described in the prose, so an agent knows exactly what to expect. No gaps remain.

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?

Both parameters (interval, lookback_weeks) have descriptions in the schema, and the tool description adds crucial semantics: defaults, clamping (1–52), and how interval affects the sample cadence. This is high added value beyond the schema, which only lists enums and basic types. The coverage is 100%, and the description enriches both parameters meaningfully.

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 a read-only history of global liquidity, returning a timeseries with specific components (Fed/ECB/BoJ/PBoC, basis, classification). It explicitly names the sibling tool get_financial_conditions as its 'companion', distinguishing it as the historical counterpart. The verb 'get' plus the resource 'liquidity_history' leaves no ambiguity about its 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?

It provides strong usage context by naming get_financial_conditions as the current-day counterpart and specifying the default period (last 12 weeks, weekly). It also explains the data provenance (observed vs reconstructed) and the handling of basis flips, which helps an agent decide when to call it. However, it does not explicitly state 'use this when you need historical liquidity data' or contrast with other history tools like get_conditions_history, so a small 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds valuable context beyond those: it clarifies the return scope (no chapter content) and access rules ('all active loops are navigable by anyone'). This gives an agent useful behavioral expectations without redundancy.

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 tight sentences that front-load the main purpose and immediately specify key limitations and access. Every clause adds value; no filler or unnecessary detail.

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 single required parameter, a rich output schema, and read-only annotations, the description provides everything an agent needs: what it returns, what it excludes, and who can use it. The mention of 'active loops' adds an important boundary condition. No significant gaps.

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 loop_slug with a clear example ('jawz'), and description coverage is 100%. The description only reinforces that the lookup is 'by slug' without adding new meaning or constraints, so it meets the baseline but does not exceed 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?

Description uses specific verb 'Get' and resource 'metadata and chapter manifest for a loop by slug,' clearly stating what the tool returns. It explicitly notes it returns 'loop info and the list of chapter nodes with titles — no chapter content,' which differentiates it from content-returning tools like get_chapter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: this tool is for metadata and titles only, not chapter content, and states that 'all active loops are navigable by anyone,' addressing access. It implies the alternative of using a content-focused tool but does not explicitly name one, so it stops 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context by detailing the response's three representations (presentation, tables, data) and the provenance block with as-of dates and ages, which goes beyond the annotation-only signal.

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 purpose is front-loaded in the first sentence, and the subsequent sentences explain the response format and provenance without unnecessary padding. Slightly detailed for a zero-parameter read, but 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 zero-parameter read-only tool with an output schema and safety annotations, the description covers the core behavior and return structure well. It does not explicitly mention the historical alternative, but the 'current' qualifier partially makes up for that.

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 parameter semantics to clarify. The description does not need to compensate, and the schema coverage is trivially complete.

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 and resource: 'Get current macro regime' with the expected GREEN/YELLOW/RED values and business cycle positioning. The word 'current' also separates it from sibling get_regime_history, which covers historical regimes.

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 word 'current' implies this is for the latest regime snapshot, while siblings such as get_regime_history and get_conditions_history cover historical views. However, the description never explicitly says when to choose this tool over the alternatives, leaving that 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context: resolution logic (matched_by isin|qualified_symbol|bare_symbol), mismatch reporting rather than silent overrides, the tokenized-stock collision policy, and FX conversion behavior. This goes well beyond what annotations provide.

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 well-organized, front-loading the core purpose and then layering resolution details, collision handling, and currency behavior. Every sentence adds information, though the tokenized-stock list and resolution taxonomy make it longer than strictly necessary. The structure is logical and scannable.

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 output schema exists (so return values are documented elsewhere), the description covers all decision-relevant context: what the tool does, how resolution works, how to force a path, how currency conversion behaves, and how conflicts are handled. An agent has everything needed to invoke it correctly 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by explaining the resolution semantics (hints narrow resolution, contradictions are reported), the collision policy for specific symbols, and the base_currency 'native' behavior. It doesn't repeat schema details but enriches them with behavioral context.

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 a clear verb and resource: 'Live prices for one or more holdings' and immediately distinguishes itself from siblings by emphasizing it 'shows its work' with resolution details, FX, and per-holding breakdowns. It is specific about what it returns (price, value, day change, resolution, quote, fx) and how it handles ambiguous tickers, making it unmistakable among the many get_* 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 explicitly states when to use this tool (live prices for holdings) and provides detailed guidance on how to disambiguate symbols, including the tokenized-stock collision list and the NASDAQ:X / X.US qualification. It also explains base_currency behavior and the 'native' option. While it doesn't name a specific alternative sibling, the guidance is so specific that an agent can confidently select it for price queries.

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=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: the Liquidity column's two non-market step reasons, the coverage flip and China-leg publication lag, provenance tagging (observed vs reconstructed), depth-limitation, and the presentation object structure. It also warns against misreading the Liquidity column and points to a safer alternative. No contradiction with annotations.

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

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

The description is dense but well-organized: it front-loads the purpose, then explains the distinction, then the critical Liquidity warning, then the response format and provenance. While it is long, every sentence carries substantive information, especially the caveat about the Liquidity column. It could be slightly more scannable with bullet points, but it earns its length.

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—two parameters, a tricky column, provenance semantics, and a presentation object—the description covers all essential aspects: what it returns, how to interpret the risky field, how to avoid pitfalls, the alternative tool, and the output structure. The output schema exists, so return-value details are covered elsewhere. Nothing an agent needs to call it correctly 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 schema already covers both parameters with descriptions: interval has 'Sample cadence (default weekly)' and lookback_weeks has 'How many weeks of history to cover (default 12, clamped 1–52)'. The description adds no new parameter semantics beyond echoing the defaults ('Defaults to the last 12 weeks, weekly'). With 100% schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Macro regime read-history — a timeseries of how the regime and its drivers have moved over recent weeks.' It enumerates the exact columns (regime color, business-cycle quadrant, growth + inflation class, etc.) and explicitly distinguishes it from a comparison of two point reads and from get_liquidity_history. This makes the tool's function and scope unambiguous relative to its 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 explicitly says when to use: 'Provides the observed history behind a

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 readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful transparency by listing exactly what the tool returns: the Jawz Loop description, example prompts, a live market read, glossary note, and guide link. No contradictions with annotations.

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

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

The description is one well-organized sentence that front-loads purpose and then enumerates the returned content. It is slightly dense, but every clause earns its place and there is 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 an output schema, the description is fully sufficient. It explains the purpose, when to use it, and what to expect in the response, leaving no major gaps for an agent to call 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 parameter description is unnecessary. Setting the baseline at 4 is appropriate because no parameter disambiguation is required and schema coverage is effectively complete.

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 orientation/onboarding aid for a new Jawz connection and for questions about what Jawz is and how to use it. It names specific, concrete outputs, distinguishing it from sibling tools like get_loop or get_prices, which appear focused on data 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 explicitly states when to use it: for new connections and for questions about Jawz's scope, coverage, or usage. It does not explicitly name alternatives or exclusion cases, but the use context is clear enough for an agent to select 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?

The description goes well beyond the readOnly and destructive annotations by explaining classification semantics, the difference between surprise and vs_consensus, the directional meaning of hot/cool, the n/a case, and the provenance age measurement behavior. This is exactly the behavioral context an agent needs to interpret results correctly.

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 every sentence earns its place by preventing misinterpretation. It front-loads the core resource and timing, then explains output semantics and edge cases without 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-optional-parameter read-only tool with an output schema, the description is highly complete. It covers timing, absence semantics, field explanations, interpretation pitfalls, and idempotent behavior. Nothing essential for correct invocation or result interpretation appears 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?

Schema coverage is 100%, and the schema already documents week_ending format and default. The description adds meaningful parameter-adjacent semantics: the Friday anchoring, the freshness caveat, and the fact that consensus_provenance.age_days is measured at week_ending rather than call time. This goes beyond the baseline but does not redefine the parameter itself.

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: past week's data releases with an H.4.1 net liquidity update. It is specific about scope and timing, but it does not explicitly contrast itself with sibling tools such as get_event_calendar or get_data_health, so it stops short of full sibling differentiation.

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 clear usage context by stating the tool is anchored to Friday and most current when run Friday morning or later. It also advises that re-asking for an earlier week yields stable age_days values. However, it gives no explicit when-not-to-use guidance or alternative tool 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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: default-to-latest behavior, slug format expectations, and list_only returning available editions without content, which goes beyond what the annotations convey.

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 filler. It front-loads the core purpose, then efficiently covers default behavior, slug format, provenance of claims, and list_only mode. 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?

Given this is a simple read-only retrieval tool with zero required parameters, a rich output schema, and clear annotations, the description covers everything needed: what it returns, how to select an edition, and how to list editions. No meaningful gap remains.

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%, so the baseline is 3, but the description adds meaningful detail: it specifies the YYYY-MM-DD slug format, confirms omission yields the latest, and explains that list_only excludes content. This enriches the parameter semantics beyond the schema alone.

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 verb ('Read') and a specific resource ('Jawz World Brief'), immediately distinguishing it from all 21 sibling getters. It also clarifies the default behavior and the key option, 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 clearly states when to fetch the latest edition versus a specific slug, and when to use list_only to retrieve editions without content. It does not explicitly name alternatives, but the tool is unique among siblings and 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?

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is known. The description adds valuable behavioral detail: it returns loop metadata, access status, and the active loop, states that every published loop is free and open, and explains that entitled deprecated loops appear with deprecated: true. This goes beyond the annotations without contradicting them.

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 concise sentences, each adding distinct information: the primary listing purpose, the return contents, and the deprecated-loop nuance. No filler or redundancy. The key facts are 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?

For a zero-parameter listing tool with an output schema present, the description is complete. It covers the main use case, access semantics, current-active-loop information, and deprecated-loop behavior. Nothing essential 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 has zero parameters and the schema is empty, so there is no parameter documentation burden. The baseline for zero parameters is 4, and the description appropriately focuses on the output and behavioral aspects rather than 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 states the tool's verb ('List') and resource ('all available Jawz loops'), and specifies the scope: metadata, access status, and the currently active loop for the user. This distinguishes it from the sibling get_loop, which presumably fetches a single loop, by focusing on collection-level listing.

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 but not explicit. The description implies this is the tool to call to enumerate available loops and see which is active, but it does not name alternatives or state when to prefer list_loops over get_loop or run_mode. The guidance is sufficient for a zero-parameter read-only listing, but lacks explicit 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?

The description discloses important behavioral traits beyond the annotations: repeated calls return identical content rather than regenerating text, each call appends a usage-counter row, and each call returns a new invocation_id for feedback. This is exactly the kind of side-effect and determinism information an agent needs and that annotations do not provide.

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, no filler, primary behavior first, side effects after. Every sentence adds useful information and the structure makes the most important details immediately visible.

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 what the tool returns, its stable/cached behavior, its side effect, and the invocation_id usage. An output schema is present, so return details do not need to be fully explained. The main gap is that loop_slug and node parameter semantics are left shallow, and no explicit comparison with get_chapter is 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 description coverage is 100%, so the baseline is 3. However, the schema descriptions are minimal: 'Loop slug', 'Chapter node', and 'Optional user context' add little real meaning. The tool description also does not explain how loop_slug and node relate to the returned framework text, nor what each node enum value means. It earns the baseline but no more.

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 a specific verb and resource: 'Returns a chapter's published framework text' and lists what that text contains (modes, questions, output format). This is much clearer than the tool title alone. It does not explicitly differentiate itself from the sibling get_chapter, so it loses a point for sibling distinction.

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 clear intended use: the framework text is reference material for the assistant to apply when judging appropriately. This tells an agent why it would call the tool. However, it does not mention when not to use it or compare it with alternatives like get_chapter or run_mode.

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

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

The description discloses behaviors beyond the annotations: repeated calls return identical content (not regenerated), each call appends a usage-counter row, and each call returns a new invocation_id for feedback. This is valuable operational context that annotations do not provide.

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, each earning its place: one for what is returned, one for idempotent behavior, one for side effects and feedback linkage. No fluff, no repetition of schema content, and the most differentiating 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?

The description covers the core behavior, the side effect, and the deterministic nature of the tool. An output schema exists, so return-value details are not required. It could additionally mention prerequisites or explicit alternative conditions, but nothing essential for calling the tool correctly 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the 'mode' concept and the granularity of the call, but it does not add parameter-specific detail beyond what the schema's descriptions and enum already provide. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Returns') and a precise resource: 'published framework text for one named mode within a chapter.' It also distinguishes itself from fetching the full chapter, which separates it from the sibling run_chapter. The purpose is immediately clear and 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 clearly frames when this tool is appropriate: when a single mode's text is needed rather than the entire chapter. It does not explicitly name sibling alternatives or state when not to use it, but the 'rather than the full chapter' contrast provides solid contextual 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?

Annotations already mark the tool as read-only, and the description adds meaningful behavioral context beyond that: the output is observational, contains no buy/sell recommendation, and includes drift labels and review questions. This gives an agent an accurate model of what the tool will and will not do, without contradicting the 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 three sentences with a front-loaded purpose and no filler. The explicit list of output fields is slightly redundant given the declared output schema, but it is compact and useful enough to justify a high score.

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 read-only annotations, a fully documented schema, and an output schema, the description is complete: it explains what the tool scores, which modes it supports, what type of output to expect, and that it is observational. No critical operational information 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?

Schema description coverage is 100%, so all six parameters are documented with types, enums, and descriptions. The tool description adds little parameter-level meaning beyond 'single position' and 'since entry', so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a specific verb and resource: score how a single position's regime fit has drifted since entry, and enumerates the returned fields. It is clear and actionable, but it does not explicitly contrast the tool with sibling get_drift_alerts or get_regime_history, so differentiation relies on name and context rather than an explicit 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 clear context: it supports Chapter 4 Mode 4.2 for single-name retrospective review and Mode 4.3 for per-position drift across the book, and explicitly states that no buy/sell recommendation is made. It lacks explicit exclusions or named alternatives, but the mode references and observational caveat provide enough guidance for an agent to decide 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.