AtlasYield

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that blocking:true means refuse the deposit, that reasonClass distinguishes protocol_refused from no_aggregator_quote, that the probe is same-chain only, and that an unscreened vault returns screened:false with no fabricated verdict. It also states 'Read-only' at the end, which is critical behavioral information in the absence of readOnlyHint annotations.

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

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

The description is dense but well-organized: it opens with the core question, then lists the return fields, then explains the blocking semantics, then the reasonClass distinction, then the same-chain limitation, then the screened:false behavior, and ends with usage guidance. Every sentence earns its place, though it is somewhat long. The front-loading of the core purpose is excellent.

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

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

For a read-only probe tool with 2 well-documented parameters and no output schema, the description is remarkably complete. It explains what the return values mean (verdict, USD in/out, fraction retained, path probed, when), what blocking:true means, what reasonClass values indicate, the same-chain scope, the screened:false edge case, and when to call it. An agent has everything needed to invoke it correctly and interpret the result.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (address and chainId) with descriptions. The tool description adds context about what the vault is (a vault contract) and that chainId is the EVM chain id, but it doesn't add much beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting and the description doesn't need to compensate.

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

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

The description opens with a concrete question ('Can a deposit into this vault be exited at size, measured today?') and then states the exact resource and action: it returns a daily round-trip route screen (USDC -> position -> USDC) with verdict, USD in/out, fraction retained, path probed, and when. This clearly distinguishes it from sibling tools like get_vault_score or explain_vault_score, which are about scoring/explaining rather than probing route survival.

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 'Call this BEFORE moving money' and explains when the tool should be used. It also provides exclusion guidance: the probe is SAME-CHAIN only and says nothing about bridging in from elsewhere, so an agent knows not to use it for cross-chain checks. It also distinguishes between two failure reasons (protocol_refused vs no_aggregator_quote) and what each implies, which helps the agent decide how to act on the result.

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

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

With no annotations present, the description carries the full behavioral burden. It explicitly says 'Read-only' and discloses a non-obvious behavior: unscored vaults return found:false instead of being silently dropped. It does not describe result ordering details or error cases, but the core behavioral expectations are covered.

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 tight sentences front-load the purpose, list the returned fields, state the edge-case behavior, and declare the read-only nature. There is no filler, repetition, or schema duplication.

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?

Although there is no output schema, the description enumerates the output dimensions and the special found:false case, and the input schema fully documents the only parameter. It is complete enough for invocation; minor gaps like ranking direction or exact response envelope are not critical for an agent to decide whether to call it.

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

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

The schema already documents the vaults array, item shape, chainId, address, and the 2-8 bound at 100% coverage, so the description adds little parameter-level meaning. It reinforces the range and hints at what the comparison will include, but does not need to compensate for schema gaps.

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

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

The description is explicit about the operation: 'Side-by-side Atlas Scores for 2-8 vaults' with the exact metrics included (composite, label, pillars, APY/TVL, quality scores) and a ranking by composite. The plural scope and 2-8 range clearly differentiate it from single-vault siblings like get_vault_score and explain_vault_score.

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 communicates the intended use case: side-by-side comparison of 2-8 vaults. The boundary is clear and the schema reinforces the min/max counts, but no explicit alternative routing is given (e.g., 'for a single vault use get_vault_score'), making this clear context without formal exclusions.

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

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

With no annotations, the description carries the full burden and does so well. It explicitly declares read-only behavior, defines the result as the exact engine output at scoredAt, rules out recomputation, and documents the found:false edge case for unscored vaults. These are behavioral guarantees beyond what the input schema could ever convey.

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

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

The description is front-loaded with the tool's purpose and packs every detail into a dense single sentence without filler. It is slightly run-on, but each clause earns its place by clarifying scope, structure, or 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?

There is no output schema, so the description must explain return semantics on its own, and it does: the factor count, composition, grouping, sub-score fields, weakest-factor summary, staleness semantics, and unscored behavior. Nothing an agent needs to interpret the result is left ambiguous.

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

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

Schema description coverage is 100%, and both parameters already have strong definitions: address has format and case-insensitivity, chainId has type, exclusivity, and concrete examples. The description adds no parameter-level detail, so the baseline score of 3 applies; the schema does the heavy lifting.

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 precise verb-resource pair: explaining why a vault has its Atlas Score, and enumerates exactly what is returned (16 factors, sub-scores, weights, raw inputs, labels, grouped by pillar, plus three weakest factors). It clearly separates itself from score-retrieval siblings by emphasizing this is the stored explanation, not a score value or recomputation.

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

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

Usage context is implied rather than explicit. The description signals this is for inspecting a previously computed score breakdown ('Exactly what the engine computed at scoredAt, not a recomputation'), but it never names alternatives or states when to pick this over get_vault_score. No exclusions are provided, so an agent must infer the appropriate scenario.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only,' which is a critical behavioral trait, and 'covers right now' implies the data is a current snapshot rather than historical. It doesn't mention auth or rate limits, but for a simple read-only coverage query that is acceptable.

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 and every part earns its place: the first defines the returned metrics, the second gives the use case and flags read-only behavior. There is zero fluff or repetition.

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

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

For a tool with two optional parameters, no output schema, and no annotations, the description covers what the agent needs: what data it returns, when to use it, and that it's non-mutating. It doesn't specify output formatting or behavior with no filters, but those are minor gaps for a coverage-checking tool.

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

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

The input schema already fully describes both parameters with 100% coverage ('Restrict to one chain id' and 'Restrict to one protocol id'), so the baseline is 3. The description's mention of checking whether a protocol or chain is in the scored universe adds some semantic context, but it doesn't meaningfully exceed 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 exactly what the tool reports—scored vault count, total TVL, composite score spread, and counts by protocol and chain—and ties it to a specific resource (the Atlas Score Index). It also signals how this differs from vault-level queries by positioning it as a pre-check before asking about a vault, making it distinguishable from siblings like get_vault_score or explain_vault_score.

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

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

It gives an explicit trigger: 'Use it before asking about a vault to learn whether a protocol or chain is in the scored universe at all.' This tells the agent when to call it. It doesn't name sibling alternatives or explain when not to use it, but the context is clear enough for routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and documents the found:false behavior for vaults outside the scored universe, which are key behavioral traits an agent needs to know.

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, tightly packed sentence that front-loads the core purpose ('Latest Atlas Score for one vault') before enumerating outputs and edge-case behavior. Every phrase contributes value, with 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?

Despite having no output schema, the description enumerates all returned fields and the not-found case. For a read-only retrieval tool with two well-documented parameters, nothing essential is missing.

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

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

Schema description coverage is 100%, with both parameters (address, chainId) fully described in the schema including examples. The tool description adds no additional parameter context, so it does not exceed the baseline of 3 for a fully documented 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 the latest Atlas Score for a single vault, listing the exact output components (composite score, pillar scores, APY/TVL, data quality, timestamp) and the found:false fallback. This distinguishes it from sibling tools like compare_vaults or explain_vault_score, which serve 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?

The phrase 'for one vault' establishes clear context that this is for a single vault, distinguishing it from multi-vault tools. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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

With no annotations provided, the description carries the full burden and explicitly declares 'Read-only', which is a critical behavioral disclosure. It also states the data is a daily snapshot and that each event includes score before/after and pillar deltas, giving agents a realistic expectation of data recency and content. It does not mention pagination or limits, but for a listing tool this is minor.

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 with zero filler. The first sentence front-loads the purpose and content, and the second adds the publication cadence and read-only nature. Every clause contributes value, making it efficient and easy to parse.

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

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

For a read-only listing tool with no output schema, the description adequately covers what the agent needs: it lists alert categories, explains the data payload (score before/after, pillar deltas), and notes publication frequency. It does not specify return format or sorting, but those are not essential for a basic list operation, and the absence of an output schema lowers the expectation.

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

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

The input schema has 100% description coverage for both parameters (chainId and minSeverity), so the schema already documents them. The description adds no additional parameter-level detail, and per the rubric the baseline of 3 applies when schema coverage is high and the description doesn't compensate further.

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

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

The description uses a specific verb ('list'), identifies the resource ('open blowup-monitor alerts'), and enumerates the alert types (score-band exits, fast composite breaks, etc.), making the tool's purpose unambiguous. It is clearly distinct from the unrelated sibling tools, so no confusion arises.

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 useful usage context: the data comes from a published daily snapshot and the date field indicates freshness. It does not explicitly state when-not to use it, but since no sibling tool overlaps in functionality, explicit alternatives are unnecessary. The clarity of purpose and frequency note are adequate guidance.

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