Philidor DeFi Vault Risk Analytics

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

With no annotations provided, the description carries the full behavioral burden. It discloses meaningful boundaries (analysis-only, no health factor computation, no tx preparation) and names the upstream dependency, but omits details such as permissions/auth requirements, rate limits, or behavior on an invalid market id.

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?

Front-loads purpose and scope, then constraints, then prerequisites and examples. Dense but every sentence earns its place; the appended example list is slightly overloaded against the schema examples already present.

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 3-param read/analysis tool with no output schema, the description covers purpose, returned fields, exclusions, workflow position, and the upstream call needed to obtain a market id. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100%, so marketId, collateral, and debt are already well documented in the schema, including spoke/hub examples. The description reinforces this with additional market-id examples and the Aave V4 protocol/version hint, but adds only marginal semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (underwrite) and resource (a collateral/debt loop on ONE lending market) and enumerates exactly what the tool returns: score, tier, utilization, borrow APR, deposit status, and recent incidents for both reserves. This differentiates it from generic siblings like get_market or get_market_overview.

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?

Gives explicit when-to-use ('Call this before a protocol MCP preview_action / prepare_action'), an explicit prerequisite path ('If you do not have a market id, call list_markets first'), and explicit exclusions ('Does not compute health factor and does not prepare txs'). The agent knows both when to call it and when not to.

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 behavioral burden and does so well: it lists the key return fields, describes attestation issuance only when issue is true, and gives the verification URL pattern. It also discloses deterministic behavior, error handling for missing or unknown API fields, structured refusal for ineligible plans, and that Philidor does not prepare transactions.

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 return shape, and most sentences add useful operational context rather than repetition. It is somewhat dense and could be more scannable, but the length is justified by the absence of annotations and output schema.

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

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

There is no output schema and no annotations, so the description must explain both behavior and returns; it does so by naming the attestation fields, optional issued-attestation fields, verification URL, refusal behavior, and error policy. For this tool's complexity, an agent has enough information 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 the positions, limits, constraints, agentId, and issue parameters in detail. The description reinforces that positions and limits are caller-supplied and that no policy is preselected, but it does not add parameter syntax or semantics beyond what the schema already provides.

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

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

The description states a specific verb and resource: it checks whether supplied positions conform to supplied limits and constraints, and calls POST /v1/graph/check. It also draws a clear boundary against recommendation tools by saying it does not recommend a vault and does not preselect a Philidor policy.

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

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

The description gives clear usage context: use it to test positions against caller-provided limits and constraints, with no preselected policy and no wallet-specific behavior. It includes an explicit non-use boundary ('does not recommend a vault') but does not name alternative tools for recommendation or comparison tasks.

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

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

No annotations are provided, so the description carries the full burden. It discloses what the comparison covers (TVL, APR, risk, audited status) and implies a read-only analytical operation, but it does not state whether data is live, whether any external calls are made, or what happens with unsupported metrics.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the core action and scope are immediately 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?

For a tool with one required parameter and no output schema, the description gives enough information to invoke it correctly: the vault count, the comparison dimensions, and the side-by-side presentation. The phrase 'and more' is slightly vague, but it does not block correct usage.

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

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

Schema description coverage is 100%, so the single parameter 'vaults' and its nested 'network' and 'address' fields are already fully documented. The description adds context about what will be compared but no additional parameter syntax or formatting details, matching the baseline for high schema coverage.

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

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

The description uses a specific verb ('Compare') with a clear resource ('2-3 DeFi vaults') and enumerates the comparison dimensions (TVL, APR, risk score, risk tier, audited status). This distinguishes it from single-vault tools like get_vault and ranked tools like find_safest_vaults.

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

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

The description clearly establishes the usage context: when an agent needs a side-by-side comparison of a specific set of 2-3 vaults. It does not explicitly name alternatives or exclusion criteria, but the comparison framing is unambiguous enough to guide selection.

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

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

Since no annotations are provided, the description carries the full burden. It transparently states the tool provides an explanation including tier, calculation, and thresholds, with no hidden side effects. It could be more explicit about being read-only, but the behavior is clearly non-mutating and straightforward.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and the key aspects it covers.

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

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

Given the simple one-parameter schema and absence of an output schema, the description is largely complete. It details what the explanation will include, though it does not specify the return format (e.g., text or object), which could be inferred from the tool's nature.

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 has 100% coverage for the single parameter 'score' with a clear description ('Risk score (0-10) to explain'). The description does not add extra meaning beyond what the schema provides, which justifies the baseline score of 3.

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

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

The description clearly states the tool's function: explaining what a Philidor risk score means, covering the tier, calculation, and thresholds. This is a specific verb+resource combination that distinguishes it from sibling tools like get_vault_risk_breakdown, which likely focuses on a specific vault's breakdown.

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

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

The description implies usage when an agent needs to understand the risk score system rather than retrieve data about specific vaults. It clearly indicates the context but does not explicitly mention when not to use it or alternatives.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains return size (top 10), sorting direction (Philidor risk score), the meaning of higher scores, and a safety caveat. This is meaningful behavioral context beyond the tool name, though it does not mention default behavior with no filters or error handling.

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 deliver the core purpose, filters, result cap, sorting rule, and a caveat without redundancy. The highest-value information is front-loaded and every clause earns its place.

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

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

For a read-only listing tool with three optional filters and no output schema, the description provides sufficient orientation: what is returned, how it is ordered, and a risk caveat. Minor gaps like pagination and empty-result behavior are acceptable given the simple scope.

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

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

Schema coverage is 100%, and each parameter already has a descriptive definition. The description mirrors those filters ('asset, chain, or minimum TVL') without adding new parameter-level detail, so it meets the baseline but does not elevate semantics.

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

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

The description states a specific verb ('Find'), a concrete resource ('highest risk-scored DeFi vaults'), and key constraints: optional filters, top-10 limit, audited status, and Philidor risk score ordering. This clearly distinguishes it from siblings like search_vaults or list_vaults_with_incidents.

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

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

The description implies the tool is for surfacing top vaults by risk score and supports optional filtering, but it never explicitly names alternatives or states when not to use it. Usage context is inferable but not directly contrasted with sibling tools.

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

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

No annotations are provided, so the description carries the burden. It does disclose the informational content (managed vaults, TVL, etc.), which is helpful, but it does not explicitly state that this is a read-only operation, potential error scenarios, or any rate or permission requirements. The behavior is mostly implicit for a 'get' tool.

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

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

The description is a single, well-structured sentence that front-loads the action ('Get detailed information') and efficiently lists the key data categories. Every word 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?

For a simple tool with one required parameter and no output schema, the description adequately covers the main purpose and data categories. It could be more complete by mentioning the return format or error handling, but given the low complexity and high schema coverage, it is sufficient.

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

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

Schema description coverage is 100% with the parameter 'curatorId' described as 'Curator ID'. The tool description adds no further semantic detail beyond the schema about how to obtain or format the ID. Baseline 3 is appropriate since the schema already covers the 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 retrieves detailed information about a vault curator, and lists specific content areas (managed vaults, TVL, chain distribution, performance). This distinguishes it from sibling tools like get_vault or get_protocol_info, making its 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 implies usage when curator-level information is needed, but it does not explicitly state when to use this tool versus alternatives like get_vault or get_protocol_info. No exclusions or alternative guidance is provided, so the usage context is only implied.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, and the description usefully discloses that the response aggregates every reserve plus hub-composition behavior, but it says nothing about auth requirements, error behavior on unknown ids, or pagination/size limits.

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

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

Front-loads the returned payload before the id-format caveats, and every sentence carries information. Minor redundancy: the id example overlaps what the schema already shows.

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

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

With no output schema, the description compensates by enumerating the returned per-reserve fields, and it explains id formats and hub composition. Missing only edge-case behavior such as what happens for an unknown or spoke-less id.

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 a single parameter and 100% schema description coverage, the schema already documents marketId with spoke and hub examples. The description's 'Spoke ids look like...' largely repeats that, adding only the hub-composition note, so the baseline 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?

States a specific verb and resource ('Get one lending market') and enumerates the per-reserve fields returned (supplied, supply APR, borrowed, borrow APR, utilization, risk tier), so the agent knows exactly what data comes back. Sibling differentiation is only implicit via the '/v1/markets' reference, which hints at list_markets without naming the tool.

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 is implied rather than stated: the agent must infer it is called with an id sourced from list_markets, and the note that hub parents are composed from spokes suggests when a hub id is acceptable. There is no explicit when-to-use-this-vs-alternatives guidance and no prerequisites or exclusions beyond the id-format constraint.

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 must carry the behavioral burden. It does add useful context (what event types are published, id formats, and that Aave V4 hub ids union spoke feeds), but it says nothing about ordering, pagination behavior, rate limits, or how many events are typically returned beyond the schema's limit default.

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 compact sentences, front-loaded with the core purpose and then routing constraints. Dense but nearly every clause carries information; the id examples are long but earn their place by clarifying accepted formats.

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 or annotations, so the description must set expectations, and it does explain what kinds of events appear. It stops short of describing the response shape (fields per event) or pagination, which would be the remaining gap for an agent consuming results.

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 already 100%, so the baseline is 3. The description goes beyond the schema by giving concrete id format examples (morpho-v1-1-pt-reusd-10dec2026-usdc-91-5) and explaining the hub-union semantics for Aave V4 ids, which the schema only hints at.

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 and resource ('Published risk events for ONE lending market') and enumerates the event kinds (incidents, bad debt, liquidation cascades) with a concrete example. It explicitly scopes itself as ONE market vs platform-level tools, so an agent can distinguish it from get_market_overview and get_market without opening schemas.

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 names both alternatives and the conditions that select them: 'Not platform stats (get_market_overview) and not the market data itself (get_market).' That is explicit when-not guidance plus concrete alternative routing, leaving little to inference.

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?

No annotations are provided, so the description carries the full burden. It lists the output metrics, which clarifies what the tool returns, but it does not disclose other behavioral aspects like data freshness, whether it's a read-only operation, or any potential aggregation logic. For a simple overview tool, this is adequate but not rich.

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

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

The description is a single sentence that leads with the action 'Get' and immediately specifies the object and scope. It lists the key metrics without any filler, making it concise and well-structured.

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

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

Given the simplicity of a zero-parameter tool with no annotations and no output schema, the description covers the essential return values (TVL, vault count, risk distribution, TVL by protocol). It could explicitly state the response format (e.g., 'returns a JSON object with...'), but the metric list effectively conveys the response content. For this complexity level, it is sufficiently complete.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The description does not need to explain parameter usage, and the baseline for 0-param tools is 4. No additional semantics are required.

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

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

The description clearly states the tool provides a high-level market overview with specific metrics (total TVL, vault count, risk distribution, TVL by protocol). This distinguishes it from sibling tools like get_vault and get_protocol_info, which target individual entities. The verb 'Get' and resource 'DeFi vault market' are specific and unambiguous.

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

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

The context is clear: use this tool when a market-level snapshot is needed, not for specific vault or protocol details. However, it does not explicitly name alternatives or state when not to use it, such as 'for specific vaults use get_vault'. The implication is strong but not directly stated.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real value beyond them: it discloses the API-key entitlement requirement, warns that a missing assessment should not be read as zero, and clarifies that 'verified' is an API assertion rather than independent trust-root verification. That last point is a genuinely non-obvious trust caveat.

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?

Purpose is front-loaded in the first sentence, and each following sentence adds a distinct, load-bearing caveat (case sensitivity, missing≠zero, API key, verified semantics). No filler 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?

With no output schema, the description carries the burden of explaining returns, and it names both returned fields and the trust caveat around 'verified'. It stops short of describing response shape or error/absence behavior beyond the 'missing is not zero' note, but it is sufficient to call 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 50%: the identifier field is self-documented (including case preservation, which the description repeats), but the network enum has no description. The description names the five ledger families but doesn't map them to the enum values or explain the exact identifier format, so it only partially compensates.

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?

States a specific verb (get) and two concrete outputs (current effective score and signed reviewed base score) scoped to five named ledgers. It is clearly distinguishable from get_native_asset_financials and explain_risk_score by its score-focused output, though it never names a sibling directly.

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?

'Preserve identifier case' and 'A missing assessment is not a zero score' give operational guidance on how to call and interpret results. However, there is no explicit statement of when to use this versus explain_risk_score or get_native_asset_financials, so the routing guidance is only implied.

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

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds real interpretive content: null means unavailable not zero, each metric carries unit, fund/global/deployment scope, source and freshness, and explicit caveats on what AUM/NAV do not imply. It omits rate limits or response shape, keeping it below a 5.

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?

Front-loaded with the core action, then caveats and freshness guidance; every sentence carries information. Slightly telegraphic run-on phrasing costs a point but nothing is wasted.

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?

No output schema exists, so the description must carry the return-value burden, and it does explain metric metadata, null semantics, and excluded data. Minor gaps remain around response structure or pagination for a tool returning multi-metric financials.

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 50% schema coverage, the network enum is undescribed in the schema, but the description compensates by enumerating the exact supported networks and reinforcing the identifier's required exactness and case preservation. This adds meaning beyond the schema for both parameters.

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

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

States a specific verb and resource (get public issuer financials) scoped to exact native tokens on five named networks. It also pre-empts confusion with siblings by declaring it does not return a risk score, distinguishing it from explain_risk_score and get_native_asset_assessment.

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?

Gives clear operational guidance: preserve identifier case, requery by refreshBy for freshness, and don't interpret fund AUM/NAV as token supply or reserves. It lacks an explicit 'use X instead when...' routing statement against get_native_asset_assessment, so it stops short of the top band.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description is free to add data-semantics context – and it does: 'Prices are display-only; constituents have no inferred weights or inherited ratings' prevents an agent from treating the payload as a ratings/weighting source, and 'source freshness' flags staleness as a first-class concern. It stops short of saying what happens for an unknown or delisted symbol.

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, zero padding: the first front-loads what you get, the second carries the one caveat that changes how the result may be used. Nothing is repeated from the annotations or schema.

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

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

For a single-parameter read with no output schema, describing the returned sections is exactly the right compensation, and the caveat sentence covers interpretation. The only gap is failure behavior for an invalid symbol, which matters for an exact-match lookup.

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

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

Schema coverage is 100% and the single parameter already documents case sensitivity, the pattern, an example (SPYon), and where to source it. The description only echoes 'exact', adding no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get an exact Ondo token') and enumerates the payload sections returned: issuer market observations, constituents, freshness, assessment links. 'Exact' distinguishes it from the listing tool, but it does not say how it differs from the adjacent siblings get_ondo_asset_data and get_ondo_asset_stream, which an agent will see right next to it.

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 is only implied: 'exact' signals a precise-symbol lookup rather than a scan, and the schema field says to obtain the symbol from list_ondo_assets. The description itself names no alternative, no when-not condition, and no prerequisite flow.

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

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

Annotations already cover read-only and idempotent behavior, and the description adds real context beyond them: family availability varies, source clocks are explicit, there are constrained interval/range pairings, and two definitional warnings (dividend yield is a decimal underlying yield, not distribution yield; supply is in token units not USD). It does not discuss response size or pagination, but the added caveats are substantive.

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 purpose is front-loaded in the first sentence, followed by constraints and caveats. The valid-windows list is dense but each item carries information. Slightly list-heavy but 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?

For a 3-parameter read-only tool with no output schema, the description covers what data families come back, the units/semantics of the trickier fields, and the valid query windows. Remaining gaps (response shape, per-family payload structure) are minor for a read 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 only 33% (only symbol is documented in-schema), so the description must compensate — and it does, listing the valid interval/range windows and the 1hour/1month default. That cross-parameter constraint is not expressible in the enums alone, which is genuine added 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 opening sentence names specific verbs and resources: OHLC, dividends, shares-multiplier history, and per-chain token supply for Ondo assets. That distinguishes it from list_ondo_assets and get_ondo_asset (metadata), though it never names those siblings explicitly to route the agent.

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 is implied by the data families listed and the valid interval/range windows, but there is no explicit when-to-use or when-not-to-use guidance against get_ondo_asset, get_ondo_asset_stream, or list_ondo_assets. The agent must infer that this is the historical series tool.

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

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

Beyond the readOnly/idempotent annotations, the description discloses a lot: values are 'retained' with source/receipt ages and evaluatedAt, a 120-second freshness policy that is not an execution guarantee, and that conflicts/collector gaps and missing (non-zero) values can appear. These are exactly the behaviors an agent needs to interpret the response correctly.

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

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

Three dense sentences, front-loaded with the primary purpose, then the caveats. No filler, though the terminology (evaluatedAt, receipt ages, collector gaps) is terse enough to require careful reading.

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

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

With no output schema, the description usefully flags what the payload will contain (ages, conflicts, gaps, missing values) and its freshness semantics. It stops short of describing the actual response shape (price vs OHLC fields), which is the main remaining gap.

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

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

Schema coverage is 100% and the single symbol parameter is fully documented in the schema, including the pattern and pointer to list_ondo_assets. The description adds no parameter-level detail, so baseline 3 applies.

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

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

The description names a specific verb and resource — 'latest retained Ondo display prices and minute OHLC' — which is concrete and distinct from a generic asset lookup. It doesn't explicitly differentiate itself from siblings like get_ondo_asset or get_ondo_asset_data, leaving the agent to infer the split.

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 is implied (fetch current display price/OHLC for a symbol) and the closing sentence carves out scope ('does not open an issuer subscription or supply history'). However, it never states when to prefer this over get_ondo_asset or get_ondo_asset_data, so the agent must guess the 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, the description must carry behavioral disclosure. It usefully states that the tool returns an access refusal and excludes freshness, which are important traits beyond the empty schema. However, it does not explain whether refusal is unconditional, what conditions cause it, what permissions are required, or what the structured refusal contains.

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

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

The description is two sentences, front-loaded with the primary behavior and followed by a concise exclusion. Every sentence adds relevant information, with no filler 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?

There is no output schema, so the description should explain the return value more fully. It identifies the output as a 'structured access refusal' but does not describe the structure, whether it is always returned, or what an agent should do with it. The crucial limitation is stated, but the definition remains incomplete for a tool whose only output is a refusal.

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

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

The tool has zero parameters, so there is no parameter semantics to clarify. The schema is empty and fully described by its coverage, making the baseline score of 4 appropriate.

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

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

The description states a specific verb and target: 'Returns the structured access refusal for the oracles family.' It also adds a scope exclusion ('Does not return freshness'). The purpose is clear, though the phrase 'oracles family' is not defined and the name get_oracles could suggest data retrieval rather than refusal.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It only notes that it does not return freshness, which is a negative hint but not a use case or routing rule. No sibling tool is named as an alternative.

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?

No annotations are provided, so the description carries the full burden. It does disclose the shape of the returned data (TVL, vault count, versions, auditors, incidents), which is genuinely useful given there is no output schema, but it says nothing about auth requirements, rate limits, or behavior for unknown/unsupported protocol IDs.

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?

One front-loaded sentence with no filler; the resource is named first and the value proposition follows immediately.

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?

Adequate for a one-parameter read tool with no output schema, since the description previews the return fields. It is still thin on failure modes (invalid protocolId, case sensitivity) and does not explain how this protocol-level view relates to the vault/market tools an agent will likely need next.

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

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

Schema description coverage is 100% and the single parameter is documented with an explicit ID list plus an alias rule, so the schema already does the heavy lifting. The description adds nothing about the protocolId parameter beyond what the schema states; baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('DeFi protocol') and enumerates the returned content (TVL, vault count, versions, auditors, security incidents). It is distinguishable from vault- and market-level siblings, though it never explicitly names an alternative to route against.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_curator_info or list_vaults_with_incidents, which also surface protocol-adjacent security data. The agent must infer the use case from the field list alone.

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

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

No annotations are provided, so the description carries the disclosure burden. The 'Get' verb makes the read-only nature reasonably clear and the description enumerates returned content categories. However, it does not mention response shape, pagination, or any prerequisite/permission considerations, leaving some behavioral aspects unspecified.

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

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

The description is two concise sentences with no filler. The first sentence front-loads the action and resource, and the second sentence explains the lookup modes. Every clause contributes useful information.

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

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

With no output schema and no annotations, the description has to explain what the call returns, and it does so by naming risk breakdown, recent events, and historical snapshots. It does not detail exact response fields or behavior for ambiguous parameter combinations, but the essential information for using a single-vault lookup tool is present.

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

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

The schema already provides 100% parameter coverage, so the baseline is 3. The description adds meaningful value by stating the two lookup modes — standalone 'id' OR the 'network + address' pair — which clarifies the intended parameter combination and reduces the risk of supplying contradictory parameters.

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

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

The description states a specific verb and resource ('Get detailed information about a specific DeFi vault') and lists the included content areas: risk breakdown, recent events, and historical snapshots. It distinguishes itself from the narrower get_vault_risk_breakdown sibling by using 'including', though it does not explicitly contrast itself with any sibling.

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

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

The description clearly implies when to use the tool: when an agent needs comprehensive details about a single vault and has either an ID or network+address. It does not name excluded cases or alternatives, but the targeted 'specific vault' framing provides clear context without misleading the agent.

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

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

With no annotations, the description carries the full burden. It does disclose the output shape (four risk categories with sub-metrics) and 'Get' implies a read-only retrieval. It does not mention any special behavioral concerns such as score normalization, live vs cached data, or response limitations, but for a simple getter this is adequate though not rich.

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

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

A single tightly written sentence that leads with the verb and resource, then enumerates the returned components without filler or repetition. Every phrase contributes 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?

For a 2-parameter read tool with no output schema, the description tells an agent what it returns (four risk vectors and sub-metrics) and the schema provides all input details. It does not explain the return structure in detail, but the high-level description is sufficient for selection and invocation.

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

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

Schema description coverage is 100%; both address and network have clear explanations (namespace, chain slug format, examples, and how to list valid slugs). Since the schema already documents the parameters completely, the description adds no extra semantic value, matching the baseline 3.

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

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

The description names a specific verb ('Get') and resource ('a vault's risk vectors') and enumerates four concrete components: Asset Composition, Platform and Strategy, Control and Governance, and History scores with sub-metrics. It is clear, but it does not explicitly distinguish itself from sibling tools such as explain_risk_score or get_vault, so it doesn't fully earn the top score for sibling differentiation.

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

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

The description implies this is the tool to use when a detailed risk breakdown is needed, and the listed categories give context. However, it never states when to prefer it over alternatives like get_vault or explain_risk_score, nor provides any when-not conditions.

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 it does disclose one important trait: the call yields an access refusal rather than data, and it explicitly excludes constituents and weights. That is meaningful behavioral information no structured field provides. However, it says nothing about why the refusal occurs, whether credentials/entitlement would change the outcome, or what the refusal payload contains.

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 short sentences, front-loaded with the outcome and followed by the exclusion. Nothing is padded, though the brevity comes partly at the cost of the missing usage context rather than from disciplined trimming.

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

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

For a no-parameter, no-output-schema tool, the description should at minimum tell an agent what it gets back and whether calling is ever useful. It signals the refusal and the missing constituents/weights but leaves the return shape and the alternative paths unexplained, so an agent cannot confidently decide 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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. It correctly implies no input is required. The listing behavior itself, not parameters, is what is under-explained.

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

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

The description opens with a specific verb and scope ("Returns the structured access refusal for the baskets family"), which is concrete, but it never explains what the tool actually does with baskets, so a reader cannot reconcile the name "list_baskets" with a response that is apparently always a refusal. It gives no differentiation from any of the 23 sibling tools, several of which (list_vaults_with_incidents, list_markets) follow the same listing pattern.

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

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

There is no statement of when to call this tool, when not to, or which alternative to use for basket data. An agent has no basis to choose it over list_rwa or get_vault beyond guesswork from the name.

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 behavioral burden, and it discloses a genuinely non-obvious trait: Aave V4 spokes sharing a liquidity hub are grouped under a composed parent while the API still keys each market on the spoke. That prevents misreading of returned identifiers. It lacks pagination or response-shape notes, so it is strong but not exhaustive.

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?

Front-loads the core definition before the hub-grouping nuance and the sibling exclusion. Every sentence carries information, though the composed-parent example adds a touch of density that could be trimmed.

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?

No output schema and no annotations, so the description must orient the agent, and it does: it defines the resource, names the platforms, explains the hub-grouping keying quirk, and excludes a confusable sibling. Missing only return-format or pagination expectations for a list endpoint with a limit parameter.

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

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

Schema description coverage is 100%, so all five parameters are already documented with defaults, ranges, and alias behavior (e.g. aave-v4 accepted as an alias). The description adds contextual framing about what a 'market' means but no parameter syntax beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('List lending markets') and immediately defines what a market is across five named platforms (Aave/Spark pool, Aave V4 spoke, Compound Comet, Morpho Blue pair, Kamino K-Lend). It also explicitly distinguishes itself from the sibling get_market_overview, so an agent can route correctly without opening a schema.

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 names the alternative (get_market_overview) and states the condition that separates them: platform-wide totals across all vaults vs. individual markets. It also hints at filter routing (version=v4 with protocol=aave), but does not cover when to prefer get_market or search_vaults, so it falls short of a full when/when-not map.

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

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

The annotations already declare this as a safe, read-only, idempotent, non-destructive, open-world operation. The description adds useful data-behavior context beyond the annotations: pagination, API-only and CSV-only entries, freshness, and identity conflicts, though it does not describe return structure or pagination behavior in 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 short and front-loaded, starting with the catalog-search purpose. The additional sentences about entry types, freshness/identity conflicts, and risk-score exclusion each add relevant scope information without 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 the tool has three undocumented parameters and no output schema, the description is only partially complete: it explains the catalog contents and data-quality caveats but omits parameter semantics and return-value expectations. Annotations cover the safety profile, but schema coverage is too low for the description to leave parameters fully implicit.

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 0%, so the description must explain the three parameters: page, limit, and search. It only implies pagination via 'paginated' and provides no meaning for search, defaults, or limits, leaving most parameter semantics undocumented.

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 and resource: searching the paginated Ondo Global Markets catalog of tokenized securities, portfolios, and issuer-reported deployments. It is clear about scope, including API-only and CSV-only entries, but it does not explicitly distinguish this tool from siblings such as get_ondo_asset or list_rwa.

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 is implied by 'Search the paginated Ondo Global Markets catalog,' and the description adds an exclusion: 'This is not a list of verified risk scores.' However, it does not name when to use this tool instead of get_ondo_asset, get_ondo_asset_data, or list_rwa.

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 it does disclose two behavioral facts: the call returns an access refusal rather than data, and coverage is excluded. However, it never explains why access would be refused, what the refusal structure contains, or whether any data is ever returned, leaving the core behavior ambiguous.

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?

It is only two sentences and front-loads the refusal behavior, so it is not bloated. But the brevity comes at the cost of under-specification: the second sentence narrows scope before the first has established what the tool does.

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

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

For a zero-param tool with no annotations and no output schema, the description is the only source of truth about the return payload, and it does not describe what the 'structured access refusal' contains or whether a successful listing is possible. An agent would have to call it blind to learn its behavior.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No param claims are made that would conflict with the empty object 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 name implies listing RWA assets, but the description never says what data is returned; instead it says it returns a 'structured access refusal for the rwa family.' That may be a permission-denied payload rather than a listing, so an agent cannot tell what the tool actually produces or how it differs from list_ondo_assets, list_baskets, or list_markets.

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

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

There is no guidance on when to call this versus the many sibling list_* tools. The only directional statement, 'Does not return coverage,' reads as a scope exclusion but is not framed as a selection criterion, so nothing tells the agent when this tool is the right choice.

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 of behavioral disclosure. It adds meaningful details: the 365-day window, the definition of 'critical', and the sorting logic (TVL descending, then recency). It does not mention whether a vault with multiple incidents appears once or the exact return structure, but it is transparent about the core filtering and ordering 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 two sentences with no fluff. The first sentence states the primary purpose, and the second adds necessary criteria and sorting. Each word earns its place.

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

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

For a parameterless list tool with no output schema, the description covers the essential information: what is listed, the incident criteria, and the ordering. It does not specify the fields included in each vault object, but given the simplicity and familiarity of vault-related tools, it is sufficiently complete for an agent to decide on invocation.

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

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

The input schema has no parameters, so the description has nothing to add beyond the schema. Baseline is 4 for zero-parameter tools. The description appropriately focuses on the tool's output behavior instead.

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

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

The description clearly states the tool's function: listing vaults that experienced a critical incident within the last 365 days. It also precisely defines what qualifies as 'critical' (severity Critical or incident_severity major) and specifies the sorting order, making it easy to distinguish from sibling tools like search_vaults or find_safest_vaults.

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 conveys a clear usage context: use this when you need a list of vaults with recent critical incidents. However, it does not explicitly mention alternatives or scenarios where this tool should not be used, falling short of providing full comparative 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?

No annotations are provided, so the description must carry the behavioral burden. It discloses that results are paginated and include risk scores and APR, which is useful return-shape context, but it omits permission requirements, any rate limits, and default/max page behavior (left to the schema).

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 tight sentences with the primary action front-loaded and no filler. The trailing 'and more' is mildly vague but does not bloat the text.

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 an 11-parameter tool with no annotations and no output schema, the description does partially compensate by stating the return contents (paginated list with risk scores and APR). However, it gives no routing guidance among the numerous sibling tools and no behavioral caveats, leaving meaningful gaps.

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

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

Schema description coverage is 100%, so each of the 11 parameters is already documented with examples and defaults in the schema. The description only name-drops the same filter categories without adding syntax or semantics beyond the schema, which is the expected 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?

States a specific verb and resource ('Search and filter DeFi vaults') and enumerates the filter dimensions (chain, protocol, asset, risk tier, TVL), so the agent knows exactly what the tool does. It does not distinguish itself from siblings like find_safest_vaults, compare_vaults, or list_vaults_with_incidents, so it stops short of a 5.

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

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

There is no explicit guidance on when to use this tool versus the many sibling search/retrieval tools (find_safest_vaults, compare_vaults, get_vault, get_vault_risk_breakdown). Usage is only implied by the word 'search', and no exclusions or prerequisites are given.

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