DeltaSignal ATLAS-7

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering most behavioral traits. The description adds the subscription gating context, which is useful but not critical. No contradictions.

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

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

The description is a single concise sentence. While it is efficient, it could be slightly more structured to improve scannability. 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?

The tool has an output schema (not shown) and only optional parameters. However, the description does not explain what the output contains or how the filtering parameters affect results. Adequate but not complete.

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

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

Schema coverage is 100% (all three parameters have descriptions). The description does not add any additional meaning beyond what the schema already provides, so the 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 'Subscription-gated semantic alpha-candidate screen' indicates it is a read operation for alpha candidates, but it lacks a specific verb (e.g., list, fetch) and does not differentiate it from sibling tools like atlas7_semantic_query or atlas7_signal_board.

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

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

No guidance is provided on when to use this tool versus alternatives. The mention of 'Subscription-gated' is a constraint, not a usage recommendation or exclusion.

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 safe, read-only, idempotent behavior. Description adds 'subscription-gated' (access control context), but no details on pagination, date range, or other 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?

Extremely concise (3 words) but under-informative; front-loads key access constraint, but loses clarity.

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 3 optional parameters and no required ones, the description is insufficient for an agent to robustly infer the tool's scope. Even with an output schema, the purpose remains too ambiguous to distinguish from sibling search tools.

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 descriptive parameter names and descriptions. Description adds no extra meaning beyond the schema (e.g., relationship between cik and ticker).

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 'Subscription-gated archive and history search' is vague; it does not specify what type of archive (e.g., filings, signals) and does not differentiate from siblings like atlas7_recent_history or atlas7_semantic_query.

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; no mention of prerequisites, limitations, or specific use cases.

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 provide readOnlyHint, idempotentHint, destructiveHint, openWorldHint. Description adds 'Subscription-gated' (access requirement) and 'filing-backed' (data source), but no behavioral details beyond that. 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?

Extremely concise but too terse - a single phrase lacking a verb or full sentence. Not front-loaded with clear action, and the cryptic phrasing undermines usefulness.

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, return values need not be explained. However, the description fails to adequately summarize the tool's purpose for an AI agent. For a tool with 3 params and annotations, more context is 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?

Schema description coverage is 100%, so the schema already explains parameters. Description adds no parameter context. 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?

Description is vague: 'Subscription-gated filing-backed fundamentals surface.' It does not state a clear verb or resource (e.g., 'retrieve' or 'list'). Compared to siblings like atlas7_quick_ticker_check or deltasignal_company_fundamentals, purpose is ambiguous.

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 vs alternatives. The description does not mention context, prerequisites, or exclusions.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint), idempotency (idempotentHint), and world state (openWorldHint). The description adds 'Subscription-gated', a critical behavioral trait not in annotations, alerting the agent to access requirements.

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?

Extremely concise at one sentence, front-loading 'Subscription-gated'. However, it sacrifices clarity; a bit more detail could improve without harming conciseness.

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

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

Despite an existing output schema and good annotations, the description fails to explain the tool's core action. With 3 optional parameters and moderate complexity, the agent needs a clearer purpose statement to use it effectively.

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 adequate parameter descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, meeting the baseline.

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

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

The description 'Subscription-gated structured Company Report input bundle' lacks a clear verb indicating what the tool does (e.g., retrieve, generate, provide). It does not distinguish from siblings like 'atlas7_company_fundamentals' or 'deltasignal_company_report', leaving the agent uncertain about its specific function.

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

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

No guidance on when to use this tool versus alternatives. The description does not specify context, prerequisites, or exclusions, leaving the agent to infer usage from the name 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, and destructiveHint=false. The description adds 'subscription-gated', which is a behavioral constraint not captured in annotations, providing valuable context. No contradictions.

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

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

The description is a single concise sentence that front-loads the key attribute (subscription-gated) and clearly states the tool's purpose. No superfluous words.

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

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

Given the presence of an output schema and rich annotations, the description is somewhat sparse. It mentions subscription gating but does not elaborate on what the 'stress view' entails or how results are presented. Adequate but could provide more context.

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

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

The input schema has 100% description coverage for all three parameters. The description does not add any additional 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 it provides a 'view' of 'covenant, debt, and liquidity stress', indicating a read operation. It distinguishes from siblings like 'atlas7_top_stress' by specifying subscription gating, but could be more specific about what the view includes.

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

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

No guidance is provided on when to use this tool versus alternatives like 'deltasignal_covenant_stress' or 'atlas7_top_stress'. The description implies usage for viewing stress data but lacks explicit context or exclusions.

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 'Subscription-gated' beyond annotations, indicating access restrictions. Annotations already cover read-only, idempotent, non-destructive behaviors, so description provides one extra behavioral trait.

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?

Extremely concise (6 words) and front-loaded with key information. Every word earns its place.

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

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

Despite output schema existing, the description is too vague. It doesn't explain what 'evidence and provenance lineage' entails, and given 5 optional parameters, more context about typical usage is 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?

Schema description coverage is 100%, so baseline is 3. Description does not add any parameter-level meaning beyond what is already 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?

Description specifies 'evidence and provenance lineage drilldown' as the resource and action, which is fairly clear. It distinguishes from siblings by focusing on lineage drilling, but lacks an explicit verb like 'retrieve'.

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 vs. alternatives. Does not mention any context or exclusions, leaving the agent uninformed about appropriate 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, idempotentHint, and absence of destructiveness. The description adds value by revealing that raw SQL is not exposed and that access is subscription-gated, which 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, front-loaded sentence that conveys the core functionality and key constraints (subscription, no raw SQL) without extraneous 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 has a rich input schema and output schema, the description is adequate but lacks usage context and does not explain the output format. It is minimally complete for a tool with full schema coverage.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning about parameters, resulting in a 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 clearly states it provides an explanation of fields, evidence requirements, and SQL fingerprint without raw SQL, which is a distinct purpose from sibling tools like atlas7_semantic_query.

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 lacks explicit guidance on when to use this tool versus alternatives. It only mentions 'Subscription-gated' as a prerequisite, but does not specify contexts or exclusions.

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 the 'Subscription-gated' constraint, which is a behavioral trait beyond annotations. However, it does not clarify pagination, rate limiting, or what happens with no parameters provided.

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

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

The description is extremely concise at three words, with no wasted text. It front-loads the key information. A slightly longer description could improve clarity without sacrificing conciseness, but it is efficient.

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

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

Given that the tool has an output schema, the description need not explain return values, but it fails to clarify what an 'issuer signal' is, why a subscription is required, or how to handle the optional parameters. The context of sibling tools suggests many alternatives for similar data, but the description does not guide selection.

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

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

Input schema coverage is 100%, so the description adds no new parameter meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema fully documents all three 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 it provides an 'issuer signal' by ticker or CIK, which is a specific verb-resource combination. While 'signal' is somewhat vague, it distinguishes from siblings like 'atlas7_alpha_candidates' or 'atlas7_signal_board' by focusing on a single issuer.

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 mentions 'Subscription-gated' but provides no context on when to use this tool versus alternatives, nor any exclusions or prerequisites. There is no guidance on whether to prefer this over sibling tools like 'atlas7_quick_ticker_check' or 'atlas7_evidence_lineage'.

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, covering safety. The description adds 'Subscription-gated', which implies access control. No other behavioral traits (e.g., pagination, audit scope) are disclosed.

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

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

Single sentence, no fluff. Front-loaded with key term 'calculation lineage audit', but could be slightly more informative without losing conciseness.

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

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

Despite having an output schema, the description lacks context on what the audit produces (e.g., list of changes, compliance reports). With 5 optional parameters and many siblings, more guidance is needed 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?

Schema description coverage is 100%; all parameters are clearly documented in the schema. The description adds no additional meaning or context for any 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 phrase 'calculation lineage audit' gives a general topic but lacks a specific action verb or outcome. It vaguely distinguishes from 'atlas7_evidence_lineage' by mentioning 'calculation', but does not clearly state what the tool does (e.g., retrieve, list, compare).

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 like 'atlas7_evidence_lineage' or 'deltasignal_atlas7_calculation_history'. The description does not mention prerequisites, context, or intended 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 provide readOnlyHint=true, idempotentHint=true, etc., covering safety and idempotency. The description adds 'Subscription-gated,' which is behavioral, indicating access control. However, it lacks details like whether the tool returns a list or a single item, or what overlay context means. With annotations providing strong transparency, the description adds moderate value.

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 very concise at one sentence. It front-loads the key idea (market context) and constraint (subscription-gated). There is no wasted text, but it could be expanded slightly for clarity without losing conciseness.

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 the tool has an output schema (not provided) and only two optional parameters, the description is too sparse. It doesn't explain what the output contains, how the instrument filters, or the default behavior. For a tool with broad sibling set, more context is needed for proper selection.

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

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

Schema coverage is 100%, so the descriptions in the schema already explain 'limit' and 'instrument' adequately. The tool description does not add any additional meaning beyond the schema. 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 mentions 'market and instrument overlay context,' which suggests it provides market context data, but it's vague. It doesn't specify what data is returned (e.g., prices, trends) or how it relates to the instrument parameter. Compared to siblings like atlas7_alpha_candidates or atlas7_semantic_query, the purpose is not distinct enough.

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 vs alternatives. It does not state prerequisites or exclusions. The subscription-gated nature hints at a constraint but not usage. The agent would need to infer from the name and 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?

The description adds the subscription-gating context beyond annotations (readOnlyHint, openWorldHint, etc.), which is useful. However, it does not elaborate on what constitutes a 'subscription' or behavior when not subscribed. Annotations already indicate safety, so the description provides marginal additional 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 extremely concise (6 words) but lacks structure; it is a fragment rather than a complete sentence. While brevity is positive, the lack of sentence structure and additional context makes it less informative than it could be.

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

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

Despite having an output schema, the description fails to explain what the tool returns or how to use the optional parameters. The vague 'input bundle' concept leaves the agent uncertain about the tool's purpose and invocation context.

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

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

All three parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema, nor does it explain how the parameters relate to the 'input bundle' concept.

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 'Subscription-gated structured Morning Brief input bundle' clearly identifies the tool as providing inputs for a Morning Brief, distinguishing it from sibling tools not related to morning briefs. However, it lacks specificity about what the inputs are or how they are structured.

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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like deltasignal_morning_brief or other atlas7_* tools, leaving the agent without guidance on 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=true, idempotentHint=true, destructiveHint=false. The description adds 'subscription-gated', informing agents that access is restricted. This is a useful addition, but it does not elaborate on behavioral traits like data freshness or concurrency limits.

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

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

The description is extremely concise (six words), but brevity sacrifices explanatory power. There is no wasted text, but more critical information is missing.

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 (as per context), the description does not explain what 'relative pressure' means or how results are structured. The term 'peer ranking' is ambiguous without further context. For subscription-gated tools, agents need to know failure modes if access is missing.

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

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

Schema coverage is 100%, so the input schema fully documents the three optional parameters (cik, limit, ticker). The description adds no extra semantic value beyond what is already 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 'Subscription-gated peer ranking and relative pressure' conveys the general function but lacks a clear verb-action. It reads more as a label than an explanation. It does not differentiate from sibling tool deltasignal_peer_ranking which likely has overlapping functionality.

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 like atlas7_pressure_board or deltasignal_peer_ranking. The 'subscription-gated' qualifier hints at access conditions but does not clarify use cases.

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, so safety is clear. The description adds that it is subscription-gated and an MVP, which are important behavioral traits not captured by 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 very short at 12 words. It front-loads the core purpose but is too terse to fully convey the tool's scope. It could be more informative without sacrificing conciseness.

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

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

Even with a full output schema, the description lacks context about what 'watchlist analysis' entails. It does not explain the nature of the analysis or how the results are presented, leaving the agent underinformed.

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 documents all 3 parameters with descriptions, so the baseline is 3. The description only restates that it uses ticker or CIK filters, adding no new semantic 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 identifies the tool as 'saved watchlist analysis'. The verb 'analysis' is implied and the resource is a watchlist. It distinguishes from siblings by focusing on a saved watchlist rather than individual ticker checks or 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 guidance on when to use this tool versus sibling tools like atlas7_quick_ticker_check or atlas7_issuer_signal. The description mentions it's subscription-gated, but does not explain the prerequisites or context for using it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds 'subscription-gated,' which is a behavioral constraint beyond annotations. However, it does not disclose other traits like data scope or performance.

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

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

The description is extremely concise (4 words) with no fluff, but it lacks structure and completeness. It is front-loaded but under-specified, earning a mid score.

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

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

Despite having an output schema and full parameter documentation, the description fails to explain what the tool does, its output, or how to use it effectively. For a tool with many siblings, this is insufficient.

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 3 parameters (limit, stress_field, signal_filter) with 100% coverage. The description adds no extra meaning about these parameters, so baseline 3 is appropriate.

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

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

The description 'Subscription-gated semantic pressure board' is vague. It does not specify what the tool does (e.g., list, retrieve) or what a 'pressure board' is. The verb and resource are unclear, and it fails to distinguish from siblings like 'atlas7_signal_board' or 'deltasignal_pressure_board'.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or comparison to siblings. The subscription-gated note is a constraint but not a usage guideline.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, providing good safety context. The description adds 'subscription-gated', which indicates access control, but overall lacks behavioral details like what 'triage' entails.

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

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

The description is extremely concise (3 words), but at the cost of clarity. It is front-loaded but insufficiently 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 has 3 optional parameters and no required ones, the description is too vague to guide invocation. It does not explain what 'ticker triage' means or how the parameters relate to the operation.

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 for all 3 parameters. The description adds no additional parameter-level information beyond what the schema already provides.

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

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

The description 'Subscription-gated semantic ticker triage' is vague and lacks a specific verb and resource. It does not clearly state what the tool does, and it fails to distinguish it from the sibling tool 'deltasignal_quick_ticker_check'.

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 usage guidelines are provided. There is no indication of when to use this tool versus alternatives, nor any exclusions or prerequisites.

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, openWorldHint, idempotentHint, destructiveHint, covering safety and idempotency. The description adds the subscription-gating constraint, which is behavioral context beyond annotations. No contradictions.

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

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

Two sentences, minimal verbosity, front-loaded with purpose. Every sentence adds value: first defines the tool, second distinguishes from sibling.

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

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

For a simple read-only tool with optional parameters and an existing output schema, the description is sufficient. It explains the core purpose, subscription requirement, and relationship to an alternative. Could elaborate on return structure, but output schema covers that.

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

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

The schema covers the single 'limit' parameter with full description (maximum 1000 rows, minimum 1). The description does not add parameter meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states 'Subscription-gated semantic readiness and entitlement status', specifying the scope and resource type. It differentiates from the sibling 'deltasignal_readiness' by noting that 'Existing DeltaSignal readiness remains available through x402; this semantic surface requires Marketplace subscription.'

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 informs when to use this tool vs the alternative: it requires a Marketplace subscription, while the existing DeltaSignal readiness (presumably via deltasignal_readiness) is available through x402. This provides clear guidance on 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 declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'Subscription-gated' context, which indicates access control. However, does not elaborate on behavior such as what 'recent' means, rate limits, or how subscription is enforced. No contradiction with annotations.

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

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

Extremely concise (6 words) but at the expense of clarity. It is front-loaded but lacks structure; a full sentence would better convey purpose. It is not redundant but could be improved without adding much length.

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

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

Despite having an output schema and 100% param coverage, the description is too vague. It does not explain what 'issuer trajectory' means, what data is returned, or how it differs from similar tools. For a tool with multiple siblings and 3 parameters, the description is incomplete.

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 schema already documents all parameters (cik, limit, ticker). Description does not add any additional meaning or context beyond what schema provides. 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?

Description 'Subscription-gated recent point-in-time issuer trajectory' hints at retrieving historical data for an issuer but is vague. It uses jargon ('point-in-time') and doesn't clearly state that it returns recent history for a given CIK or ticker. Not a tautology but insufficient for clear understanding.

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 siblings like atlas7_issuer_signal or atlas7_company_fundamentals. No when-to-use, when-not-to-use, or alternatives mentioned. Agent must infer from tool name 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 behavioral context: results are evidence envelopes (not raw SQL) and the tool is subscription-gated. This adds value beyond the annotations.

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

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

The description is two concise sentences with no redundant information. It front-loads key constraints (subscription gate, governed, return type) without any 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?

Given 6 optional parameters, output schema exists, and annotations are rich, the description adds needed context about return format and access control. It is sufficiently complete for effective tool selection.

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

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

Schema description coverage is 100%, so parameters are fully documented. The description does not add per-parameter semantics; it only provides a high-level summary. 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 it is a 'semantic query' that returns 'ATLAS evidence envelopes only' and explicitly says 'raw SQL is never returned'. This provides a specific verb+resource and distinguishes from other query tools that might return 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?

The description mentions 'Subscription-gated' which implies access control but does not provide explicit guidance on when to use this tool versus siblings. No alternative tools or exclusion conditions are mentioned.

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

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

Annotations already declare safe read-only behavior. The description adds the constraint 'Subscription-gated,' which is a useful behavioral trait not captured in annotations. However, it lacks details on subscription requirements or data freshness.

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

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

The description is a single short sentence, which is concise but may be too minimal. It sacrifices informational value for brevity.

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

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

Given the existence of an output schema, the description does not need to explain return values, but it fails to provide enough context to distinguish this tool from many similar siblings or to understand when it should be invoked.

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 clear parameter descriptions. The tool description does not add any additional meaning beyond what is already in the schema, so baseline 3 is appropriate.

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

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

The description 'Subscription-gated latest issuer signal board' conveys a general purpose but is vague. It does not specify the action (e.g., retrieve, list) or differentiate from siblings like atlas7_issuer_signal.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites or exclusions.

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 addition of 'subscription-gated' provides extra behavioral context. However, it does not elaborate on return behavior or constraints beyond annotations.

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

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

Single sentence, no fluff, front-loaded with key purpose. Very concise, though could include slightly more detail without harming conciseness.

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 output schema present, discussion of return values is not needed. However, the description is minimal and lacks context about how themes/concepts/taxonomies are related or what 'subscription-gated' entails practically.

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

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

Schema description coverage is 100%, so parameters are already documented. The tool description adds no extra meaning beyond the 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?

Clearly states it's for theme, concept, and taxonomy discovery, with the additional context of being subscription-gated. This distinguishes it from sibling tools like atlas7_alpha_candidates or atlas7_semantic_query.

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 purpose but does not provide when-not-to-use or mention of 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety is clear. The description adds 'subscription-gated' (indicates access restriction) and 'semantic' (hints at sorting logic), which provide behavioral context beyond annotations.

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

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

The description is extremely short (a phrase fragment), which is concise but lacks full sentence structure. It is front-loaded with the key term 'top-stress ranking', but does not include essential behavioral details that could fit without much extra length.

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

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

Given the tool has an output schema and all parameters are documented, the description is partially complete. However, it omits details like how the ranking is computed, what 'semantic' means in practice, or how subscription gating works. An output schema exists, so return value info is not needed, but behavioral details are missing.

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

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

Schema description coverage is 100%, with each parameter (limit, stress_field, signal_filter) already described in the input schema. The description does not add new meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description 'Subscription-gated semantic top-stress ranking' clearly indicates the tool produces a ranking of top stress items, with verbs implied (ranking). It differentiates from sibling tools like atlas7_covenant_stress (which focuses on covenants) and deltasignal_top_stressed (similar but not explicitly distinguished), but not fully explicitly.

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

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

No guidance on when to use this tool versus alternatives like atlas7_covenant_stress or deltasignal_top_stressed. The description does not specify context, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it performs one HTTPS read, has no side effects, and does not handle wallets or payments. It also clarifies deterministic scoring (Phase 1). No contradictions.

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

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

The description is a single paragraph that covers purpose, parameters, and behavior without excessive verbosity. It could be slightly more structured (e.g., bullet points) but remains clear and efficient.

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

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

The description lists all significant return fields (ticker, CIK, alpha score, etc.), making it complete for an agent. With an output schema present and strong annotations, the description fills remaining 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%, and the description adds value by suggesting limit ranges (10-25 for summaries, up to 100 for full screening), default issuer_type, and when to use include_funds. This supplements the schema's parameter 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's purpose: a read-only screening tool that ranks issuers by alpha score. It specifies the resource (DeltaSignal issuer universe) and the action (rank by Phase 1 alpha score), and the returned fields. This distinguishes it 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?

The description provides usage guidance, including default behavior (operating-company issuers) and when to use include_funds. It implicitly differentiates from other tools by focusing on screening, but does not explicitly name alternative tools for other alpha-related 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds context beyond those: it specifies 'read-only and idempotent; it performs one HTTPS read, has no destructive side effects' and enumerates what it doesn't affect. 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?

Three well-structured sentences with front-loaded purpose. Every sentence provides essential information—no filler or redundancy.

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

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

Given the tool's complexity, presence of output schema, and annotations, the description covers usage scenario, behavioral boundaries, parameter guidance, and links to siblings. It is complete without needing elaboration on return values.

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 meaning beyond parameter names and types: it explains limit range purpose, source_date replay concept, issuer_type values, and a warning for include_rows. This significantly aids correct 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 uses a specific verb ('explain why... includes, excludes, or demotes rows') and identifies the resource ('alpha-opportunity board'). It distinguishes itself from siblings by stating when to use it (after deltasignal_alpha_opportunities or deltasignal_alpha_sweep) and lists return summaries.

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 ('after deltasignal_alpha_opportunities or deltasignal_alpha_sweep when the user asks why...') and provides exclusions (no destructive side effects, does not change scoring/state). Also links to sibling tools by 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?

The description declares read-only, idempotent behavior with no destructive side effects, no trading, no data storage, and no wallet secrets handling. This aligns with and expands upon the annotations (readOnlyHint, idempotentHint, destructiveHint), leaving no behavioral ambiguity.

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

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

The description is well-structured and front-loaded with the core purpose. It covers all necessary aspects in a logical order, though it is a bit lengthy. Every sentence serves a purpose.

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

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

Given the tool's complexity (2 parameters, annotations, output schema), the description fully covers purpose, parameters, behavior, usage guidelines, and alternatives. It mentions output content and treats the result as issuer intelligence. No 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 description coverage is 100%, and the description adds context beyond the schema: it explains ticker normalization to uppercase and that source_date should only be used to replay a historical slice. This provides useful semantic guidance.

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 DeltaSignal ATLAS-7 alpha signals for crypto public company tickers, listing specific signal evidence types. It distinguishes from sibling tools like covenant_stress and company_fundamentals by explicitly naming when those should be used instead.

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

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

The description provides explicit usage guidelines: use for research triage on supported public-company tickers (COIN, MSTR, etc.), avoid crypto asset symbols. It also directs the agent to alternative tools (readiness, covenant_stress, company_fundamentals) for different needs.

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), the description adds behavioral details: performs three internal HTTPS reads, no destructive side effects, never calls issuer-level tools, and preserves partial results on failure. This enhances transparency meaningfully.

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 but comprehensive: two sentences for purpose, one for parameters, two for behavior, and one for usage. Each sentence earns its place, no fluff, and information is front-loaded.

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

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

Given complexity (composite workflow with multiple internal API calls) and presence of output schema, the description adequately covers internal plan, parameter constraints, and behavioral characteristics. No gaps remain.

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

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

The only parameter (output_mode) is fully described in schema (100% coverage). The description reinforces the allowed value (compact only) and explicitly prohibits passing other parameters, which adds semantic value beyond the schema by clarifying what is not allowed.

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 composite workflow for alpha screening across the current DeltaSignal issuer universe. It specifies the action (screening), resource (opportunity and alpha), and scope, distinguishing it from sibling tools that are more granular or non-composite.

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: 'when the user asks for alpha opportunities, opportunity sweep, clean alpha board, or names worth follow-up research.' It also lists parameters that should not be passed (limit, offset, ticker, etc.) because the preset owns internal arguments, providing clear guidance on proper 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?

Description significantly enriches annotations by detailing internal behavior: resolving TF-SUB article, comparing linked evidence, marking missing evidence, returning eight sections. It also explicitly states non-behaviors (no Grok, no invention, no mutation). No contradiction with annotations.

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

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

Description is a single well-structured paragraph that efficiently covers purpose, usage, key parameters, behavior, and constraints. No redundant or filler sentences; every sentence contributes essential information.

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

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

Given the tool's complexity (25 parameters), 100% schema coverage, rich annotations, and presence of output schema, the description provides sufficient context on internal workings and limitations. It explains what the tool does and does not do, though it could briefly mention that it is read-only (already in 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 description coverage is 100%, so baseline is 3. Description highlights key parameters (article_tripcode, tripcode, prior_article_tripcodes, etc.) but adds minimal new meaning beyond schema. It does clarify which parameters are primary vs optional, but this is already inferable from 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?

Description clearly states the tool is a read-only synthesis tool used when a subscriber provides a TripCode and asks for the thesis map. It specifies the verb (synthesize), resource (DeltaSignal article), and distinguishes from siblings through its synthesis focus and read-only nature.

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 explicitly states when to use (when subscriber gives TripCode and asks for thesis map), lists key parameters, and describes default behavior for HUT. While it does not explicitly mention when not to use or provide alternatives, the context from sibling tools and the specific trigger condition offer clear 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 read-only, idempotent, non-destructive. The description adds valuable context: it does not run the audit, mutate data, or access raw evidence. No contradiction with annotations.

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

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

The description is two sentences, front-loading the purpose and use case. Every sentence adds value; no wasted words.

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

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

Given no parameters, rich annotations, and an output schema, the description fully covers what the tool does and when to use it. No 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?

With zero parameters, the baseline is 4. The description notes 'Parameters: none', which is sufficient. No further explanation needed.

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

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

The description clearly states the tool's purpose: to check the health of the ATLAS-7 audit. It specifies the verb 'check' and the resource 'audit status', listing exact information returned. It distinguishes itself from sibling tools by focusing on ATLAS-7 specifically.

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

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

The description provides explicit when-to-use guidance: 'before trusting historical ATLAS-7 surfaces' or when asked about the nightly audit currency. It lacks explicit alternatives or when-not-to-use scenarios, but the context is clear.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that it has no wallet, settlement, or trading actions, and explains the parameter behavior (date ranges for paging, mode effect). No contradictions with annotations.

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

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

The description is well-structured with 6-7 sentences that are front-loaded with purpose. Every sentence adds value, no redundancy or filler.

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

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

Given the tool's complexity (8 optional params, output schema exists), the description covers all key aspects: what it returns, how to filter, mode options, safety guarantees. The output schema handles return value details, so completeness is high.

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 adds meaningful context: source_date replays a slice, source_date_from/to page recent slices, ticker/CIK narrow, mode compact/full. This goes 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?

The description clearly specifies the action (assemble complete ATLAS-7 calculation history) and the resource (bundle from various precomputed surfaces). It distinguishes from siblings by enumerating the components it includes, which none of the other ATLAS-7 tools do comprehensively.

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

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

The description explicitly states when to use this tool ('when agents need the complete ATLAS-7 calculation bundle') and provides context ('before historical report rendering so agents do not mix latest-only fields'). It does not explicitly name alternative tools, but the listed components imply 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these by stating 'read-only and idempotent; it performs no writes, has no destructive side effects' and adds context about not returning the raw facts_payload, providing drill-down 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?

The description is a single paragraph that front-loads the purpose and key behavior. It is clear and efficient, though slightly verbose in listing parameter details that are already in the schema.

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

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

Given the tool's complexity (7 parameters, output schema present), the description adequately covers use cases, behavior, and parameter usage. It leverages the existing schema and annotations to avoid redundancy.

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 parameters are well-documented. The description summarizes key parameters (source_date, ticker, cik, limit, offset) and their roles, adding value like default limit and cap, but does not substantially extend the schema descriptions.

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

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

The description clearly identifies the tool as a read-only resource to retrieve compact SEC CompanyFacts/XBRL materialization rows for the crypto public-company universe or a specific ticker/CIK. It specifies the verb 'retrieve' and the resource 'CompanyFacts history', making the purpose distinct from siblings.

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

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

The description provides explicit guidance on when to use the tool ('for Mirror Pulse or ATLAS-7 historical joins') and what to expect (compact issuer-level inventory). It also hints at what not to do (raw facts_payload is not returned) but does not explicitly name 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description expands on this by listing specific non-behaviors: it does not fetch live market data, run ATLAS calculations, place trades, or mutate recorder state. It also explains the return structure (available, missing, not_applicable). No contradictions.

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

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

The description is a single dense but well-organized paragraph. It front-loads the purpose, then explains layers, lists parameters, and adds behavioral notes. Every sentence adds value, though it could be slightly more readable with breaks.

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 6 optional parameters, high schema coverage, and an output schema, the description explains the return format (available/missing/not_applicable) and the meaning of the four levels. It omits edge cases like empty results or error handling, but these are often covered by the output schema. Overall, it provides sufficient context.

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

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

Schema coverage is 100%, with each parameter well-described in the schema. The description merely lists the parameter names, adding no new semantic detail beyond what is in the schema. Thus, it meets the baseline for high schema coverage without enhancing 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 opens with a clear verb ('determine'), resource ('ATLAS-7 four-level layers evidence backing'), and scope ('one issuer or paginated issuer universe'). It distinguishes from sibling tools by specifying it's about the four-level applicability engine, not alpha candidates, evidence lineage, or other related tools.

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

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

The description provides context: it generalizes the AI10/Tech100 engine, is read-only and idempotent, and does not fetch live data or place trades. This implies when to use it (for evidence-backed layer queries) and when not (when live data or destructive actions are needed). However, it does not explicitly name alternative tools or state exclusions.

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 show readOnly, idempotent, non-destructive. Description adds that it performs one HTTPS read, no destructive side effects, no NL generation, no trades, and includes lookahead safety flags, adding significant 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?

Four sentences, front-loaded with purpose, each sentence provides unique value. No redundant or vague language.

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 optional parameters, output schema exists, and annotations cover safety, the description explains behavior, mode choices, safety features, and intended use. Complete for an agent to use 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%, and description adds practical guidance: use compact by default for Mirror Pulse joins, full only for audit pages due to payload size. This goes 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?

The description clearly states it returns 'daily ATLAS-7 CompanyFacts-derived factor rows keyed by as_of_date' with point-in-time safety. It distinguishes itself from sibling history tools by emphasizing retrospective recomputation and lookahead safety flags.

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: for Mirror Pulse, backtests, or agents needing daily factor history. Provides mode guidance (compact vs full). Does not directly exclude siblings, but context is clear.

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

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

Annotations already declare readOnly and idempotent hints. The description adds further behavioral context: single HTTPS read, no destructive side effects, and no retroactive application of latest snapshot, providing full 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, front-loaded with purpose, and structured into two clear sentences covering usage, parameters, and behavior without unnecessary words.

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

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

Given the presence of output schema and annotations, the description fully covers return fields (debt, fair value, stress, etc.), usage context, and parameter behaviors, leaving no significant gaps for the agent.

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

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

Schema coverage is 100% and descriptions already document parameters. The tool description summarizes them (ticker required, date bounds, limit cap, offset) but adds little beyond what 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 clearly states the tool retrieves historical ATLAS-7 covenant and stress series for a ticker with specific return fields and use cases, distinguishing it from sibling tools like deltasignal_atlas7_point_in_time_history and 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?

Explicitly lists when to use the tool (historical ATLAS data, mNAV backtests, Mirror Pulse joins) with clear context, but does not explicitly state when not to use or mention specific alternatives beyond implied 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it does not fetch live exchange data, place trades, or mutate recorder state. This complements the annotations and provides transparency 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 well-structured: purpose first, then return details, parameter list, and behavior. It is concise without being overly terse, though the parameter enumeration could be considered slightly redundant given the schema.

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

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

Given the tool has 8 optional parameters, a clear output schema, and no required fields, the description covers the return content, behavioral constraints, and what the tool does not do. It is complete for a read-only query tool, though pagination details are left to the schema.

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

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

Schema description coverage is 100%, so baseline is 3. The description merely lists the parameters (e.g., product, source_date, mode) without adding meaning beyond what the schema already provides. No additional semantic enrichment is present.

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 retrieves 'Coinbase INTX perp market-factor history' from persisted recorder evidence, using a specific verb ('retrieve') and resource. This clearly differentiates it from sibling tools like deltasignal_coinbase_perp_constituents or deltasignal_coinbase_perp_factors, which focus on other 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?

The description indicates this is a read-only tool for retrieving specific history data, providing clear context. However, it does not explicitly state when to use this tool over alternatives (e.g., deltasignal_atlas7_calculation_history) or when not to use it, missing explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context by stating it does not fetch live data, place trades, or mutate state, which aligns with and reinforces 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 two sentences: first explains purpose and nature, second lists parameters. It is front-loaded with essential information, contains no redundancy, and earns every word.

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, the description need not explain return values. It covers the core purpose (retrieve persisted registries), behavioral traits (read-only, not live), and parameter summary, making it sufficiently complete for an agent to understand 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%, so baseline is 3. The description groups optional date parameters and mentions mode options, providing minimal extra value beyond the schema. No additional constraints or formats are explained beyond what schema already provides.

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

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

The description clearly states the verb 'retrieve', the resource 'persisted constituent registries', and scope 'one Coinbase thematic or index perp product'. It distinguishes from live exchange-native APIs, making the purpose precise and distinct from siblings.

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

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

The description explicitly labels the tool as 'read-only' and clarifies it does not fetch live exchange data or place trades, implying its appropriate use cases. However, it does not explicitly list alternative tools for live data or other scenarios, which would make it a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating 'does not fetch live exchange state or write recorder artifacts on demand,' providing specific 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, front-loaded with purpose and context. The parameter list in the second sentence is efficient but slightly run-on. Overall, it is 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 tool has 8 parameters with 100% schema coverage, an output schema exists, and annotations cover behavior, the description provides sufficient context. It explains the output contents and the read-only, idempotent nature, making it complete for an agent to use effectively.

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 the parameters but does not add significant new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states it is a read-only tool for persisted Coinbase INTX market-factor history for one perp product. It specifies the output includes factor rows, deltas, quality state, and optional full market inputs or lineage. This is specific and distinguishes from sibling tools that likely handle other products or 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?

The description explicitly says 'Use this read-only tool when the user wants persisted Coinbase INTX market-factor history for one perp product.' It also notes it does not fetch live exchange state or write recorder artifacts, implying when not to use it. However, it does not explicitly name alternative tools or state when not to use it in a comparative manner.

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 value by specifying what the tool does not do: it does not create factors, reconstruct missing depth, or override underlying factor rows. This provides clarity 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 three sentences with no wasted words. The first sentence states the purpose, the second explains the conversion, and the third lists parameters and behavior. Information is front-loaded and every sentence earns its place.

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

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

With an output schema present and good annotations, the description covers purpose, behavior, and parameters adequately. It mentions the labels produced but could briefly describe the output format. Overall, it provides sufficient context for effective tool 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?

Schema coverage is 100% with each parameter already described. The description merely lists the parameters without adding new meaning or context beyond the schema. Baseline is 3, and no additional semantics are provided.

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

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

The description clearly states the tool retrieves a market SPECTRA field map for a specific Coinbase INTX perp product. It uses specific verbs ('retrieve', 'converts') and identifies the resource precisely, distinguishing it from sibling tools like 'deltasignal_spectra_field_map' by naming the product type.

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

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

The description implies usage when needing the SPECTRA field map for a Coinbase perp, but does not explicitly state when not to use it or mention alternative tools. No exclusions or alternatives are provided, relying on general 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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds context beyond annotations by stating no live exchange fetches, order placement, or settlement flows. 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?

Two sentences with no wasted words. The purpose is front-loaded, and the description is tightly written, earning its place.

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

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

Given the tool's complexity and the presence of an output schema, the description adequately covers what it returns (rank, percentile, ranking_score, etc.) and behavior. It is mostly complete but could benefit from mentioning pagination behavior.

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

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

Schema coverage is 100%, so baseline is 3. The description lists parameters (product, underlying_ticker, source_date, etc.) but adds no new meaning beyond the schema. It does not compensate for any gaps.

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: to rank Coinbase INTX perp products by the latest market_alpha row per product. It specifies the resource (Coinbase perp rankings) and action (rank), differentiating it from sibling tools like deltasignal_coinbase_perp_factors.

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 lists parameters and mentions read-only behavior but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites or when not to use it, which is a gap.

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. Description adds further context: 'performs one HTTPS read, has no destructive side effects, does not modify SEC data, accounts, files, or wallets.' 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?

Two well-structured paragraphs. First states purpose and parameter summary; second explains behavior and usage guidance. No 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 4 parameters, output schema, and rich annotations, description fully covers purpose, parameter details, behavioral traits, and usage context. Output schema handles return format, so no gap.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds value by summarizing parameters and noting behavior like returning availability metadata for optional containers, which goes 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 it retrieves SEC XBRL-backed fundamentals for one crypto public company ticker, listing return contents and differentiating from siblings like alpha_signals and covenant_stress for modeled signal interpretation.

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 specifies when to use this tool (e.g., user asks for revenue, net income, filing context) and when to use alternatives (alpha_signals or covenant_stress for modeled interpretation). Also notes read-only and idempotent behavior.

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. The description adds behavioral details: 'performs six internal HTTPS reads', 'rejects invalid tickers before fan-out', 'preserves partial results if a required issuer leg fails', which go beyond annotations. 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 approximately 150 words, front-loaded with purpose, then lists components, parameters, behavior, and usage. Every sentence adds value; no fluff or repetition.

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

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

Given the tool complexity (composite workflow with 5 params and an output schema), the description covers internal structure (6 legs), error handling, and parameter usage. It does not describe the output format explicitly, but an output schema exists, so this is acceptable. Minor gap: no mention of pagination or size limits.

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 baseline is 3. Description adds meaning: ticker normalization to uppercase, period format (YYYY-MM-DD), output_mode restriction to compact in Phase 1, and explanation of boolean flags. This provides 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 it is a 'read-only composite workflow tool for the default full single-issuer DeltaSignal ATLAS-7 company report add-on', specifying verb (compose report), resource (single ticker), and scope. It distinguishes from siblings by listing its components and contrasting with low-level drilldown 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?

Explicit usage guidance: 'Use it when the user asks for a report, deep dive, issuer brief, or diligence package on one crypto public-company ticker, or when a Morning Brief top-stressed or alpha-screen row needs a separately sold explanation report; use low-level tools only for custom drilldowns'. Provides clear context and 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 read-only, idempotent, non-destructive. The description adds specific behavioral traits: local MVP, no SEC identity minting, no inference from prose, no wallet calls. It also describes the output packet contents. No contradictions with annotations.

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

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

The description is a single, well-structured paragraph that front-loads the purpose, then lists key parameters, then behavioral notes, then output. Every sentence adds value, but it is slightly verbose with the list of output components.

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 18 optional parameters and the presence of an output schema, the description provides a clear scope, default behavior, and what the tool does not do. It explains the output packet structure partially, which is adequate since output schema covers details.

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 supplements by highlighting the three key parameters (article_tripcode, filing_tripcodes, ticker) and their default behavior (e.g., ticker=HUT loads default pack). This adds value beyond individual parameter 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 states a specific verb-resource pair (compare article node to filing evidence) and clarifies it's read-only. It distinguishes from generic compare tools by specifying TF-SUB vs TF-XBRL, but does not explicitly contrast with the similar sibling 'deltasignal_compare_claim_to_evidence'.

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 article-to-filing comparison and notes the default HUT behavior, but it lacks explicit when-to-use or when-not-to-use guidance versus other sibling tools like 'deltasignal_compare_claim_to_evidence'.

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 reiterates these and adds the important behavioral detail that the tool returns specific verdicts without inventing evidence, which is 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 two sentences that front-load the purpose and behavior, with no unnecessary words. The parameter hint is integrated efficiently.

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 complexity (14 parameters), good annotations, and presence of output schema, the description covers the essential aspects: purpose, behavior, return categories, and basic parameter usage. It is complete enough for an agent to invoke correctly, though additional parameter synergy details could be helpful.

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 minimal parameter semantics beyond the schema, only grouping parameters for use. It does not clarify the interplay among the many optional parameters beyond the basic combination hint.

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 verb 'compare' and the resource 'claim to River claim records and evidence refs', and it mentions specific outcomes (confirmed, weakened, unresolved, new_claim). This distinguishes the tool from siblings, many of which have different purposes.

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

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

It provides clear usage context ('Use this read-only tool to compare a claim...') and gives parameter combination hints ('pass claim_text or query plus river_tripcode or issuer'). However, it does not explicitly mention when not to use this tool or suggest alternatives among the many siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these by stating 'read-only and idempotent; it performs one HTTPS read, has no destructive side effects' and further describes return data (stress, headroom, etc.). This adds useful behavioral context beyond annotations.

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

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

The description is concise at about 5 sentences, front-loading the main purpose and mode distinction. Every sentence adds value – no redundancy or fluff. It efficiently covers purpose, usage, behavior, and alternatives.

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 (10 parameters, no required, output schema exists, rich annotations), the description covers all key aspects: two modes, filter behaviors, read-only nature, return data summary, and sibling tool guidance. It is complete enough for effective tool selection and invocation, though it could optionally detail output schema fields.

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

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

Schema description coverage is 100%, so the baseline is 3. The description summarizes parameter roles (ticker for detail, filters for list mode) but does not add significant meaning beyond what the schema already provides. The added usage context is adequate but not exceptional.

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 ATLAS-7 covenant stress analysis on crypto public companies. It specifies two modes (single-issuer detail via ticker, or screening the universe with filters) and explicitly distinguishes from sibling tools (top_stressed, peer_ranking, 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?

The description provides explicit guidance on when to use this tool vs. alternatives: 'Use top_stressed for the default ranked universe, peer_ranking for relative peer context, and alpha_signals when the user asks for opportunity or edge rather than covenant stress.' It also explains the detail vs. list mode behavior and filter 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 declare readOnlyHint and idempotentHint. The description adds significant behavioral details: it performs one HTTPS read, has no destructive side effects, and explicitly states it never infers breach or risk unless evidenced. 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 well-structured with a clear purpose, parameter details, and behavioral notes. It is slightly verbose but every sentence adds value. Front-loading the intended use is 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 complexity (3 params, high schema coverage, output schema exists), the description fully explains what the tool does, what it returns (Markdown brief with specific content), and its limitations (no inferences). No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning by explaining that 'period' maps to the evidence period and 'style' has specific values (professional, concise, trader, detailed) and notes that style only changes tone not facts.

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 briefs on ticker-specific covenant stress evidence. It distinguishes from siblings like deltasignal_covenant_stress (raw data) and deltasignal_top_stressed_natural (different scope) by specifying ticker-specific natural language output.

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

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

The description begins with 'Use this premium read-only Natural Language tool when...', providing clear context for when to invoke it. It does not explicitly name alternatives or when-not to use, but the use case is well-defined.

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 internal details: 'performs one internal daily-changes read, filters evidence for one issuer/change.' This goes beyond annotations without contradicting them, explaining the single-read 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 three sentences, front-loaded with purpose and usage condition, then parameters, then behavior. Every sentence adds value, 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?

With 5 parameters fully documented, rich annotations, and an output schema present, the description covers all necessary context: when to use, what it returns, and behavioral guarantees. 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?

Schema description coverage is 100%, but the description adds value by summarizing that ticker or cik is required (though schema says none required), explaining limit defaults and cap, and describing offset pagination. This clarifies usage 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?

The description clearly states the tool is a read-only drilldown for when a user asks why an issuer or CIK was flagged in daily changes. It specifies the action (drilldown), resource (daily change evidence), and distinguishes from sibling tools like deltasignal_daily_changes.

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: 'only when the user asks why one issuer or CIK was flagged in daily changes.' It also provides a clear exclusion: 'Do not use it for routine monitoring, Morning Brief, or Alpha Sweep unless the user explicitly asks for proof.' This gives excellent guidance on 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?

Description adds specific behavioral details beyond annotations: 'performs one HTTPS read, has no destructive side effects, does not write notifications, files, accounts, or wallet state'. Annotations already had readOnlyHint, idempotentHint, destructiveHint; description enriches with network and side-effect context.

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

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

Description is slightly lengthy but front-loaded with purpose and efficient comma-separated list of highlights. Sentences are structured logically: purpose, usage, behavior, alternatives. Could be tightened slightly but still clear.

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 0 parameters, rich annotations, and existence of output schema, the description fully covers purpose, usage, behavior, and alternatives. It explains what the output contains (highlights), which complements 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?

No parameters defined, and description states 'Parameters: none; call it exactly as-is'. Schema coverage is 100% trivially. Baseline for 0 params is 4, and description adequately handles the absence.

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