closelook-intelligence

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 clear. The description adds behavioral context by specifying the exact output content (returns for multiple periods) and the temporal context (end-of-day), going beyond 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 two sentences long, with the key information front-loaded ('Side-by-side of all Closelook headline indices') followed by specific metrics. No unnecessary words; it is efficient and well-structured.

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

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

For a zero-parameter, read-only tool with no output schema, the description is remarkably complete. It lists the indices, metrics, and timing context, giving an agent everything needed to understand what the tool returns and when to use it.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain; the description correctly focuses on the tool's output instead.

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 performs a side-by-side comparison of all Closelook headline indices and lists the specific indices and metrics included (last close, 1-day, 1-week, MTD returns). This distinguishes it from sibling tools like get_index_snapshot, which likely focuses on a single index.

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

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

The description provides clear context for use: 'The fastest read on where the AI trade rotated, end-of-day' implies it is intended for quick daily overviews. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context about the glossary's scope (260+ entries, categories, coined terms). It does not contradict annotations and adds value by describing what the tool accesses.

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

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

The description is a single sentence that is front-loaded with the main action ('Get Closelook's definition'). The parenthetical list of glossary categories is relevant and informative, though slightly dense, but every part serves a purpose.

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

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

Given the simple one-parameter tool and read-only annotations, the description sufficiently explains purpose and scope. It does not specify the return format, but 'definition' implies a textual answer, which is adequate for this tool.

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

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

The input schema provides a complete description of the 'term' parameter, including examples (e.g., 'Korea discount' or 'MACD'), so the description does not need to add more. Schema coverage is 100%, meeting the baseline.

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

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

The description clearly states the tool retrieves Closelook's definition of a financial or market term from its 260+ entry glossary. It specifies the resource (glossary) and various categories, distinguishing it from sibling tools like compare_indices and get_index_snapshot.

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 the tool is for looking up term definitions but does not provide explicit guidance on when to use this tool versus alternatives like search_closelook. No exclusions or conditional usage are mentioned.

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 it as read-only and non-destructive, and the description adds useful behavioral context: it is a curated, hand-worked pick, includes closing forecast details, mirrors the public web page, and is published weekly on Friday. It doesn't contradict annotations and gives more insight into the nature of the output.

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

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

The description is compact, front-loads the main purpose, and adds essential context about content and cadence in two sentences. The phrasing is slightly ornate and cryptic at the end ('STANDING... diary views, scored afterwards'), but it does not waste words.

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

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

For a simple read-only retrieval with zero required parameters and no output schema, the description covers the core context: what the pick is, where it comes from, and the weekly publication timing. It leaves minor ambiguity about exact response structure, but this is not critical for invocation.

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

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

The input schema fully documents both parameters ('all' and 'date') with meaningful descriptions. The tool description does not need to repeat those, but it also adds no extra semantic details or usage nuances for the parameters beyond 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 clearly identifies the tool as returning Closelook's weekly Chart Pick: one standout name from the Directional Flow engine, with setup bullets, house reading, and forecast views. It is not a tautology and gives the resource and cadence, though it does not use an explicit retrieval verb like 'returns' or 'gets'.

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 cadence and format imply when to use this tool — for the weekly Friday Chart Pick — but the description does not explicitly say when to use it over sibling tools or when to use the 'all' vs 'date' parameters. It identifies what the tool offers but leaves the choice of alternatives to the agent.

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

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

Annotations already cover readOnlyHint=true and destructiveHint=false, so the read-only nature is established. The description adds useful context with 'End-of-day' timing and details on data elements (IG/BBB/B/HY spreads, 20/60-day deltas, 3-year percentiles). It does not disclose potential limitations or data freshness beyond 'End-of-day', but it does add value beyond 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 a single dense sentence but packs substantial information without filler. It front-loads the tool's identity ('Closelook’s AI Credit Stress Tape') and then lists the data components. It is efficient, though slightly run-on and could benefit from sentence breaks for readability.

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 major data categories (funding ladder, credit spreads, tier aggregates, per-issuer flags) and notes end-of-day timing. However, with no output schema, it leaves the exact output structure, units, and flag semantics unspecified. It gives a strong overview but is not fully self-contained for an agent interpreting raw output.

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

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

There are zero parameters, so no parameter semantics are needed. The schema coverage is 100% with an empty object, and the description correctly omits parameter details. Baseline of 4 applies for a zero-parameter 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 clearly identifies the tool as providing an 'AI Credit Stress Tape' and enumerates its components (funding ladder, FRED spreads, tier aggregates, warning flags). It distinguishes itself from sibling tools by focusing specifically on credit stress. However, it never explicitly states the action verb (like 'returns' or 'provides'), relying on the tool name and title for that.

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 no guidance on when to use this tool versus alternatives. It does not mention why one would select this over get_index_snapshot or get_latest_view, nor does it specify exclusions or use-case context. The implied use is for checking credit stress, but explicit comparison is absent.

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 this as read-only and non-destructive, so the description's key behavioral additions are the 'Last 90 trading days' availability constraint and the default of the latest day when date is omitted. This is useful context beyond the annotations, but the description does not disclose other traits such as result structure or behavior when no content 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 a single dense sentence that front-loads the tool's purpose and includes the valuable 90-day limit. It is efficient and avoids repetition, though the final possessive clause about the web page is slightly indirect rather than purely functional.

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 100% schema coverage and only two optional parameters, the description provides enough context about what the agent will receive, including the specific editions and the 90-day window. It is not fully exhaustive, but the missing details are already covered by the schema or annotations.

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?

Since schema description coverage is 100%, the schema already documents both the 'date' and 'days' parameters fully. The description adds no new parameter-level semantics, only restating the date-or-latest behavior and a 90-trading-day constraint.

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 the trading-day hub, enumerating exactly which pieces are returned for a given date: the Morning 10 headline, Midday 10 headline, and Daily Pulse edition(s) with links. It is resource-specific and distinct from sibling tools that return individual pieces, though it relies on nouns rather than an explicit action verb like 'returns' or 'gets'.

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 the tool should be used when you need all of a trading day's content pieces together, particularly when you have a specific date or want the latest. It does not explicitly say when not to use it or name a sibling alternative, leaving usage to be inferred.

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 readOnlyHint=true and destructiveHint=false. The description adds valuable context: data freshness ('nightly', 'End-of-day'), methodology ('recency-weighted regression on log-closes'), and coverage (~330 stocks). This goes beyond what annotations convey, though it doesn't disclose every edge case.

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 yet efficient. The first sentence is a compact definition, the seven views are listed, and the closing sentence provides source context. No filler words; every clause contributes.

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 a heavier burden. It explains the ranking concept and all view options, but doesn't explicitly state the response format (e.g., whether it returns ticker and score). For a simple ranking tool, it's nearly complete, but a brief mention of output shape would seal the gap.

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 covers both parameters with descriptions and an enum for view. The description enhances the enum by mapping each value to human-readable phrases with timeframes: 'rising fastest (21d)', 'this week’s biggest moves (5d)', etc., adding meaning not present in the schema 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 tool as returning the nightly Directional Flow ranking, with specific methodology (recency-weighted regression on log-closes) and enumerates all seven ranking views. This distinguishes it from sibling tools like get_signal_scores or get_factor_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?

The description provides clear context: it is the nightly, end-of-day ranking tool, and it mirrors a known web page. It implies when to use it (for trend-quality rankings) without explicitly naming alternatives or exclusion scenarios, 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, so the read-only safe nature is known. The description adds useful context not in the annotations: that this is an end-of-day reading, and it details the metrics computed (50-day trend, percentile, ROC). It does not need to disclose side effects since it is a pure read.

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

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

The description is two tight sentences that front-load the purpose ('factor-regime read') and then pack relevant detail: asset pair, trend horizon, output metrics, and 'end-of-day' timing. Every sentence earns its place, with no fluff.

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

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

For a zero-parameter, read-only tool with no output schema, the description is remarkably complete: it explains the exact indicator (SPMO/SPLV), the analysis (vs 50-day trend), the outputs (leading factor, percentile stretch, ROC), and the timing (end-of-day). The agent can select and invoke this tool confidently without further clarification.

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

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

The tool has 0 parameters, so the baseline is 4. The description does not need to explain params, and it doesn't. It still adds context about what the tool computes, but the schema is empty, so no param semantics are required.

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

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

The description clearly states the tool provides a factor-regime read: the momentum/low-volatility ratio (SPMO vs SPLV) against its 50-day trend, including which factor leads, how stretched the ratio is (3-year percentile), and 20/60-day rate of change. This specific verb (read) and resource (factor regime) distinguishes it from sibling tools like get_credit_stress or get_signal_scores.

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: 'The fastest single read on risk appetite under the index surface.' It implies when to use (quick risk-appetite check) but does not explicitly mention when not to use or name alternative tools for other scenarios. This is a clear context without exclusions, so a 4 is appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds meaningful context beyond annotations: the data is proprietary and end-of-day, and it specifies the return content (level, returns, sub-index strengths). This adds useful behavioral detail without contradicting 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 a single, information-dense sentence. It front-loads the purpose, lists all options inline, and specifies the return fields without any redundancy. Every word earns its place.

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

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

For a simple one-parameter read-only tool with no output schema, the description covers all necessary aspects: what it does (snapshot), the valid inputs (with semantics), and what it returns (level, returns, sub-index extremes). The sibling tools are available for comparison, but this tool's description is complete on its own.

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 provides 100% coverage for the single parameter with an enum and a brief description. The tool description goes further by attaching semantic meanings to each enum value (e.g., RUBIN for AI buildout, HALO for non-AI growth), which helps the agent select the correct index. This exceeds the baseline for high schema coverage.

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

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

The description clearly states the tool returns a current snapshot of one specific Closelook index, listing all valid index codes (RUBIN, HALO, AW40, AEI, EUROAI) and the exact data returned (level, recent returns, strongest/weakest sub-indices). This is a specific verb+resource and distinguishes from siblings like compare_indices, which is for comparison.

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 this is for retrieving a snapshot of a single index, but does not explicitly state when to use this versus alternatives like compare_indices. There are no exclusions or when-not-to-use instructions, so it stops at implied usage rather than explicit guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about the content (Morning 10 and Daily Pulse) and return structure (headline, core statement, link), which is valuable since no output schema is provided.

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

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

The description is a single, well-structured sentence that front-loads the key purpose and includes all necessary details without redundancy. Every phrase 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 no-parameter, read-only tool with strong annotations and a clear description of the return content, the description is fully complete. No output schema is needed because the description enumerates the expected fields.

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 is complete. The rubric assigns a baseline of 4 for zero-parameter tools, and the description appropriately focuses on output rather than parameters.

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

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

The description clearly states the tool returns Closelook's latest published market view, specifically today's Morning 10 and the latest Daily Pulse thesis, each with headline, core statement, and link. This is specific enough to distinguish it from siblings like get_index_snapshot or search_closelook.

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 makes it clear this tool is for retrieving the latest published market view, which implies when to use it. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for a read-only, parameterless 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 annotation set the read-only and non-destructive base, and the description adds real behavioral depth: data sources, number of FRED series, bucket organization, what the output contains, and update cadence. Nothing in the description contradicts 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?

Three dense but focused sentences carry the whole picture: what the tool is, what data it includes, and how current the data is. There is no padding or repetition of schema content.

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

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

For a tool with one documented optional parameter, one read-only annotation, and no output schema, the description provides enough context for an agent to understand the output shape selection and freshness expectations. The missing pieces are minor and are already covered by the schema.

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

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

The schema already explains the single optional parameter and its allowed values. The description reinforces the conceptual meaning by naming the two monitors being configured, but it does not add fully novel parameter detail beyond that baseline.

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

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

The description is specific about what the tool brings back and which data it combines: Structural Inflation and Growth & Recession monitors with scores, regimes, direction, recession risk, and z-scores. This clearly separates it from similar-sounding offerings like get_factor_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?

The intended use is strongly implied: this is the tool for the Closelook macro inflation and growth regime reads. However, it does not explicitly state when not to use it or point to sibling alternatives, so the agent must infer the routing from context.

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

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

Annotations already establish readOnly and non-destructive behavior. The description adds behaviorally relevant details beyond the annotations: the data is a daily scheduled board, updated at 22:30 UTC, and mirrors a known closelook.net URL. It does not need to warn about side effects because the annotations already declare none.

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 core content is packed into one readable sentence plus a short cadence note. Every clause conveys a useful reporting element, but the phrasing borders on promotional and repeats the idea of 'daily', so it is slightly less crisp than a minimal API-style 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, the description gives enough orientation: what the board contains, the benchmark universe, the source URL, and the update cadence. It does not fully define the shorthand like 'Mag names' or 'ORCL torque', but those are domain terms and the external mirror provides additional context.

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

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

The tool has zero parameters and 100% schema coverage applies trivially, so there is nothing for the description to explain. The baseline for a parameter-less tool applies, and the description contains no confusing parametric claims.

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 Mag Pulse as a specific daily board and lists its exact contents: hyperscaler cohort names, 1d/1w/1m/1y changes, benchmark tickers, MAGS trendline, and ORCL torque. This materially differentiates it from siblings like get_index_snapshot, get_tech_board, and get_wire.

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 implies when to use it: when an agent or user wants the Mag Pulse hyperscaler daily board, not a different market view. It also provides operational context with the daily 22:30 UTC cadence, though it does not explicitly name alternatives or state when-not-to-use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations: three years of daily closes, update cadence after the US close, and the mirror relationship to a webpage, which helps an agent reason about data freshness and coverage.

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

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

The description packs a lot of useful detail into a single substantive sentence, listing the asset universe, the computed metrics, the three-year daily-close window, and the update cadence. It is dense but not padded, and the most identifying information is front-loaded before the URL and update note.

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 board-instrument lookup with one optional parameter and no output schema, the description gives enough invocation information: what symbols are valid, what the response contains, the lookback window, and when it is updated. It could be more complete by explicitly distinguishing itself from comparable snapshot/board tools, but as a standalone reference it serves an agent well.

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%: the symbol parameter already includes the 'omit to list the board' behavior and example values such as N225.INDX, EURUSD, and BTC. The description reinforces the symbol space by listing real examples (S&P 500, Nikkei, EURUSD, gold, oil), but it doesn't add material semantic details beyond the schema, so the 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 identifies a specific verb+resource: get market board instruments, and enumerates the asset classes included (indices, FX pairs, crypto, futures proxies, US funds) and the metrics returned (last level, changes, 52-week range). It clearly describes the tool's focus on the homepage board, which helps separate it from related snapshot tools such as get_index_snapshot or get_stock_snapshot, though it never names a sibling explicitly.

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 context (homepage board, daily after US close, mirrors a URL) but never says when to choose this tool over its many siblings like get_index_snapshot, get_stock_snapshot, get_price_history, or get_tech_board. There is no when-to-use, when-not-to-use, or alternative routing, so an agent must infer the choice from the name and scope.

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 description appropriately adds non-safety context: the daily cadence, the mirror URL, and the exact scoring dimensions. It does not fully describe response structure, but for a read-only regime snapshot it is quite transparent.

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

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

The description is tight and front-loaded: it leads with the tool's identity, then enumerates the actual contents, then the cadence and reference. Every phrase carries meaningful information without bloating.

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 monitor, the description is complete: it tells the agent what the tool does, what data items appear, the scoring scales, the daily update rhythm, and a reference URL. There is no obvious missing need for invoking 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 schema coverage is perfect by default. The description adds meaning by defining what the returned temperature report contains, which is relevant even though it doesn't discuss parameters.

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

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

The description clearly identifies the resource (house money-regime monitor) and specifies its output: eight instruments scored 0–100 on Position/Momentum/Volume/Volatility/Fragility, technical state, and the absorption ratio. It is specific enough to distinguish this from most sibling tools, though it lacks an explicit imperative verb like 'returns'.

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: the description labels it 'the house money-regime monitor' and says it mirrors the daily lab page. However, it does not explicitly state when to choose this over siblings like get_macro_regime or get_factor_regime, nor any exclusions or 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 indicate readOnlyHint=true and destructiveHint=false, and the description adds non-annotated behavioral detail: the data is a weekly Friday-close snapshot, mirrors a particular public URL, and contains only free-tier information. It also clarifies that full composition and P&L are not included, helping the agent set expectations.

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

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

The description is well-structured and front-loaded with the core subject, followed by the returned fields and scope boundaries. It contains no filler, though the enumerated book list partly duplicates the schema and makes the first sentence slightly longer than necessary.

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 only one optional parameter and no output schema, the description is sufficiently complete: it states the source, update frequency, output fields, and the public/subscriber boundary. An agent can accurately decide whether this tool fits a request and what to expect in 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%, so the parameter's meaning is fully documented in the input schema. The description repeats the book list with human-readable names and implies omit-for-all behavior, but it does not meaningfully extend the semantic information already present in the schema.

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

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

The description clearly identifies the tool as retrieving Closelook's live reference portfolios (public snapshot) and specifies exactly what data is returned: snapshot date, position count, top-10 holdings, and headline return vs deposited capital. The list of included books and the distinction from subscriber-only content makes the purpose actionable and distinct from the sibling tools.

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

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

The description gives clear context for when to use this tool: to retrieve the public portfolio snapshot, exactly as shown on the free page and on closelook.net/portfolios/. It also clarifies what is excluded (subscriber-only composition, cost basis, P&L), though it does not explicitly name alternatives or contrast with sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value beyond annotations by specifying the exact data returned (latest close, changes over 1D/1W/1M/3M/6M/1Y, 52-week range, last ten sessions) and ticker format rules, which helps the agent anticipate behavior.

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

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

Two sentences, front-loaded with the core purpose, then specifics, then ticker format. No redundant words; every sentence adds essential information.

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

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

The tool has one parameter and no output schema, so the description carries the burden of explaining return values. It lists all key outputs, making the tool's behavior clear. Minor gaps such as error handling or limitations are acceptable given the simple scope.

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 lists 'ticker' with example values, and schema coverage is 100%. The description enhances this by explicitly stating the formatting rules (US tickers bare, foreign with exchange suffixes like 005930.KS, 6857.T, ASML.AS), providing deeper semantics beyond the schema.

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

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

The description clearly states the tool reads end-of-day price history for ~2,500 tickers from a data lake, listing specific outputs (latest close, period changes, 52-week range, last ten sessions). It distinguishes itself from siblings by focusing on individual tickers and historical price data, not indices or definitions.

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

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

The description provides clear context on when to use this tool (for price history of tickers) and the data it returns. However, it lacks explicit exclusion or alternative guidance (e.g., 'for index data, use get_index_snapshot'), so it falls short of a 5.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds valuable behavioral context: the tool only works for 'covered ticker', and the no-ticker call reveals current coverage and the forward calendar. It also explains the 'gap between beat-rates and reactions' as the product, which frames the output. 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 two sentences long, front-loaded with the core purpose ('Print Record for a covered ticker'). Every clause adds detail about the data returned or the no-ticker behavior. No extraneous words or repetition. It is dense but appropriately sized for the tool's complexity.

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 burden of explaining what is returned. It lists the key components (earnings prints, EPS/revenue beat, price reaction, headline counts, metric line, next scheduled print) and covers the coverage-list behavior. It does not specify exact formatting or edge cases (e.g., what if ticker not covered), but for a simple read-only lookup tool, it is sufficiently complete.

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

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

The schema description covers 100% of the parameter, including the example tickers and the omission behavior. The description reinforces 'Call without a ticker' but adds little beyond that. Baseline for high schema coverage is 3, and the description does not introduce new parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool provides 'Closelook's Print Record for a covered ticker' with specific components: last ~10 earnings prints, EPS/revenue beat-or-miss, 3-day price reaction, headline counts, metric line, and next scheduled print. This distinguishes it from sibling tools like get_price_history and get_signal_scores, which focus on different datasets. The verb 'get' and resource 'print record' are explicit 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 gives explicit usage guidance: 'Call without a ticker to see current coverage and the forward calendar.' This tells the agent how to invoke the tool in both modes. It does not name alternatives or exclusions, but the unique content (earnings print metrics) makes it clear when this tool is appropriate. A 5 would require explicit when-not-to-use guidance, which is absent.

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 provide readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds value by listing the three ranking families with detailed views (e.g., 'views: top, momentum' for flow families), almost 400 characters of extra detail that help the agent understand the scope of returned data. 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 moderately concise at about 500 characters, but the first two sentences could be restructured for clarity. The detailed list of families and views is front-loaded, which is good. Some punctuation and phrasing could be tighter, but overall it is acceptably 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 3 parameters, full schema coverage, readOnlyHint=true, and no output schema, the description adequately explains the families and their views. However, it does not describe the overall return format or behavior such as pagination or data freshness, which would be helpful. Still, for a read-only ranking retrieval tool, this is mostly sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds some semantic depth by explaining families and views (e.g., 'up-day beta vs down-day beta over 126 trading days'), but does not elaborate on the 'limit' parameter beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states 'Closelook’s other daily ranking families' and lists the available families (country-flow, sector-flow, etc.), conveying that this tool provides access to various ranking metrics. However, it lacks a specific verb like 'retrieve' or 'get', and the phrase 'Mirrors closelook.net/stocks/rankings/' is somewhat implicit. It distinguishes from sibling get_df_ranking by noting 'end-of-day' context.

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 identifies that this tool is for 'other' daily ranking families distinct from get_df_ranking, but it does not explicitly state when to use this tool versus siblings or when not to. It provides no guidance on prerequisites, context exclusions, or alternatives beyond the implied sibling differentiation.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the exact output contract: per-pair current ratio, 1y change, historical extremes with dates, percentile, distance from low, and lowest-since date. It also discloses the data granularity ('weekly since first common date'), so the agent knows both the safety profile and the observable behavior.

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

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

The description is dense but efficient: it leads with the core purpose, fully enumerates the ten pairs, then gives the return fields and periodicity. The pair enumeration is necessary because the pair list is the tool's core content, so the length is justified. It could trim some redundancy around 'mirrors...' but overall 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?

With no output schema, this description carries the full burden of explaining the result payload, and it does so thoroughly: exact pairs, exact metrics, date span, and periodicity. It even clarifies that the tool corresponds directly to a public page for cross-reference. An agent can correctly decide to call the tool and know what will come back.

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 the single parameter and all preset slugs at 100%, but the description adds human-readable meaning to those slugs (e.g., India vs US, EM vs US, gold vs US equities). It also confirms that omitting the parameter returns all presets, which is reinforced by the schema. This is meaningful value on top of an already well-covered schema.

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

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

The description opens with a specific resource — 'Ratio Chart presets' — and defines exactly what it returns: relative-performance facts for ten named instrument pairs. It lists the exact output fields (current ratio, 1y change, all-time low/high, percentile, etc.), making the tool's function unmistakable and clearly distinct from sibling listing/ranking tools.

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

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

The description clearly establishes that this tool is for preset ratio pairs only, not arbitrary pairs, and tells the user which pairs are covered. It does not explicitly name a sibling tool as the alternative for non-preset pairs, but it points to the website mirror for any-pair charting, which gives solid context about the tool's limited scope.

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 the tool read-only and non-destructive. The description adds meaningful behavioral context: output comes via ETF vehicles, EM is approximated from country funds, and the matrix mirrors a known website page. This gives an agent useful modeling limitations beyond 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 compact and front-loaded with the core output, followed by method, caveat, and update cadence. Each sentence contributes useful information, though the phrase 'The decomposition institutions see' is slightly stylistic rather than purely functional.

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 a reasonably good job clarifying what will be returned: sector returns per region, plus leaders and laggards. It also notes the EM approximation and cadence. It could mention exact output formatting or whether all regions are returned by default, but the essentials are covered.

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

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

Both parameters already have descriptions against schema enums, so schema coverage is 100%. The description restates the regions and windows but adds little semantic depth beyond what the schema provides. A baseline score of 3 is appropriate.

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

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

The description states a specific output: an 11 GICS sector × 4 region return matrix with leaders and laggards, which is concrete and distinguishable from generic market tools. It does not explicitly position itself against siblings such as compare_indices or get_index_snapshot, but the resource and scope are clear.

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

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

The description provides clear usage context: use it to see sector performance across US, Europe, Asia-Pacific DM, and EM over a selected window. It adds refresh timing ('Daily after each regional close') but does not explicitly discuss when not to use it or which sibling tool to choose 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 indicate readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context: the data is end-of-day, scoring uses sector-appropriate weights, and coverage is limited to ~300 names. 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?

Two concise sentences with no filler. The first sentence efficiently packs the tool's output components; the second notes end-of-day timing. Every clause adds value.

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

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

For a tool with no output schema, the description does well to enumerate the returned components (composite rank, seven sub-scores, ratios). It could mention behavior for uncovered tickers or score interpretation, but the provided information is largely sufficient for an agent to understand the tool's scope.

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 describes the ticker parameter with a clear example (DDOG), and coverage is 100%. The description adds the context that the ticker must be among ~300 covered names, but it doesn't elaborate on parameter format or constraints beyond the schema's example. Baseline 3 is appropriate.

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

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

The description clearly states the tool provides per-ticker scoring for ~300 covered names, listing the composite rank, seven sub-scores, and literature ratios. This specific verb+resource (get scores) distinguishes it from sibling tools like get_price_history or compare_indices.

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 context makes it clear this is for retrieving Closelook's proprietary scoring for a single ticker, but it does not explicitly state when to use it versus alternatives or mention limiting conditions like coverage scope. The covered-names limitation is implied, though not framed as a usage guideline.

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 description does not need to restate that it is a safe read operation. It adds useful context beyond those annotations: the tool aggregates G7 yields in two weighting styles, includes a z-scored index with a defined interpretation, mirrors a public page, and updates daily. This gives the agent meaningful expectations about what the snapshot represents.

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

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

The description is dense but front-loads the resource name and uses a structured list to convey many data components without fluff. The two-sentence layout keeps the source URL and frequency in a short fresh sentence. It is appropriately sized for a no-argument read-only dashboard, although the single long first sentence is somewhat crowded.

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 zero parameters and no output schema, the description must carry the burden of explaining what the agent will receive, and it largely does: it lists countries, maturities, weighting methods, slopes, change windows, and the Pressure Index interpretation. The main omission is a clear statement of the return structure or format beyond the board-mirroring language, but the described fields are sufficiently detailed for an agent to know what the tool provides.

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

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

The input schema has zero parameters and 100% schema description coverage, so there is no parameter surface requiring compensation. The baseline of 4 applies because no parameter-specific burden exists. The description also adds overall context about the board's composition, even though it does not need to define inputs.

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

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

The description clearly identifies the resource as the G7 Sovereign Pressure board and enumerates the exact data it provides: equal- and debt-weighted yields, slopes, per-country maturities, changes, and the z-scored Pressure Index. It distinguishes itself from siblings like get_credit_stress or get_macro_regime by focusing specifically on sovereign yield pressure. It lacks an explicit operation verb such as 'returns' or 'lists', but the resource and content are unambiguous.

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

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

There is no explicit guidance on when to choose this tool versus alternatives such as get_credit_stress, get_factor_regime, or get_macro_regime. The mention that it mirrors a website and updates daily provides only implicit context, not decision rules. An agent is left to infer its applicability from the content.

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 valuable behavioral context beyond annotations by specifying the data is end-of-day and enumerating the exact metrics returned (trend scores, beta, structural state, index memberships), which helps the agent understand output nature.

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

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

Two concise sentences: the first packs the tool's purpose and output details, the second provides integration guidance. No redundant or filler content.

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

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

Given one parameter, existing annotations, and no output schema, the description fully enumerates the return fields (trend scores, beta, structural state, index memberships), mentions frequency (end-of-day), and suggests companion tools. This is complete for the tool's complexity.

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

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

Schema covers 100% of the single parameter (ticker) with example values. The description adds no additional parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves a snapshot of a stock's directional flow trend scores, beta, structural state, and index memberships. It uses specific resource language ('One covered stock') and distinguishes from siblings by recommending companion tools for price bars and signal scores.

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 suggests pairing with get_price_history and get_signal_scores for complementary data, providing clear context for when to use this tool in combination. However, it does not include explicit exclusions or when-not-to-use guidance.

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

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

The description adds meaningful behavioral context beyond the annotations: 'timestamped, deterministic', 'newest first, each with headline, excerpt and body', and 'Mon-Fri live; fully automated surface (disclosed as such)'. Since annotations already carry read-only/safety information, this go-between effort is sufficient and adds useful expectations.

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

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

The description is dense and front-loaded, leading with 'Tape' and 'timestamped, deterministic market cards', then a compact list of card types. Every phrase carries useful information, and the assertion that it mirrors a public webpage is action-relevant.

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 covers return shape enough: each card has a headline, excerpt, and body, and they are presented newest first. It also explains availability (Mon-Fri) and automation. It could more explicitly address offline behavior or weekend behavior, but overall the context is strong for a 3-parameter read-only tool.

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

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

The input schema already covers all three parameters at 100%, so the description does not need to enumerate them. It does loosely mirror the type/window values via the card-category list, but it adds no explicit parameter examples or value mappings. Baseline 3 is appropriate given full schema coverage.

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

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

The description names a specific resource and verb ('Closelook's Tape') and enumerates distinctive content categories: session wraps, macro prints, earnings reactions, outliers, PEAD signals, and weekly recaps. It explicitly mirrors closelook.net/tape/, making its purpose unmistakable and differentiating it from sibling tools like get_wire or get_latest_view.

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 implies when to use this tool: to retrieve the latest timestamped market cards from the Tape. It also adds cadence ('Mon–Fri live; fully automated surface') which helps an agent know the tool's temporal relevance. It does not explicitly name alternatives or provide 'use X instead' guidance, so it falls just short of a 5.

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

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

With annotations already declaring the tool safe and read-only, the description adds useful behavioral context: the board is refreshed after each close, each card has its own session and as-of date, and an archive exists. This goes beyond the structured metadata without contradicting it.

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

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

The description is compact and front-loaded. It opens with the board's core purpose, then adds useful details on data scope, freshness, and archive location without wasting words.

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

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

The description is sufficiently complete for a read-only, optional-parameter board tool. It explains what the board contains, how recent the data is, and where the archive lives. Slightly more detail about the response structure or ranking criteria would make it stronger, but it is not blocking.

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 has complete descriptions for both parameters, including limit range, default, and region examples. The tool description does not add much parameter-level meaning, so the schema carrying the load is fine at baseline.

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

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

The description clearly identifies the resource as a Tech Signal Board and explains what it contains: ranked global tech signals, new highs, big moves, sector rotation, and geographic coverage. It is specific and useful, but it does not explicitly differentiate the tool from sibling tools such as get_ranking or get_signal_scores.

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 this tool is for current, curated tech signals rather than historical or raw data, and it mentions the dated archive location. However, it never explicitly states when to prefer this tool over its siblings or when not to use it.

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

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

Beyond the safe read-only hints already present in annotations, the description adds useful behavioral detail: newest-first ordering, per-day archives, mirrored URLs, and refresh cadence several times per trading day. This helps the agent understand currency and scope without overclaiming.

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 moderately sized but every sentence adds value: it introduces the two modes, explains each mode's content, provides source URLs, and mentions refresh behavior. It is well organized and front-loads the central wire concept.

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?

Even without an output schema, the description conveys the return content in enough detail: rows, ordering, extras like house read and consensus comparisons, the forward calendar, and archive access. An agent has sufficient information to select and invoke it successfully.

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 schema descriptions are already complete, and the tool description adds meaningful semantics for the wire parameter by explaining exactly what each enum value returns. Limit and ticker are already well covered by the schema, so nothing critical is missing.

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

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

The description names a specific resource (the two Closelook wires), assigns concrete meanings to each wire value, and distinguishes the two modes. It goes well beyond the tool name and title, so an agent knows exactly what this tool returns.

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 use context: wire=analyst returns sell-side calls and wire=earnings returns earnings prints, both newest-first. It does not name sibling tools that might overlap, but the wire/value explanation is strong enough to guide selection.

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

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

Annotations already indicate read-only and non-destructive; description adds the specific return format (one-line summary and link) and scope of the corpus, providing useful behavioral context beyond 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?

Single sentence with clear structure, listing content types and usage guidance without redundancy.

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

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

For a simple search tool with two parameters and no output schema, the description covers purpose, return format, and scope, making it adequately complete.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds the use case but no additional parameter semantics beyond what schema provides.

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 searches Closelook's research corpus, enumerates content types, and mentions returns with summary and link, distinguishing it from sibling tools like define_term.

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 'Use for "what has Closelook written about X"' providing clear usage context, but does not explicitly mention when not to use it or alternatives.

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