DeltaSignal ATLAS-7

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description reinforces this and adds specific behavioral details: a single HTTPS read, no side effects, and no handling of wallets or orders. 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 concise at 8 sentences, front-loaded with purpose, then parameter details, then behavior. Every sentence contributes meaning without redundancy.

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

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

Given the tool's complexity (7 parameters, no required params, complete schema coverage, annotations, and output schema), the description covers purpose, parameter usage, behavior, and limitations. It is comprehensive for an AI 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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining the limit range, source_date replay, and how each filter narrows results. It also provides usage context for include_funds and issuer_type.

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 the DeltaSignal issuer universe by alpha score. It specifies the output fields and distinguishes it from siblings by emphasizing its read-only screening nature and specific parameter options.

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 guidance on when to use parameters like include_funds and issuer_type, and notes the default behavior. It also cautions that high scores are drilldown candidates, not conclusions. However, it does not explicitly contrast with sibling tools like deltasignal_alpha_signals.

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

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

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

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

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

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

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

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

Given 4 parameters and an output schema (not shown), the description fully covers purpose, behavior, parameter details, and usage scenarios. It is comprehensive for the tool's complexity.

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

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

Schema coverage is 100% with descriptions. The description adds semantic context beyond schema: e.g., limit is 1-100 for bounded samples, source_date replays a known slice, issuer_type narrows audit, include_rows should be used only for explicit debugging.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds operational details: 'performs one HTTPS read, has no destructive side effects, does not trade, does not store user data, and does not handle wallet secrets.' This goes beyond annotations but some context (e.g., idempotency) is already hinted.

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 tightly-written paragraphs with front-loaded purpose. Every sentence earns its place: no fluff, clear structure covering purpose, parameters, behavior, and usage guidelines.

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 (alpha signals, optional replay date, many siblings), the description covers all necessary aspects: return content, parameter usage, behavioral safety, and guidance for alternatives. Output schema exists, so return values need not be detailed.

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: explains ticker normalization and that source_date should be used 'only to replay a known historical DeltaSignal slice,' which clarifies its purpose beyond format constraints.

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') and resource ('DeltaSignal ATLAS-7 alpha signals for one crypto public company ticker'), and differentiates from siblings by mentioning specific alternatives later (covenant_stress, company_fundamentals).

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

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

Explicitly states when to use ('research triage on supported public-company tickers'), when not to use ('do not pass crypto asset symbols unless they are listed public-company tickers'), and provides specific alternative tools (readiness, covenant_stress, company_fundamentals).

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 significant behavioral context beyond annotations: it explains the tool performs three internal HTTPS reads, is idempotent and read-only, has no side effects, never calls issuer-level tools, and preserves partial results on failure. This aligns with and enriches the annotations (readOnlyHint, idempotentHint, destructiveHint).

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 front-loaded purpose. It includes all necessary details without excessive verbosity. Minor redundancy (e.g., 'read-only' mentioned twice) could be trimmed, but overall it is concise and organized.

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

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

Given the tool's complexity (composite, internal calls, partial failure) and the availability of output schema, the description provides complete guidance: what it does, how it works internally, when to use it, what parameters to avoid, and how to interpret the result as a screen requiring further drilldown. 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 coverage is 100%, so baseline is 3. Description adds value by clarifying that only 'compact' is accepted for output_mode and explicitly forbids passing other parameters (limit, offset, etc.) even though they are not in the schema. This prevents misuse.

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 for alpha screening across the DeltaSignal issuer universe, specifying the internal call plan (readiness, alpha_opportunities, daily_changes). It distinguishes from sibling tools like deltasignal_alpha_opportunities by noting it enforces a preset call plan and does not accept issuer-level filters.

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 alpha opportunities, opportunity sweep, clean alpha board, or names worth follow-up research.' It also clearly states which parameters must not be passed (limit, offset, ticker, source_date, issuer filters) because the tool owns them internally. This helps the agent avoid incorrect invocations.

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 significantly adds to the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) by detailing specific behaviors: it resolves article objects, compares filing evidence, marks missing evidence, returns eight thesis-map sections, and explicitly states what it does not do (call Grok, invent evidence, mutate storage, treat TripCodes as SEC identities). This provides comprehensive transparency beyond the structured annotations.

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

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

The description is front-loaded with the core use case and contains multiple sentences that each add unique information (purpose, parameter hints, behavioral guarantees, limitations). It is well-structured and avoids redundancy, though the length is justified by the tool's complexity and number of parameters. It could be slightly tightened without losing 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?

Given the tool's complexity (25 optional parameters, output schema present, rich annotations), the description covers all necessary aspects: what the tool does, when to use it, key parameters, behavioral guarantees, and what it does not do. The presence of an output schema reduces the need to describe return values, and the description fills remaining gaps 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 description coverage is 100%, so the baseline is 3. The description highlights the most important parameters (article_tripcode, tripcode, prior_article_tripcodes, linked_xbrl_tripcodes, filing_tripcodes, ticker) and mentions the special HUT behavior. This adds context but does not explain individual parameter meanings beyond what the schema already provides. The description adds marginal value.

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: it generates a thesis map from a DeltaSignal article TripCode. It specifies the trigger ('when a subscriber gives... an article TripCode and asks for the thesis map') and the resource (the article). This distinguishes it from sibling tools like deltasignal_alpha_opportunities or deltasignal_compare_article_to_filing_evidence, which serve different functions.

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 context for when to use the tool: when a subscriber requests a thesis map given an article TripCode. It identifies the primary parameters (article_tripcode or tripcode) and optional ones (prior_article_tripcodes, linked_xbrl_tripcodes, filing_tripcodes, ticker). It also mentions a special case for HUT. However, it does not explicitly state when not to use this tool or suggest alternatives, which would improve 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 indicate readOnlyHint, idempotentHint, destructiveHint. The description reinforces these and adds specific context: no destructive side effects, does not run the audit, mutate data, or access raw issuer evidence. This adds value beyond annotations.

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

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

The description is a single well-structured paragraph, front-loaded with the main purpose. It is concise but thorough, using each sentence to add essential information without redundancy.

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

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

Given the presence of an output schema (so return values are covered there) and rich annotations, the description fully covers purpose, usage, and behavioral traits. No gaps remain for this simple parameterless tool.

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

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

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

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

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

The description clearly states the tool checks ATLAS-7 audit health, reads the latest audit summary from Azure Blob, and lists the reported fields. It distinguishes itself from sibling tools by being a read-only status check rather than running the audit or accessing raw data.

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

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

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

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

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

Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds that it assembles from precomputed surfaces and performs no wallet/settlement/trading actions. This provides useful behavioral context without contradicting annotations.

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

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

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

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

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

The description covers purpose, usage, parameters, and behavior. With an output schema present, it doesn't need to detail return structure. It could mention pagination more explicitly, but the parameter descriptions handle that.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Given output schema exists, description does not need to explain return values. It covers key behaviors, parameter usage, universe size, and drill-down guidance. Complete for a retrieval tool with rich annotations.

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

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

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

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

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

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

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

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

Description provides explicit usage context: 'Use this for Mirror Pulse or ATLAS-7 historical joins when you need the compact issuer-level CompanyFacts inventory'. It does not explicitly mention when not to use or name alternative tools, but the context is clear enough for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: it performs one HTTPS read, no NLP, no trades/wallets/settlements. This additional detail enhances transparency without contradicting the annotations.

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

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

The description is a single paragraph of five sentences, front-loaded with purpose and usage. Every sentence adds necessary detail without redundancy. It is efficient and well-structured for an AI agent to parse.

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

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

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

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

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

Schema coverage is 100%, so the baseline is 3. The description restates parameters and adds usage advice for mode (compact vs full), but does not significantly augment the meaning beyond what the schema provides. The added guidance on mode selection earns it a 3 rather than a 2.

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

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

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

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

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

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

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

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

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

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

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

The description is a single paragraph that efficiently communicates purpose, parameters, and behavior. It is front-loaded with the main action. While compact, it includes necessary detail without redundancy.

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

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

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

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

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

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

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

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

The description clearly states the tool retrieves 'historical ATLAS-7 covenant and stress series for one crypto public company ticker', using specific verbs and resources. It distinguishes from siblings by mentioning unique use cases like mNAV backtests and Mirror Pulse joins, which are not covered by similarly named tools such as deltasignal_atlas7_point_in_time_history.

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

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

The description provides explicit use cases: 'when the user needs historical ATLAS data, MSTR/Strategy time series, mNAV backtests, Mirror Pulse joins, or dated stress/risk snapshots.' It does not explicitly mention when not to use or name alternative tools, but the context is clear enough for an agent to decide.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that it performs one HTTPS read, has no destructive side effects, and does not modify SEC data, accounts, files, or wallets. No contradiction, and extra context reinforces safety.

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 parameters, then behavior, then usage guidance. It is slightly verbose but each sentence adds value. Could be tightened but still 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?

The description covers all important aspects: what data is returned, parameter details, behavior (read-only, idempotent), usage context, and sibling differentiation. Output schema exists so return format is documented. Fully adequate.

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 nuance by explaining that include_segments and include_related_party return availability metadata even when facts are not populated, and that period is optional with default latest filing. This goes beyond schema.

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

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

The description clearly states the tool retrieves SEC XBRL-backed fundamentals for one crypto public company ticker. It enumerates specific data returned (filing period, identifiers, core financial values, provenance, optional containers), and distinguishes from sibling tools like alpha_signals and 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 specifies when to use this tool (revenue, net income, assets, cash, liabilities, equity, SEC filing context, fact provenance) and when to use alternatives (alpha_signals, covenant_stress). No ambiguity.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds specific behavior: performs six internal HTTPS reads, rejects invalid tickers before fan-out, preserves partial results on leg failure. 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 dense paragraph that front-loads purpose and then details parameters and behavior. It is efficient, though slightly long; every sentence adds value.

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

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

Given the tool has an output schema (not shown) and detailed input schema with 100% coverage, the description covers behavior, usage, parameter details, and edge cases (e.g., partial results). It is fully complete for an AI 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%, so baseline is 3. Description adds minor context: ticker normalization to uppercase, optional parameters listed, SPECTRA inclusion condition. This adds some value but does not significantly deepen understanding beyond the schema.

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

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

The description clearly states it is a composite workflow tool for the default full single-issuer DeltaSignal ATLAS-7 company report. It specifies the scope (single issuer, full report) and implicitly distinguishes from lower-level sibling tools for custom drilldowns.

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

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

Explicitly states when to use: for report, deep dive, issuer brief, diligence package, or when Morning Brief rows need explanation. Also says to use low-level tools only for custom drilldowns, providing clear 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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context beyond annotations: 'no destructive side effects, does not mint official SEC identity, does not infer filing evidence from prose, and does not call wallets or x402 settlement.' This fully discloses behavioral traits.

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 but front-loads the purpose and key behaviors. It is concise given the complexity (18 parameters). However, structure could be improved with bullet points or separation of parameter notes and behavior notes, but the current form avoids verbosity.

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 parameters and an output schema (true), the description covers the main use case (HUT MVP), return value composition, and constraints. It lacks guidance on error handling or behavior when article_tripcode is omitted, but overall it provides sufficient context for an AI agent to 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 coverage is 100% with descriptions for all 18 parameters. The description adds value by summarizing default behavior (e.g., ticker=HUT loads default pack, filing_tripcodes optional). While it doesn't explain each parameter in detail, it complements the schema well.

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: 'compare a TF-SUB article node against resolved TF-XBRL filing evidence objects'. It uses specific verb-resource pairing and distinguishes from siblings by specifying read-only comparison. The mention of HUT MVP default behavior adds clarity.

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 outlines parameters and defaults (article_tripcode optional, filing_tripcodes for one or more objects, ticker=HUT loaded default pack). It explains idempotent and local behavior. However, it does not explicitly exclude use cases or contrast with sibling comparison tools like 'deltasignal_compare_claim_to_evidence', which would improve guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'read-only with no destructive side effects' is consistent. Additional value comes from stating the return categories ('confirmed, weakened, unresolved, or new_claim') and explicitly noting it does not 'invent evidence', which is beyond the annotation metadata.

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 (approximately 40 words) with no filler. It front-loads the primary purpose and read-only nature, then efficiently covers parameter combinations and behavior. Every sentence is informative and earns its place.

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

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

Given the output schema exists, the description does not need to detail return types, but it still lists the outcome categories. It covers purpose, parameter guidance, behavioral safety, and expected results. With 14 optional parameters and high schema coverage, the description provides sufficient context for an agent to decide when and how to invoke the tool.

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

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

The input schema has 100% parameter description coverage, so each parameter is individually documented. The description adds meaning by grouping required-optional patterns ('pass claim_text or query plus river_tripcode or issuer'), which helps the agent understand valid parameter combinations. This spatial guidance adds value beyond the isolated 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 compares a claim to River claim records and evidence refs, uses a specific verb (compare), and specifies the resource (claim vs River records). It also lists possible outcomes (confirmed, weakened, unresolved, new_claim), making the purpose unambiguous. While sibling differentiation is not explicit, the other 'compare' sibling ('deltasignal_compare_article_to_filing_evidence') targets different sources, so the scope is 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?

The description advises this is a 'read-only tool' and suggests parameter combinations ('pass claim_text or query plus river_tripcode or issuer'), which gives some usage context. However, it does not specify when to avoid this tool or mention alternative tools like 'deltasignal_search_by_claim' or 'deltasignal_compare_article_to_filing_evidence', leaving the agent to infer usage boundaries.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context: 'it performs one HTTPS read, has no destructive side effects, and does not change filings, portfolios, wallets, or account state.' This reinforces safety and provides operational detail.

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

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

The description is well-structured, starting with purpose and mode selection, then parameters, behavior, and alternatives. It is front-loaded and informative, though slightly verbose. Every sentence contributes meaning.

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, two modes, output schema exists), the description thoroughly covers both modes, explains filtering, mentions output fields, and lists alternatives. It is 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 description coverage is 100%, so baseline is 3. The description adds value by explaining that ticker selects detail mode and that without it, list-mode filters apply. It provides ranges (min_stress 0-100) and usage tips ('Use 10-25 for concise screens'). This exceeds baseline.

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

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

The description clearly states it is for ATLAS-7 covenant stress analysis on crypto public companies, with specific verb 'analyze' implied. It distinguishes two modes (detail with ticker, list without ticker) and mentions specific outputs. Among siblings, it differentiates itself by naming alternatives like top_stressed and peer_ranking.

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

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

The description explicitly says when to use each mode and provides 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.' This is excellent 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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds valuable context: 'read-only and idempotent; it performs one HTTPS read... has no destructive side effects, and never infers covenant breach, default risk, insolvency, liquidity crisis, or trade direction unless returned by evidence.' This goes beyond annotations.

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

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

The description is a single dense paragraph that front-loads purpose. Every sentence serves a purpose; it is not overly long. Some structuring could improve readability, but it is concise enough for the content.

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

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

Given the annotations cover safety, an output schema exists (not detailed here), and parameters are documented, the description is largely complete. It covers purpose, usage, behavior, and parameter mapping. It does not detail output format, but that is handled by the output schema.

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

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

Schema coverage is 100% with descriptions for each parameter. The description mentions parameters (ticker required, date optional, style options) but adds only marginal value, such as explaining style affects tone/density. Baseline 3 is appropriate.

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

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

The description explicitly states it is a 'premium read-only Natural Language tool' for 'ticker-specific covenant stress evidence explained in human-readable Markdown.' It specifies the data sources (ATLAS-7 covenant, leverage, etc.) and differentiates from sibling tools like 'deltasignal_covenant_stress' which likely returns structured data.

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

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

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

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

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

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

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

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

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

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

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

Given the presence of an output schema and rich annotations, the description covers all necessary aspects: purpose, usage constraints, parameter behavior, and side-effect profile. It is complete for the tool's complexity.

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

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

Schema description coverage is 100%. The description reiterates key details: ticker or cik required, source_date optional, limit defaults to 100 and capped at 250, offset for pagination. This adds practical context beyond the schema.

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

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

The description clearly states the tool is a 'read-only drilldown tool' for explaining why an issuer or CIK was flagged in daily changes. It distinguishes from sibling tools like deltasignal_daily_changes and explicitly defines its narrow scope.

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

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

Explicitly states 'only when the user asks why one issuer or CIK was flagged in daily changes' and warns against using for 'routine monitoring, Morning Brief, or Alpha Sweep unless the user explicitly asks for proof.' This provides clear when-to-use and when-not-to guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specific details: 'performs one HTTPS read, has no destructive side effects, and does not write notifications, files, accounts, or wallet state.' No contradiction.

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

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

The description is a single, well-organized paragraph that front-loads purpose, lists contents, gives usage, explains behavior, and offers alternatives. Every sentence adds value without redundancy.

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

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

Given no parameters, comprehensive annotations, and an existing output schema, the description fully explains the tool's purpose, contents, and usage boundaries. No gaps remain for an agent to decide when to invoke it.

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

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

No parameters exist, and schema coverage is 100%. Description states 'Parameters: none; call it exactly as-is,' which is clear but adds little beyond the schema. Baseline score of 4 applies per guidelines.

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 the latest DeltaSignal daily change snapshot, listing specific contents like crypto filing deltas and new issuers. It distinguishes from siblings by mentioning use of 'readiness' for service health and 'issuer-specific tools' for detailed research.

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

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

Explicitly says 'call it exactly as-is when the user asks what changed today or needs a monitoring summary.' Provides clear alternatives: 'use readiness for service health and issuer-specific tools for detailed research on any ticker it mentions.'

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 reiterates idempotent, local, no side effects, and specifies operations it avoids (Azure Blob, Substack mutation, wallets, x402 settlement), adding valuable 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?

Single paragraph is well-structured: purpose, identity parameters, metadata note, behavior, and return usage. Every sentence earns its place with no fluff.

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

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

For a tool with 24 parameters and an output schema, the description covers purpose, identity parameters, behavioral constraints, and how to use the return values (TripCode in subtitle, blob paths in pipeline). Sufficient for correct invocation.

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

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

While schema has 100% coverage, the description groups parameters into identity-defining (issuer/ticker, title, research_slug, research_date, version) vs. publication metadata (post_id, canonical_url, slug, published_at) that do not affect TripCode, adding significant semantic value beyond individual descriptions.

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

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

The description clearly states it generates a deterministic TF-SUB resolver object for DeltaSignal-owned articles/narrative research nodes, distinguishing it from siblings like resolve and list tools.

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

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

Explicitly labels itself as a read-only identity tool and lists what it does not do (write Azure Blob, mutate Substack, etc.), providing good usage context. Lacks explicit 'when not to use' or direct alternatives, but the purpose is clear enough.

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 value by stating it does not modify SEC filings, call wallets, or replace accession numbers, providing 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 verbose (multiple sentences) and includes parameter details already in the schema. It could be more concise by focusing on purpose and behavior rather than repeating parameter info.

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 15 parameters, full schema coverage, output schema exists, and thorough annotations, the description covers purpose, behavior, and examples. Minor gap is lack of sibling differentiation, but overall 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%, so baseline is 3. The description adds some usage guidance (e.g., ticker=HUT seed object) but does not significantly supplement the existing 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 it generates a deterministic TF-XBRL resolver object for a DeltaSignal evidence object. It provides specific usage examples (ticker=HUT). However, it does not explicitly distinguish from similar sibling tools like deltasignal_generate_article_tripcode or deltasignal_resolve_filing_tripcode.

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

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

The description gives context on when to use (e.g., with ticker HUT or explicit fields) and implies it is for generating identifiers. It does not explicitly state when not to use it or mention alternatives like resolver 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich detail: server-enforced evidence plan, bounded internal fan-out, partial failure preservation, and explicit missing evidence reporting. This goes well beyond what annotations provide.

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

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

The description is comprehensive but efficient, front-loading purpose and usage context before listing evidence plan and behavior. All sentences contribute necessary information, with no redundancy or fluff despite the complexity of the tool.

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

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

With an output schema present, the description covers purpose, usage context, parameter semantics, behavioral details, and error handling (missing evidence reporting). It is fully adequate for an AI agent to correctly select and invoke the tool.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds value by summarizing key parameters (ticker normalized to uppercase, optional date controls for reproduction, output_mode=compact) and their roles, going beyond the schema's individual descriptions.

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

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

The description clearly identifies the tool as a composite workflow for paid, filing-backed issuer drilldowns when causality is needed beyond a headline score. It distinguishes from sibling tools by specifying it aggregates multiple evidence sections (readiness, fundamentals, covenant stress, etc.) and targets GME-style deep analysis.

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

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

The description explicitly states when to use: 'when a daily brief pressure or opportunity row needs causality, not just a headline score' and implies it's for paid reports. It doesn't explicitly list exclusions but contrasts with simpler tools, providing adequate guidance for an AI agent.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these by stating 'read-only and River-root-first with no destructive side effects' and adds detail about how missing nodes are handled, adding some value beyond annotations.

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

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

The description is relatively concise for the complexity, front-loading purpose and behavior. It uses a list-like structure for parameters and clearly separates behavior notes. Could trim a few words, but overall 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 the tool's complexity (10 optional parameters), presence of annotations and output schema, the description provides all necessary context: purpose, usage guidance, behavioral traits, and parameter grouping. It is complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so description doesn't need heavy parameter detail. The description groups parameters (e.g., 'pass current_tripcode, article_tripcode...') and notes default values (object_type, include_unpublished, limit), providing useful context beyond the schema's individual descriptions.

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

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

The description clearly states it is a 'read-only resolver to discover TF-SUB article nodes' using various inputs like TripCodes or issuer lookups. It specifies the verb 'discover' and resource 'TF-SUB article nodes', distinguishing it from siblings like resolve_article_tripcode or article_thesis_map.

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 advises using this tool 'before article_thesis_map' to avoid manual pasting of old River TripCodes. It also clarifies that missing nodes are returned in 'missing_or_unresolved' rather than inferred, providing clear guidance on when and how to use it.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds valuable context: bounded internal fan-out, preserves partial results on failure, and server-enforces the call plan. 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?

Concise at ~120 words, with front-loaded purpose and logical flow: use case, internal calls, parameter restrictions, behavior, usage scope. Every sentence earns its place.

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

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

Given the tool's complexity (composite workflow with multiple sub-calls), the description fully covers its purpose, restrictions, behavior, and usage context. Output schema exists, so return format is not 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 coverage is 100% with one parameter (output_mode) already described. Description only restates 'optional output_mode=compact only', adding marginal context about Phase 1. 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 identifies the tool as a read-only composite workflow for the DeltaSignal ATLAS-7 daily scan, lists the internal calls it executes, and distinguishes it from sibling tools like deltasignal_company_report or deltasignal_issuer_deep_report by specifying its use case.

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 (morning brief, daily brief, daily scan, etc.) and when not to use (sell company-report or deep-brief separately). Also warns against passing certain parameters because the preset owns them internally.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it performs a server-enforced workflow, has no destructive side effects, and produces a bounded response. This adds valuable context beyond annotations, but could mention error handling or performance traits.

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 informative but somewhat verbose, with a mid-sentence parameter listing that could be streamlined. It front-loads the purpose well but includes redundant details about parameters already clear from schema. Moderate 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 the presence of an output schema and annotations, the description covers the tool's core behavior, constraints, and output format (Markdown). It omits error handling or specific response structure, but those are likely in the output schema. Completeness is good for a read-only tool with rich contextual signals.

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 that style changes tone/density only (not facts) and that date/limit are conditional on backend support. This provides meaningful nuance beyond the schema's types and descriptions.

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

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

The description clearly states the tool renders the server-composed Morning Brief as audit-grade Markdown. It distinguishes from siblings by noting it never fans out into tools or generates social drafts/trade recommendations, making the purpose unambiguous.

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

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

The description explicitly says to use this tool when the user wants the Morning Brief rendered as Markdown. It lists what it does not do (no fan-out, no social drafts, no trade recommendations), implying alternatives exist. However, it does not explicitly name the sibling tool for structured data, so slightly less clear on when not to use.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds context: performs one HTTPS read, no side effects, no external writes. Consistent and additive.

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?

Concise and well-structured: purpose, returns, parameters, behavior, usage. Every sentence adds value; no fluff.

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

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

Output schema exists; description lists returns. Covers behavior, parameters, and usage alternatives. Fully adequate for the tool's complexity.

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

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

Schema coverage is 100% with good descriptions. The description adds minimal extra meaning (e.g., period for reproducing filing date). Baseline score 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 clearly states it compares one crypto public company against its peer group and lists specific return fields. It distinguishes from siblings like covenant_stress and top_stressed.

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 whether one issuer is better or worse than peers') and provides alternatives for absolute stress, universe-wide ranking, and opportunity signals.

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 (readOnly, idempotent, non-destructive), description adds that it performs three internal HTTPS reads, preserves partial results, and never calls issuer-level tools. These details are not in 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 detailed but each sentence adds value. Front-loaded with purpose. Could be slightly more concise, but still 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 it's a composite workflow with an output schema, the description explains purpose, parameters, internal behavior, and usage context thoroughly. 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 already describes output_mode as optional and only compact accepted. Description adds constraints on what not to pass (limit, offset, etc.). Schema coverage is 100%, so baseline is 3, but description adds meaningful constraints beyond 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's a read-only composite workflow for risk/stress monitoring, listing its components (readiness, top_stressed with limit 15, risk_distribution). This distinguishes it from sibling tools like deltasignal_readiness, deltasignal_top_stressed, and deltasignal_risk_distribution.

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

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

Explicitly states when to use: when user asks for risk monitoring, pressure board, etc. Also advises against passing certain parameters. Does not explicitly mention alternatives, 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?

The description adds context beyond annotations: 'read-only and idempotent; calls bounded morning brief composite; no destructive side effects; removes internal-only identifiers; preserves non-advice language; returns deterministic HTML plus copy_text.' 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 structured with a clear lead sentence followed by parameter constraints and behavioral details. While slightly verbose, every sentence adds value and it is well 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 the single optional parameter, existing annotations, and the mention of an output schema, the description covers purpose, usage, behavior, and parameter constraints thoroughly with no evident 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% for the single parameter output_mode. The description adds that only 'compact' is accepted and warns against passing other parameters like ticker or limit, clarifying the preset's internal control.

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 renderer' for 'DeltaSignal Daily Brief artifacts' and details the outputs: HTML brief and copy-ready text with explanations. It distinguishes itself from siblings like deltasignal_morning_brief by being public-safe.

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

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

The description explicitly lists use cases: 'when the user asks for a public daily brief, customer-facing daily brief, investor-ready risk and opportunity scan, or copy-ready DeltaSignal article.' It also specifies parameters not to pass. However, it does not mention when not to use or provide alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds beyond that: it performs three internal HTTPS reads, rejects invalid tickers before fan-out, preserves partial results on leg failure, and server-enforces the call plan. 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 thorough yet concise. It opens with purpose in the first sentence, then covers behavior, usage, and constraints. Each sentence adds value; no fluff. Could be slightly shorter but still 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?

With output schema present and rich annotations, the description still adds necessary context: it explains the composite workflow, the partial-results behavior, and the server-enforced plan. For a tool with this complexity, it is 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%, so baseline 3. The description adds meaning: ticker normalization and whitespace trimming, explicit constraint that output_mode only accepts 'compact'. This provides behavioral detail beyond the schema's property 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 uses specific verb ('sanity check') and defines the exact resource scope (single ticker, composite of readiness/covenant_stress/alpha_signals). It explicitly distinguishes itself from full company-report tools by listing what is excluded (fundamentals, peer ranking, SPECTRA), making sibling differentiation clear.

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

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

The description states when to use (fast single-ticker check) and what user queries it addresses (e.g., 'is one ticker clean, stressed, actionable, or needs deeper diligence'). It also lists what is intentionally excluded, implying when not to use, though it does not explicitly name alternative sibling tools.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral context: performs one HTTPS read, no destructive side effects, no external writes, no secrets or payments. No contradiction. Adds some 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?

Description is concise yet comprehensive, front-loaded with purpose and usage. Every sentence adds distinct value, no fluff. Structured logically from purpose to usage to behavior.

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

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

With no parameters, existing annotations, and an output schema, the description adequately covers when to use, behavior, and return fields. No gaps remain for an AI agent to select and invoke the tool correctly.

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

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

No parameters exist (0 params, schema coverage 100%). The description states 'Parameters: none; call it exactly as-is'. Baseline for 0 params is 4.

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 verifying DeltaSignal ATLAS-7 data plane readiness, listing specific return values. It distinguishes from siblings by noting that it should be used before analysis, while other tools like daily_changes or issuer tools are for 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?

Explicitly specifies when to use ('start of an agent workflow, after a deploy, or whenever results should be gated on freshness') and when not to ('use daily_changes for what changed and issuer tools for company-specific analysis'). Also clarifies it is read-only and idempotent.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specific context: no mutation of Azure Blob, Substack, filings, wallets, or account state. No contradiction.

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

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

Concise, front-loaded with purpose, each sentence adds value. No redundancy.

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

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

Tool has moderate complexity with one parameter and output schema present. Description covers input format, idempotency, and non-destructive behavior. No need to explain return values due to output schema.

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

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

Schema coverage is 100% with detailed schema description. Description adds an example format for the tripcode parameter, which is helpful but not extensive; baseline 3, slight improvement to 4.

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 loads a TF-SUB article/narrative research object, specifies the verb 'load' and resource, and distinguishes from sibling tools by focusing on article tripcodes.

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 a subscriber provides a TripCode from an article subtitle and requests the machine-readable object. Implicitly excludes other tripcode types via sibling 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 read-only, idempotent, non-destructive. Description adds context: idempotent and local for MVP, no mutation of SEC filings, no wallet/x402 calls, returns HUT seed objects.

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?

Concise and well-organized: opens with purpose, lists required param, behavioral guarantees, and usage scenario. No redundant sentences.

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, description covers all necessary aspects: purpose, parameter detail, behavioral traits, and usage context. Complete for a single-parameter resolver tool.

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

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

Schema covers 100% of parameter definition. Description adds example format and constraints (e.g., 'TF-XBRL-HUT-2026Q1-...') beyond the schema description, enhancing usability.

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 the tool resolves TF-XBRL TripCodes into SEC/XBRL evidence objects, distinguishing from sibling resolve tools for article and river tripcodes.

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 recommends using before article comparison when a Substack article names a TF-XBRL evidence object, providing clear context. Lacks explicit when-not-to-use or alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing fail-closed behavior and that missing items are reported as missing_or_unresolved, exceeding annotation coverage.

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

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

Three sentences—purpose, parameter list, behavior—each earning its place with zero redundancy. Front-loaded with the core action, then efficient details.

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

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

With 11 optional parameters, no required ones, and an output schema present, the description covers purpose, accepted parameters, and behavioral traits like idempotency and error reporting. Could mention output format but the output schema fills that gap; overall sufficient for the complexity.

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

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

The schema covers 100% of parameters with descriptions, achieving baseline 3. The description adds a narrative overview but does not significantly augment the schema, leaving parameter semantics adequately explained without surplus value.

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 loads a TF-RIVER issuer thesis graph, specifies it is read-only, and distinguishes from sibling resolvers (e.g., deltasignal_resolve_article_tripcode) by mentioning TripCode types and issuer lookup scope.

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

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

While the description lists accepted parameters and notes 'Issuer lookup uses by_issuer only,' it does not explicitly compare with alternative tools like deltasignal_resolve_article_tripcode or provide when-to-use vs when-not-to-use guidance.

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

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

Description adds significant behavioral context beyond annotations: no Grok calls, no mutation, no inventing evidence, no investment advice. Annotations already include readOnlyHint and idempotentHint, but description enriches with specific exclusions.

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 paragraph of 6 sentences, front-loaded with purpose, then parameters, behavior, exclusions. No redundant sentences, efficient and 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 12 parameters and existing output schema, description covers purpose, behavior, exclusions, and return fields. Slight lack of explicit when-to-use vs siblings, but overall 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%, so baseline is 3. Description lists parameters and notes required/optional but adds little beyond schema descriptions, which already detail each parameter.

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

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

The description clearly states the tool is a read-only composite resolver for TripCodes, returning a research packet with article memory, River continuity, etc. It distinguishes itself from simpler resolve tools by being subscriber-facing and 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?

The description says to use it as the default subscriber-facing TripCode tool, implying preference over other resolve tools. However, it does not explicitly state when not to use it or list alternatives, though siblings provide 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds key behavioral details: deterministic graph synthesis, no LLM/trading layer, and that missing evidence remains missing.

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 paragraph (~100 words) that front-loads the purpose, lists parameters, and covers behavior—no wasted sentences.

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 an output schema, the description includes the use case, entry points, output shape ('eight-section thesis-map shape'), and behavioral traits, making it sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists some parameters but does not add new meaning 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 states a specific verb+resource ('reverse search' on 'River') and lists entry points (TripCode, issuer, claim, filing, or current object), distinguishing it from sibling tools that search by issuer or claim alone.

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 describes when to use ('start from... and reconstruct what the River already covered') but does not explicitly mention when not to use or contrast with similar siblings like deltasignal_search_by_claim or deltasignal_search_by_issuer.

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 value beyond annotations by detailing behavior: 'one HTTPS read, no destructive side effects, does not write external systems or access user accounts.' 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?

Three sentences, front-loaded with purpose, then usage, then behavior. No 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?

With no parameters and an output schema, the description covers purpose, usage, behavior, and output format (risk-tier buckets with counts/percentages). Complete for an 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?

No parameters; description correctly states 'Parameters: none; call it exactly as-is.' Baseline for 0 params is 4.

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

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

The description clearly states the tool's verb (summarize), resource (active crypto public company universe by ATLAS-7 risk tier), and output (risk-tier buckets with issuer counts and percentages). It distinguishes from siblings like top_stressed by specifying its unique scope.

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

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

Explicitly states when to use (market-wide risk mix, high-level distribution) and when to use alternatives (top_stressed for high-risk issuers, issuer tools for company-level analysis).

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 value by specifying that missing claim indexes are returned as unresolved, not fabricated, which is a behavioral trait beyond the annotations.

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

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

The description is two sentences long, front-loads the core purpose, and efficiently covers key behavior and parameters without any waste.

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 14 parameters, many sibling tools, and an output schema, the description is fairly complete: it states the action, read-only nature, and a key behavioral trait. It does not explain parameter distinctions, but schema descriptions cover that.

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

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

Schema coverage is 100% with descriptions for all 14 parameters. The description lists five parameter names but does not add new semantic 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 searches one River or claim index for matching thesis claims, using specific parameters. However, it does not differentiate from sibling tools like deltasignal_search_by_issuer or deltasignal_reverse_search_river, so it lacks sibling distinction.

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

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

The description implies usage via 'Use this read-only tool' and lists parameters, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds useful context: 'read-only with no destructive side effects; this is a discovery helper, not a thesis generator.' This reinforces the safety profile and clarifies intent. 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 concise sentences with zero waste. The first sentence immediately states the tool's purpose. The second sentence summarizes parameters and behavior. The structure is front-loaded 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?

Given the output schema exists (as per context signals) and the input schema covers all parameters, the description adequately sets expectations. It explains the tool is read-only and a discovery helper. However, it could mention the output format or that it returns structured data, but the output schema presumably 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?

Schema coverage is 100%, with each parameter having a description, examples, and constraints. The description merely lists parameters in prose ('pass issuer or ticker, optional include_unpublished, and limit') without adding semantics beyond what the 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?

The description clearly states the tool resolves 'issuer index, active TF-RIVER root, and published TF-SUB article nodes.' It specifies the action ('resolve') and the resources, and distinguishes from sibling tools by focusing on issuer-based search. The name 'deltasignal_search_by_issuer' reinforces this.

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 notes this is a 'discovery helper, not a thesis generator,' implying it's for initial research, not analysis. It also mentions its read-only nature. However, it lacks explicit guidance on when to use this tool versus similar sibling search tools like deltasignal_search_by_claim or deltasignal_reverse_search_river.

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?

Despite annotations already providing readOnlyHint, idempotentHint, destructiveHint, the description adds value by specifying 'performs one HTTPS read' and explicitly listing what it does not affect (files, wallets, orders, account state). 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?

Two sentences: first states purpose, second covers parameter and behavior. No wasted words, essential information 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 the simple tool (one parameter, read-only, output schema exists), the description covers purpose, usage, behavior, and parameter adequately. No additional context 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 coverage is 100% with description and examples. The description repeats the required nature and examples but does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

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

Description clearly identifies the verb 'retrieve' and resource 'SPECTRA historical field-map contract' for one crypto public company ticker. This distinguishes it from sibling tools like deltasignal_alpha_opportunities 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?

Explicitly states when to use: 'when the user asks for SPECTRA, field-map, historical pressure, filing choreography, or report-visualization context for a named issuer.' Does not mention when not to use or specific alternatives, but the context is clear given the sibling list.

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 non-destructive write. The description adds significant behavioral context: it is in-memory only, does not call evidence routes, does not execute wallet settlement, and refuses trading instructions. This goes well 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 front-loaded with the core purpose and includes all relevant behavioral notes. It is slightly verbose (e.g., future implementation details) but well-organized and 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 the output schema exists, the description covers purpose, usage context, limitations, and safety comprehensively. It explains the tool's role in the flow and its current capabilities, leaving no major gaps.

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

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

Schema coverage is 100%, so the per-parameter descriptions are already present. The description merely restates which parameters are required/optional without adding new semantics. Meets baseline but provides no extra value.

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 creates an accountless Thesis Monitor object with a capability token, specifying what it stores, returns, and refuses. It distinguishes from siblings like deltasignal_thesis_readiness by positioning it as the create operation for a lightweight MCP/x402 flow.

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 advises using it after thesis readiness for a lightweight flow and notes that persistent storage and paid evaluation are future phases. It also lists refused instructions (buy, sell, etc.), providing implicit when-not-to-use. Could be more explicit about alternative tools but sufficient.

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 goes beyond by detailing: 'read-only and idempotent; it performs deterministic local validation only, has no destructive side effects, does not call DeltaSignal evidence routes, does not execute wallets or x402 settlement, and never returns buy, sell, hold, target-price, allocation, or order instructions.' This fully discloses 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 well-organized: purpose first, then parameter list, behavior, and usage guidance. Every sentence adds value. It could be slightly more concise (e.g., removing redundant 'Parameters:'), but overall 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 the tool's moderate complexity (8 params, 2 required), output schema exists, and annotations are rich, the description covers all necessary context: purpose, input, behavior, and usage flow. It also explicitly states what the tool does not do, ensuring agents understand its limitations.

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 lists the parameters and mentions which are required vs optional, but does not add significant semantic detail beyond what the schema already provides for each parameter. The schema descriptions for ticker and thesis_text are already thorough.

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

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

The description clearly states the tool's purpose: 'determine whether a user-written issuer thesis is monitorable' and lists ten specific scoring criteria. It distinguishes from siblings like deltasignal_thesis_create (creation) and deltasignal_readiness (simpler readiness) by emphasizing the thesis-structuring and readiness-check role.

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

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

Explicitly says 'Use this read-only tool before paid ATLAS evidence evaluation' and 'Use it as the free or low-cost thesis-structuring layer; use paid thesis baseline or evaluation only after readiness is monitor_ready or needs_cleanup.' This provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds specific behavioral details: 'it performs one HTTPS read, has no destructive side effects, and never writes orders, files, accounts, or wallet state.' This clarifies the scope of side effects beyond the hints. 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 well-structured with a clear opening sentence stating purpose. Every sentence adds value: behavior, parameters, use cases, and alternatives. It is appropriately sized for the tool's complexity.

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