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?

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?

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 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?

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.