DeltaSignal ATLAS-7

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explicitly stating it performs one HTTPS read, has no destructive side effects, and is idempotent, confirming 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?

Two well-structured sentences. First sentence states core purpose and returned fields. Second sentence covers parameters, behavior, and usage recommendation. No redundant 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 4 optional parameters and an output schema, the description covers purpose, usage context, parameter semantics, and behavioral notes. It is fully sufficient for an agent to decide when and how to invoke 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?

Schema coverage is 100%, but the description adds practical guidance: suggests limit values for summaries vs. full screening, explains source_date as replaying a slice, and defines acceptable values for risk_tier and debt_coverage_status.

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

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

The description clearly states it is a read-only screening tool to rank issuers by Phase 1 alpha score. It differentiates from the sibling tool deltasignal_alpha_signals by specifying it is for multi-issuer screening before using single-issuer signals.

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

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

Explicitly says to use this before single-issuer alpha_signals when the user asks what names screen best right now. It also lists what it does not handle (wallets, payments, orders, account state), providing clear usage boundaries.

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

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral details: performs one HTTPS read, no destructive side effects, does not change board scoring, payments, wallets, files, or account state. No contradiction.

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?

Description is concise at about 8 sentences, front-loaded with purpose, and structured with parameter details and usage guidance. No redundant information.

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

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

Given 4 parameters and an output schema (not shown), the description fully covers purpose, behavior, parameter details, and usage scenarios. It is comprehensive 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 coverage is 100% with descriptions. The description adds semantic context beyond schema: e.g., limit is 1-100 for bounded samples, source_date replays a known slice, issuer_type narrows audit, include_rows should be used only for explicit debugging.

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

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

The description clearly states it is a read-only diagnostic tool to explain why the alpha-opportunity board includes, excludes, or demotes rows. It specifies the return summaries and distinguishes from sibling tools like deltasignal_alpha_opportunities and deltasignal_alpha_sweep.

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

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

Explicitly provides when to use: after deltasignal_alpha_opportunities or deltasignal_alpha_sweep when the user asks about missing rows, exclusions, demotions, or safety of summarizing. Also gives example scenarios.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety is clear. The description adds context about the types of signals returned, but does not disclose additional behavioral traits 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 a single sentence that is clear, front-loaded, and contains no unnecessary words. Every part is 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?

Given the presence of an output schema (not shown) and comprehensive annotations, the description is fairly complete. It lists the types of indicators, which is useful context. Minor missing elements like prerequisites or pagination details are not critical for a 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?

Schema description coverage is 100%, with both parameters having descriptions. The tool description adds minimal extra meaning beyond the schema, mentioning 'one crypto public company ticker' which aligns with the ticker param, but does not enhance parameter understanding significantly.

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

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

The description explicitly states the tool returns high-conviction alpha and edge signals for one crypto public company ticker, listing specific indicators (resilience, treasury, regime-fit, phase-one opportunity). This clearly distinguishes it from sibling tools like deltasignal_company_fundamentals or deltasignal_risk_distribution.

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 provide guidance on when to use this tool over alternatives, nor does it mention when not to use it. No comparisons or usage context are given.

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, idempotent, non-destructive. The description adds critical behavioral details: three internal HTTPS reads, no issuer-level tool calls, and partial result preservation on failure. 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 a single dense paragraph but every sentence adds value: purpose, internal behavior, usage guidelines, and parameter restrictions. No fluff, well front-loaded with the main action.

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

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

Given the tool has one optional parameter, full annotations, and an output schema (not shown but indicated), the description covers purpose, behavior, error handling, and usage context comprehensively. It is complete for an agent to select and invoke correctly.

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

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

The input schema has one optional parameter 'output_mode' with basic description. The description clarifies that only 'compact' is allowed and forbids other parameters like limit, offset, ticker, source_date, and issuer filters because they are internally preset. This adds meaningful guidance beyond the schema.

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

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

The description states it is a read-only composite workflow for opportunity and alpha screening, detailing the internal call plan (readiness, alpha_opportunities, daily_changes) and defaults. This clearly identifies the tool's purpose and distinguishes it from siblings like deltasignal_alpha_opportunities.

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 lists user intents that trigger this tool: 'alpha opportunities, opportunity sweep, clean alpha board, or names worth follow-up research.' It also instructs treating the result as a screen for further drilldown. While it does not explicitly state when not to use it or name alternative tools, the context is sufficient for typical usage.

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

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. The description reinforces these and adds specific context: no destructive side effects, does not run the audit, mutate data, or access raw issuer evidence. This adds value 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?

The description is a single well-structured paragraph, front-loaded with the main purpose. It is concise but thorough, using each sentence to add essential information 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?

Given the presence of an output schema (so return values are covered there) and rich annotations, the description fully covers purpose, usage, and behavioral traits. No gaps remain for this simple parameterless 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?

Input schema has no parameters, and description explicitly states 'Parameters: none.' With 0 parameters, the baseline is 4, and the description adds no extra param detail but is clear about absence.

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 checks ATLAS-7 audit health, reads the latest audit summary from Azure Blob, and lists the reported fields. It distinguishes itself from sibling tools by being a read-only status check rather than running the audit or accessing raw data.

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

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

Explicitly states when to use it: 'Use this before trusting historical ATLAS-7 surfaces' and 'when an operator asks whether the nightly audit is current.' Also clarifies it does not run the audit or mutate data, providing clear usage boundaries.

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

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

Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds that it assembles from precomputed surfaces and performs no wallet/settlement/trading actions. This provides useful behavioral context 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?

Every sentence in the description serves a purpose: purpose, component list, parameter summary, behavioral note, and usage hint. It is front-loaded with the most important information and contains no filler.

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

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

The description covers purpose, usage, parameters, and behavior. With an output schema present, it doesn't need to detail return structure. It could mention pagination more explicitly, but the parameter descriptions handle 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?

Schema coverage is 100% with good descriptions. The tool description adds value by explaining how parameters work together (e.g., source_date replays a slice, range for paging, ticker/CIK narrowing, mode behavior). This enhances understanding beyond individual schema descriptions.

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

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

The description clearly states the tool returns the complete ATLAS-7 calculation bundle for an issuer and source_date, and lists the components. It differentiates itself from sibling tools like deltasignal_atlas7_companyfacts_history and deltasignal_atlas7_point_in_time_history by focusing on the full bundle.

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

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

The description explicitly says to use this tool when needing the complete calculation bundle for historical report rendering, and warns against mixing latest-only fields. It provides context but does not list alternatives or when not to use, though that's partially mitigated by sibling names.

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?

Description adds value beyond annotations by stating 'it performs no writes, has no destructive side effects, and never returns the raw facts_payload' and advises how to drill down. This aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) and provides actionable guidance.

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?

Description is concise (4 sentences), front-loaded with purpose, then details, then parameter info, then behavioral notes. Every sentence adds value with no redundancy.

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

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

Given output schema exists, description does not need to explain return values. It covers key behaviors, parameter usage, universe size, and drill-down guidance. Complete for a retrieval tool with rich 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?

Schema coverage is 100%, so baseline is 3. Description adds context by listing parameters like source_date, ticker/cik, limit, offset with defaults and behavior (e.g., 'limit defaults to 25 and is capped at 250'), enhancing usability beyond schema descriptions.

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

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

Description clearly states verb 'retrieve', resource 'compact SEC CompanyFacts/XBRL materialization rows', and scope 'crypto public-company universe or a specific ticker/CIK'. It distinguishes from siblings by specifying usage for 'Mirror Pulse or ATLAS-7 historical joins' and mentions '215 crypto companies'.

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?

Description provides explicit usage context: 'Use this for Mirror Pulse or ATLAS-7 historical joins when you need the compact issuer-level CompanyFacts inventory'. It does not explicitly mention when not to use or name alternative tools, but the context is clear enough for 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: it performs one HTTPS read, no NLP, no trades/wallets/settlements. This additional detail enhances transparency 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 a single paragraph of five sentences, front-loaded with purpose and usage. Every sentence adds necessary detail without redundancy. It is efficient and well-structured for an AI agent to parse.

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

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

Given the high parameter count (8), optional params, and existence of output schema, the description is quite complete. It covers purpose, usage context, mode selection, and safety. It does not detail output semantics, but that is covered by the output schema. Minor gaps: exact pagination limits are in schema but not repeated, and difference from sibling companyfacts_history tool is implicit but clear.

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 baseline is 3. The description restates parameters and adds usage advice for mode (compact vs full), but does not significantly augment the meaning beyond what the schema provides. The added guidance on mode selection earns it a 3 rather than a 2.

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 is for retrieving daily ATLAS-7 CompanyFacts-derived factor rows keyed by as_of_date, with emphasis on point-in-time safety and lookahead flags. It distinguishes itself from siblings by being a structured history tool specific to factor rows, and the read-only nature is explicit.

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 specifies exactly when to use this tool: for Mirror Pulse, backtests, or agents needing daily ATLAS-7 factor history. It provides mode recommendations (compact by default, full for audit pages). However, it does not explicitly mention alternatives or when not to use it, though the context of siblings makes the differentiation clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds operational details: 'it performs one HTTPS read, has no destructive side effects, and does not apply the latest ATLAS snapshot retroactively across history.' This adds value beyond the annotations without contradiction.

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 paragraph that efficiently communicates purpose, parameters, and behavior. It is front-loaded with the main action. While compact, it includes necessary detail 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?

Given the output schema exists (not shown but indicated), the description still lists return fields: 'debt, crypto fair value, BTC holdings, stress, risk tier, live-price fields, quality flags, and provenance.' This covers the context needed for an agent to understand the tool's output. The description 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?

The input schema has 100% coverage, but the description adds context by summarizing parameters and stating defaults and caps: 'ticker is required; source_date_from and source_date_to bound the inclusive ATLAS source-date range; limit defaults to 500 and is capped at 2000; offset paginates the dated series.' This goes beyond the schema's individual descriptions.

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

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

The description clearly states the tool retrieves 'historical ATLAS-7 covenant and stress series for one crypto public company ticker', using specific verbs and resources. It distinguishes from siblings by mentioning unique use cases like mNAV backtests and Mirror Pulse joins, which are not covered by similarly named tools such as deltasignal_atlas7_point_in_time_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 provides explicit use cases: 'when the user needs historical ATLAS data, MSTR/Strategy time series, mNAV backtests, Mirror Pulse joins, or dated stress/risk snapshots.' It does not explicitly mention when not to use or name alternative tools, but the context is clear enough for an agent to decide.

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, idempotentHint=true, and destructiveHint=false. The description adds value by revealing that the data is SEC XBRL-backed and that segment and related-party facts are optional, providing context 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 20-word sentence that conveys the core functionality and optional enhancements without redundancy. Every word serves a purpose, making it highly concise and well-structured.

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

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

Given the existence of an output schema and strong annotations, the description covers the main purpose, data source, and optional parameters. It lacks details on data coverage or period handling, but for a fundamentals tool with rich schema, it is complete enough.

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 input schema documents all parameters adequately. The description adds minimal extra meaning by describing the optional facts as 'deeper financial diligence', but this is not essential. 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 returns SEC XBRL-backed company fundamentals for one ticker, with optional segment and related-party facts. The verb 'Returns' and resource 'company fundamentals' are specific and make it distinguishable from sibling tools like deltasignal_alpha_signals or deltasignal_covenant_stress.

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

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

The description implies usage for financial diligence but does not explicitly state when to use this tool versus siblings or provide exclusions. No alternative tools are named, and the context for choosing this over other data tools is not given, leaving the agent to infer based on tool names alone.

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, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details: performs five internal HTTPS reads, rejects invalid tickers before fan-out, preserves partial results on leg failure, and normalizes ticker to uppercase. This goes well 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?

Well-structured: purpose first, then parameter summary, behavior, usage guidance. Every sentence adds value. Slightly long but appropriate for a composite tool.

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

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

Highly complete given complexity: covers purpose, parameters, behavior, error handling, and usage guidance. Output schema exists, so return values are covered. No omissions.

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%, baseline 3. The description adds context: ticker normalization, period format, output_mode restriction to compact, and booleans for segments/related party. This enriches schema meaning.

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

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

The description clearly identifies it as a read-only composite workflow for the DeltaSignal ATLAS-7 company report, listing the specific legs (readiness, company_fundamentals, alpha_signals, peer_ranking, covenant_stress). It distinguishes from siblings by stating 'Use it when the user asks for a report, deep dive, issuer brief, or diligence package' and contrasting with low-level tools for custom drilldowns.

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

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

Explicitly provides when to use (user asks for report, deep dive, etc.) and when not ('use low-level tools only for custom drilldowns'). Also notes that SPECTRA is intentionally excluded from Phase 1, preventing misuse.

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, idempotentHint=true, destructiveHint=false, which are consistent with the description's 'fetches' action. The description adds no additional behavioral context beyond what annotations provide, such as rate limits or side effects, but does not contradict 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?

The description is a single, well-structured sentence that immediately conveys the tool's purpose and capabilities. Every clause is meaningful, and there is no unnecessary information.

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

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

Given the tool's complexity (10 parameters, two modes) and the presence of an output schema, the description is complete. It covers the two primary use cases (ticker detail and universe screening) and the available filters, enabling an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds value by grouping parameters into two modes and explaining their filtering purpose (e.g., 'risk tier, quality flags, debt coverage status, linkbase-backed rows, and minimum stress score'). This contextualizes the parameters beyond their individual schema descriptions.

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

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

The description clearly states it fetches ATLAS-7 covenant stress for a single ticker or screens the issuer universe with filters. The verb 'fetches' and resource 'covenant stress' are specific, and it distinguishes between two modes, differentiating it from sibling tools like 'deltasignal_top_stressed' or 'deltasignal_risk_distribution'.

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 outlines usage in two modes: single ticker detail with an optional period, and list mode with multiple filters (risk tier, quality flags, etc.). This provides clear guidance on when to use each mode, though it does not explicitly state when not to use the tool or mention alternative tools for similar tasks.

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, idempotentHint, destructiveHint. The description adds valuable context: 'read-only and idempotent; it performs one HTTPS read... has no destructive side effects, and never infers covenant breach, default risk, insolvency, liquidity crisis, or trade direction unless returned by evidence.' This goes 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?

The description is a single dense paragraph that front-loads purpose. Every sentence serves a purpose; it is not overly long. Some structuring could improve readability, but it is concise enough for the 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 the annotations cover safety, an output schema exists (not detailed here), and parameters are documented, the description is largely complete. It covers purpose, usage, behavior, and parameter mapping. It does not detail output format, but that is handled by the output schema.

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

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

Schema coverage is 100% with descriptions for each parameter. The description mentions parameters (ticker required, date optional, style options) but adds only marginal value, such as explaining style affects tone/density. 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 explicitly states it is a 'premium read-only Natural Language tool' for 'ticker-specific covenant stress evidence explained in human-readable Markdown.' It specifies the data sources (ATLAS-7 covenant, leverage, etc.) and differentiates from sibling tools like 'deltasignal_covenant_stress' which likely returns structured data.

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 says 'Use this premium read-only Natural Language tool when the user wants ticker-specific covenant stress evidence explained in human-readable Markdown.' It implies alternatives exist (e.g., structured data tools) but does not explicitly state when not to use or provide exclusions. The sibling list provides context for 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?

Annotations already indicate readOnlyHint, idempotentHint, and no destructive effects. The description adds value by stating it performs 'one internal daily-changes read, filters evidence for one issuer/change, and has no destructive side effects.' No contradiction.

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

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

The description is four sentences, front-loaded with purpose and usage, then parameters, then behavior. Every sentence provides essential information without fluff.

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

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

Given the presence of an output schema and rich annotations, the description covers all necessary aspects: purpose, usage constraints, parameter behavior, and side-effect profile. It 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 description coverage is 100%. The description reiterates key details: ticker or cik required, source_date optional, limit defaults to 100 and capped at 250, offset for pagination. This adds practical context 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 is a 'read-only drilldown tool' for explaining why an issuer or CIK was flagged in daily changes. It distinguishes from sibling tools like deltasignal_daily_changes and explicitly defines its narrow scope.

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

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

Explicitly states 'only when the user asks why one issuer or CIK was flagged in daily changes' and warns against using for 'routine monitoring, Morning Brief, or Alpha Sweep unless the user explicitly asks for proof.' This provides clear when-to-use and when-not-to 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, idempotentHint=true, destructiveHint=false, so the description's burden is lower. The description adds context about the content of the snapshot (SEC/XBRL changes, issuer movements) but no additional behavioral traits beyond what annotations provide. No contradiction.

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?

A single, well-structured sentence that front-loads the core function. Every word adds value, and there is no redundancy or unnecessary information.

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

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

Given no parameters, clear purpose, and the presence of an output schema, the description provides sufficient context for an agent to understand the tool's role. It specifies the type of updates and targets monitoring workflows, making it complete enough for effective use.

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 no parameters, so the baseline score is 4. Schema coverage is 100% by default. 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 clearly states the tool returns a daily snapshot of changes, highlighting SEC/XBRL-driven changes, issuer movements, and fresh updates. It uses a specific verb-resource pair ('Returns... snapshot') and provides enough context for its purpose, though it doesn't explicitly distinguish from sibling tools like deltasignal_alpha_signals.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies use for monitoring workflows but doesn't mention exclusions or situations where siblings would be more appropriate. For a tool with zero parameters, usage is straightforward, but guidelines are minimal.

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, idempotentHint, and destructiveHint. The description adds valuable context: it is server-enforced, idempotent, read-only, has bounded internal fan-out, preserves partial failures, and explicitly reports missing evidence instead of inventing facts. This exceeds 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 a single paragraph of about 150 words. It front-loads purpose and use case. Every sentence adds value, though it could be slightly more concise. Still, it is well-structured and informative.

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, the description covers purpose, usage, behavioral transparency, parameter semantics, and what the report will contain (causality, filing evidence, changes, peer context, historical stress path, missing sections). The presence of an output schema (not shown) reduces the burden, but the 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?

All 7 parameters have schema descriptions (100% coverage). The description adds practical usage details: ticker is normalized to uppercase, output_mode=compact is the only accepted mode in Phase 1, and date parameters are 'reproduction controls.' This adds meaning beyond the schema.

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

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

The description clearly states the tool as a 'read-only composite workflow tool for a paid filing-backed issuer drilldown' and specifies it is used when a daily brief row 'needs causality, not just a headline score.' This distinguishes it from simpler tools like deltasignal_morning_brief. The listing of evidence plans further clarifies its comprehensive scope.

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

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

The description explicitly states when to use: 'when a daily brief pressure or opportunity row needs causality' and implies when not to use (when only a headline score is needed). It does not name sibling tools explicitly but provides sufficient context for the agent to differentiate.

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?

Adds significant behavioral context beyond annotations: 'performs six internal HTTPS reads, has no destructive side effects, never calls issuer-level tools, and preserves partial results if one required internal call fails.' This fully informs the agent of safety and resilience.

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

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

Every sentence is meaningful and well-structured. The description leads with purpose, then lists internals, then parameter rules, then behavior, then usage guidance. No redundancy and efficiently packed with information.

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

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

Given the presence of an output schema (not shown but indicated), the description covers all necessary aspects: purpose, usage, parameter constraints, behavioral traits, and clear differentiation from siblings. It is complete for a composite workflow 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?

Schema coverage is 100% for the single parameter. The description adds that 'output_mode=compact only' and warns against passing other parameters because the preset owns arguments internally. This provides critical usage constraints not 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 states it is a 'read-only composite workflow tool' for a 'morning brief daily scan', listing the internal calls it makes (readiness, daily_changes, etc.). This distinguishes it from sibling tools which are individual low-level 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?

Explicitly says 'Use this ... as the default first-pass' and lists use cases (morning brief, daily brief, daily scan, etc.) and when to use low-level tools ('only when the user explicitly asks for a custom drilldown').

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, idempotentHint, destructiveHint. The description adds that it is server-enforced, has no side effects, and renders bounded responses. It also states no fan-out into other tools, which is valuable 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?

The description is concise at ~80 words, front-loading purpose. It covers all key aspects in a single paragraph, though could be slightly more structured with bullet points or separate sentences 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?

Given 3 optional parameters, strong annotations, and an output schema, the description is comprehensive. It explains behavior, parameter conditions, and differentiators from other tools, leaving no critical gaps for an agent to understand invocation.

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

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

Schema description coverage is 100%. The description reinforces parameter meaning (style affects tone/density only, date/limit conditionally accepted), adding context not fully captured in schema descriptions.

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

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

The description clearly states the tool renders the server-composed Morning Brief as audit-grade Markdown. It identifies the specific resource (Morning Brief), the verb (render as Natural Language), and distinguishes from siblings by noting it never fans out into tools or generates social drafts/trade recommendations.

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

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

The description explicitly says when to use: when the user wants the Morning Brief in Natural Language. It implies when not to use (e.g., for structured data, use deltasignal_morning_brief), but does not name alternatives explicitly. Parameter usage caveats are given.

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 and idempotentHint, so the description adds value by detailing outputs (ranking, percentile, signals) but does not disclose additional behavioral traits like side effects or authorization needs beyond what 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?

Single sentence of ~20 words, directly stating action and outputs. No redundancy or wasted words; front-loaded with key information.

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

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

Given that an output schema exists, the description adequately outlines tool purpose and returns. However, it does not explain what 'covenant stress ranking' or 'percentile context' mean, which might require agent inference. Still, sufficient for most contexts.

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?

Input schema has 100% description coverage, with clear definitions for 'ticker' and 'period'. The description adds no extra parameter-level meaning beyond what the schema provides, so 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 clearly states the tool compares a crypto public company against its peer group, specifying the outputs: relative covenant stress ranking, percentile context, and peer-comparison signals. It distinguishes from sibling tools like deltasignal_covenant_stress and deltasignal_top_stressed by focusing on peer 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 use for issuer research needing peer comparison but does not explicitly state when to use this tool versus alternatives (e.g., deltasignal_covenant_stress). No exclusionary or contextual guidance is provided.

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 significant behavioral context beyond the annotations: it performs three internal HTTPS reads, has no destructive side effects, never calls issuer-level tools, and preserves partial results on failure. This is fully aligned with the annotations (readOnlyHint, idempotentHint, destructiveHint) and provides valuable transparency.

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

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

The description is concise and front-loaded with the purpose. It contains all necessary information in a coherent paragraph. Slightly verbose but 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?

Given the tool's complexity (composite workflow, one parameter, output schema), the description is complete. It explains the internal calls, parameter constraints, behavior, and use cases, leaving no gaps for an agent to misinterpret.

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 baseline is 3. The description only confirms that output_mode=compact is accepted, which is already stated in the schema's description. No additional parameter meaning is provided 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 is for risk and stress monitoring across the current DeltaSignal issuer universe. It specifies the verb 'monitoring' and resource 'issuer universe', lists the three internal calls (readiness, top_stressed, risk_distribution), and distinguishes it from siblings by explicitly forbidding certain parameters.

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 lists when to use this tool: 'when the user asks for risk monitoring, pressure board, stress board, top stressed overview, or current risk mix.' It also provides exclusions on parameters. However, it does not explicitly compare to sibling tools like deltasignal_top_stressed or deltasignal_readiness, which are individual components.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specific behavioral details: removes internal identifiers, preserves non-advice language, returns deterministic HTML plus copy_text, which further clarifies side-effect-free and safe usage.

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?

Description is well-organized with clear sections for purpose, parameters, behavior, usage. While slightly wordy, every sentence adds value; could be trimmed slightly but remains effective.

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 presence of an output schema (context: true), the description covers all needed context: purpose, usage constraints, parameter guidance, behavioral details, and idempotency. It is complete for a tool with a single optional parameter.

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

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

Schema covers the single optional parameter output_mode with description. Description adds critical constraint that only 'compact' is accepted, which is not in the schema, and warns against passing other 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 this is a read-only composite renderer for customer-facing DeltaSignal Daily Brief artifacts, distinguishing it by specifying it produces public-safe HTML and copy-text and does not accept common filter parameters unlike 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?

Explicitly tells when to use: when the user asks for a public daily brief, customer-facing daily brief, investor-ready risk scan, or copy-ready article. Also lists parameters not to pass, providing clear usage boundaries.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool performs three internal HTTPS reads, rejects invalid tickers before fan-out, preserves partial results, and has no side effects, providing valuable behavioral context 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 well-structured with a clear opening statement, followed by behavioral details and parameter notes. It is slightly long but every sentence adds value; the information is front-loaded and easy to parse.

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

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

The description covers purpose, use case, behavior, parameter handling, and excluded features. Given the presence of annotations and output schema, it provides all necessary context for correct tool selection and invocation.

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

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

Input schema has 100% description coverage. The description adds that ticker is normalized to uppercase and that output_mode only accepts 'compact'. It also notes whitespace trimming and normalization, which enhances understanding 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 specifies a 'fast single-ticker sanity check' that evaluates readiness, covenant_stress, and alpha_signals. It clearly distinguishes this tool from sibling tools like deltasignal_company_report and deltasignal_peer_ranking, stating what is intentionally excluded.

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

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

The description states when to use this tool: for a quick sanity check without the full company-report payload. It also provides explicit use cases ('when the user asks whether one ticker is clean, stressed, actionable, or needs deeper diligence') and mentions excluded features.

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 declare the tool read-only and idempotent. The description adds specific details about what is checked, providing behavioral context 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?

The description is a single sentence that conveys all necessary information without extra words. It is well-structured and front-loaded with the main action.

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

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

Given the tool has no parameters and the description covers the key checks, it is complete for a readiness assessment tool. The output schema likely handles return values, so no further description needed.

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

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

With zero parameters, the baseline is 4. The description explains the purpose effectively, so no additional parameter information is needed.

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

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

The description clearly states it checks the live ATLAS-7 data plane before analysis, specifying four distinct aspects (service readiness, data freshness, issuer coverage, safety to query). This distinguishes it from sibling tools that perform other analyses.

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

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

The description explicitly says 'before analysis', indicating the tool is a prerequisite for other operations. While it doesn't list alternatives, the context of usage is clear and helpful for selecting 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no further behavioral details. The description explains what the tool summarizes but doesn't mention performance, pagination, or any hidden side effects. Given good annotation coverage, a score of 3 is appropriate.

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?

A single, front-loaded sentence that conveys purpose and usage context efficiently with no wasted words.

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

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

For a zero-parameter tool with an output schema (context signal indicates output schema exists), the description adequately covers the tool's function and typical use case. No additional details are necessary.

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, so baseline is 4 per guidelines. The description does not need to add parameter information, and it doesn't attempt to invent any.

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 specific verb 'summarizes' and resource 'active issuer universe by ATLAS-7 risk tier', making the tool's purpose clear and distinct from siblings like 'deltasignal_top_stressed' (top stressed issuers) and 'deltasignal_covenant_stress' (specific covenant stress).

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

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

The description provides clear context: it's for understanding market-wide stress concentration before drilling into individual companies. It implies a sequential usage pattern but does not explicitly state when not to use the tool or list alternative 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?

Behavioral traits are disclosed beyond annotations: the description confirms it is read-only and idempotent, and adds 'performs one HTTPS read, has no destructive side effects, and does not write files, wallets, orders, or account state.' Annotations already mark readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds useful context.

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

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

The description is well-structured, starting with the tool's purpose and then providing parameter and behavioral details. Every sentence adds value, though the behavioral part could be shortened slightly given annotation coverage.

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 that an output schema exists, the description adequately covers the tool's purpose, when to use it, and its behavior. It mentions the return type ('issuer-specific filing choreography and pressure-map context') without needing exhaustive detail. This is sufficient for a single-parameter 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 provides a description, pattern, examples, and length constraints for ticker (100% coverage). The description adds value by reinforcing that the ticker 'must be one public-company symbol such as RIOT, MARA, COIN, MSTR, HUT, or CLSK,' which emphasizes the expected inputs 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 uses a specific verb 'retrieve' and identifies the unique resource 'SPECTRA historical field-map contract' for a 'crypto public company ticker'. It clearly distinguishes this tool from siblings by focusing on SPECTRA and field-map context, unlike other tools like deltasignal_company_fundamentals.

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

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

The description explicitly states when to use the tool: 'Use it when the user asks for SPECTRA, field-map, historical pressure, filing choreography, or report-visualization context for a named issuer.' This provides clear context and disambiguation without needing to mention 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?

Discloses it is a non-trading write operation, creates an in-memory record, has no destructive side effects, does not call evidence routes, and refuses trading instructions. This goes beyond annotations (readOnlyHint=false, destructiveHint=false) to provide comprehensive behavioral details.

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 information-dense but well-structured: purpose, storage details, parameter list, behavioral notes. Each sentence adds value. Slightly long but justified given 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?

Given 7 parameters, complex behavior, and an output schema (thesis_id + access_token), the description covers return values, runtime limitations, and future phases. It is complete for an agent to decide usage.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description summarizes required and optional fields but adds little semantic value beyond the schema. 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 creates an 'accountless Thesis Monitor object' protected by a one-time capability token. It specifies verb ('create'), resource ('Thesis Monitor object'), and distinguishes from siblings by emphasizing accountless and token-based access.

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

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

Explicitly instructs to use 'after thesis readiness' for a lightweight MCP/x402 flow without accounts, providing clear use context. However, it does not explicitly state when to avoid this tool (e.g., when persistent storage is needed), though the limitations are implied.

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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavioral details: 'deterministic local validation only,' 'no destructive side effects,' 'does not call DeltaSignal evidence routes,' 'does not execute wallets or x402 settlement,' and 'never returns buy/sell/hold instructions.' This fully informs the agent of safe 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 a single, information-dense paragraph that front-loads purpose and then covers behavior. It is concise with no redundant sentences, though it could be slightly more structured (e.g., bullet points) for easier parsing.

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 8 parameters, 100% schema coverage, an output schema, and thorough annotations, the description is complete. It explains purpose, usage guidelines, behavioral guarantees, and parameter roles, leaving no gaps for agent understanding.

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% with parameter descriptions. The description lists required and optional parameters but adds no new meaning beyond summarizing what's in the schema. Baseline 3 is appropriate as schema already documents semantics.

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

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

The description clearly states the tool's purpose: 'determine whether a user-written issuer thesis is monitorable' before paid evaluation. It lists specific scoring dimensions (issuer specificity, thesis clarity, etc.), distinguishing it from sibling tools like deltasignal_readiness by focusing on thesis readiness.

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

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

Explicit guidance: 'Use this read-only tool before paid ATLAS evidence evaluation' and 'use paid thesis baseline or evaluation only after readiness is monitor_ready or needs_cleanup.' It positions the tool as a free/low-cost structuring layer, giving clear when-to-use and when-not-to-use 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. Description adds ranking logic and context but no additional behavioral traits 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?

Single, well-structured sentence that is front-loaded with key information. No redundant or extraneous 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?

With an output schema present, description adequately covers core functionality and use case. Could mention ordering direction but overall complete for a ranking tool with documented parameters and schema.

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

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

Schema coverage is 100% and provides descriptions for both parameters (limit, offset). Description does not add any new parameter semantics beyond what schema already offers.

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

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

Description clearly states verb 'ranks', resource 'most stressed crypto public companies', and specifies inputs (covenant stress, debt coverage, etc.) and use case (triage workflows). Distinguishes from siblings like 'deltasignal_alpha_signals' which focus on different aspects.

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?

Implied usage for triage workflows, but no explicit when-to-use or when-not-to-use guidance compared to sibling tools. The description does not mention alternatives or exclude other contexts.

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, idempotentHint, and destructiveHint. The description adds context about the single HTTPS read and explicitly states it never executes trades or writes, reinforcing the safety profile.

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

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

Three front-loaded sentences cover purpose, parameters, and behavior with zero wasted words. Each sentence serves a distinct function.

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?

Output schema exists externally. The description summarizes output content (preserving ranks, stress values, flags, etc.) and confirms no side effects, making the description complete for decision-making.

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 baseline is 3. The description adds value by explaining the effect of the style parameter ('changes tone and density only, not facts') and context for limit and offset usage.

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

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

The description clearly states the tool's purpose: generating human-readable Markdown from the Top Stressed screen. It distinguishes itself from the sibling 'deltasignal_top_stressed' raw JSON tool, providing a specific verb-resource pair.

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

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

Explicit guidance on when to use this tool ('when the user wants ... human-readable Markdown') and when to use the sibling ('Use raw deltasignal_top_stressed for cheap structured JSON'), with no ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the SVG generation is 'deterministic' and 'Go-native', reinforcing idempotency and performance. It also clarifies the MVP status. 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?

Two sentences: first sentence clearly states purpose and outputs, second sentence adds an important limitation. No fluff, front-loaded with key information.

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

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

Given the complexity (nested contract object, output schema exists, annotations cover safety), the description is adequate. It covers the core behavior and constraints. It does not explain all output fields (fit report, hashes) but output schema presumably handles 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?

Schema description coverage is 100%, so the schema already details each parameter. The description mentions 'contract' and optional parameters but adds minimal extra meaning beyond what the schema provides. Baseline is 3.

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

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

The description explicitly states the action ('Render'), the input ('validated StrategiX visual-spec contract'), and the output ('deterministic Go-native SVG with fit report, hashes, compact search metadata, and human-readable receipt fields'). It distinguishes from sibling tools (validate, package, search) by focusing on rendering and using a validated contract. The note about MVP limitations adds 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 implies the contract should be validated first, suggesting a workflow with the validate tool. It states the MVP does not use external renderers, setting expectations. However, it does not explicitly state when to avoid this tool or list 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, idempotentHint=true, and destructiveHint=false, indicating safe, non-mutating behavior. The description adds value by specifying exactly what is validated (e.g., nodes, edges, viewport policy) and explicitly stating it does not draw or mutate the canvas, providing behavioral context 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 no wasted words. The first sentence states the primary purpose, and the second provides key details (what is validated, what is not done). Information is front-loaded and efficiently presented.

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 purpose and behavioral constraints, and the output schema is available (though not shown) so return values need not be described. It mentions what is validated and what is not, but could slightly benefit from a note about the output format. Overall, it is sufficiently complete for a validation 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 has 100% description coverage for all properties of the 'contract' parameter, so the schema already documents the structure. The description adds little extra meaning beyond listing some validated fields, which is partially redundant. Baseline of 3 is appropriate given 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 it validates a StrategiX visual-spec contract before rendering, specifying the exact fields it checks (nodes, edges, owners, etc.) and explicitly distinguishing itself from drawing or mutation. This differentiates it from sibling tools like strategix_diagram_render and strategix_visual_spec_package.

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 before rendering ('before rendering') and mentions 'Infrastructure-first', but does not explicitly state when to use this tool vs alternatives or when not to use it. The context of sibling tools (render, package, search) provides indirect guidance, but the description lacks explicit exclusions or comparisons.

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, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by listing what is included in the output (JSON contract, source digest, fit report, metadata, receipt block), which goes beyond annotations. However, it does not mention side effects or limitations.

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, front-loaded with the action and concise details. No superfluous words, efficient structure.

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

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

Given the tool's complexity (5 parameters, nested objects, output schema exists), the description adequately explains the output composition. It does not need to explain return values due to output schema. Missing input context beyond schema but schema is thorough.

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 input schema already fully describes all parameters. The description does not add parameter-level semantics beyond what the schema provides, resulting in baseline score.

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

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

The description uses specific verbs ('Package') and resources ('canonical contract', 'rendered SVG', 'self-contained HTML'), listing the embedded elements. It clearly distinguishes this packaging tool from sibling tools like strategix_diagram_render and strategix_diagram_validate.

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

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

No guidance on when to use this tool versus alternatives (e.g., strategix_diagram_render). No mention of prerequisites or exclusions, leaving the agent to infer usage 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 indicate read-only, idempotent, non-destructive behavior. The description adds that results are compact metadata, which is useful beyond annotations but not extensive.

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 that are front-loaded with the core purpose and end with a clear limitation. Every sentence 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?

Given the output schema exists and annotations cover safety, the description sufficiently covers what the tool returns and its scope, leaving no major 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?

Schema coverage is 100% with clear parameter descriptions. The description adds context by listing searchable fields (topic, source digest, etc.), enhancing understanding of the query parameter.

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 'Search compact visual-spec metadata' and lists searchable fields. It distinguishes from sibling tools like strategix_diagram_render by focusing on metadata search only.

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 sets expectations by stating 'Returns compact metadata only; full HTML/SVG/XML is a drilldown concern,' implicitly guiding against using this tool for full spec retrieval. However, it does not explicitly name alternatives.

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