Philidor DeFi Vault Risk Analytics

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It discloses the comparison fields but does not mention whether the operation is read-only, any potential errors (e.g., invalid vault addresses), output format, or rate limits. This leaves significant behavioral gaps.

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 verb 'Compare' and lists the key attributes. It contains no redundancy or filler, maximizing clarity with minimal length.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core function effectively. It could mention output format or limitations, but for a comparison tool with this scope, it is adequately contextual.

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 fully documents the only parameter (vaults) with descriptions for the array and its nested properties (network, address). Since schema coverage is 100%, the description adds no extra parameter semantics, and the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Compare' and the resource '2-3 DeFi vaults side-by-side' with specific attributes (TVL, APR, risk score, etc.). This distinguishes it from sibling tools like get_vault (single vault) and search_vaults (searching), 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 phrase 'side-by-side' implies use for comparative analysis, and the restriction to 2-3 vaults provides clear context. However, it does not explicitly mention alternatives or exclude cases where other tools (e.g., get_vault) would be more appropriate, stopping short of full 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?

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 full burden and does well: it discloses the return count (top 10), sorting order (by Philidor risk score), the score interpretation (higher = lower assessed risk), and a key caveat (scores are not a safety guarantee). It also notes the 'audited' qualifier, adding meaningful behavioral context beyond a simple 'find' operation.

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 the primary purpose stated up front and the key behavioral details in the second. Every phrase contributes essential information (top 10, audited, sorting, caveat), with no fluff or repetition.

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

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

Despite having no output schema and no annotations, the description is sufficiently complete: it explains the result set size, sorting, interpretation of risk score, and the safety caveat. It also conveys the optional filter parameters. This is all an agent needs to correctly invoke and interpret the tool's output.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only restates the filter options ('asset, chain, or minimum TVL') without adding semantic detail beyond what the schema already provides for each parameter (e.g., 'Minimum TVL in USD'). Thus it adds no extra value.

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

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

The description uses a specific verb ('Find') and resource ('highest risk-scored DeFi vaults'), and clearly states the tool's unique scope: returning top 10 audited vaults sorted by Philidor risk score. This distinguishes it from siblings like search_vaults (likely broader search) and list_vaults_with_incidents (incident-focused).

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 when to use it: when you need the highest risk-scored vaults, with optional filters by asset, chain, or minimum TVL. It doesn't explicitly state when not to use it or mention alternative tools, but the context makes the intended use clear.

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

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

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. 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 burden. The verb 'Get' implies a read-only operation, and the description is transparent about what data is returned (TVL, vault count, versions, auditors, security incidents). It does not mention side effects or error cases, but for a straightforward information retrieval tool, this is sufficient.

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

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

The description is a single, front-loaded sentence that immediately states the purpose and lists relevant data points. Every word adds value, with no redundant or filler content.

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

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

Given the simple one-parameter schema and no output schema, the description is reasonably complete. It explains what information will be returned without needing to describe return formatting. It could mention response structure, but the listed data points give enough context for an agent to understand the tool's capability.

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 parameter protocolId already includes a description with examples (e.g., morpho, aave, yearn). The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool gets detailed information about a DeFi protocol, listing specific content (TVL, vault count, versions, auditors, security incidents). It distinguishes from sibling tools like get_vault or get_curator_info by focusing on protocol-level data, but does not explicitly name alternatives, 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?

The description provides clear context for when to use the tool: when needing protocol-level info such as TVL or security incidents. However, it does not explicitly state when not to use it or mention alternative sibling tools, so there are no exclusions or alternative 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?

Since no annotations are provided, the description carries the full burden. It discloses what information is returned (risk breakdown, recent events, historical snapshots) and how to identify the vault. However, it fails to clarify behavior for edge cases: what happens if multiple params are provided, if none are provided, or if the lookup fails. It also doesn't state that the operation is read-only, though 'Get' implies it. These gaps make it adequate but not fully transparent.

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 core purpose and key content types. The second sentence concisely explains the lookup methods. No redundant words or repetition of schema details. Every element 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 simple tool with three optional parameters and no output schema, the description covers the main use case and expected content. However, it leaves ambiguity around the parameter combinations (e.g., can you provide address alone? what if network alone?) and doesn't describe error behavior or return format beyond listing content areas. Given the lack of annotations, the description could be more complete to ensure correct handling of all invocation modes.

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 descriptive parameter names and examples (id, address, network) with 100% coverage. The description adds the semantic relationship 'by ID or by network + address', clarifying that id can be used alone or network and address can be combined. This goes beyond the schema and aids correct invocation. However, it doesn't explain precedence or validation rules when both methods are used, preventing a higher score.

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

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

The description clearly states the verb and resource: 'Get detailed information about a specific DeFi vault' and enumerates the contents (risk breakdown, recent events, historical snapshots). It distinguishes from siblings like search_vaults (which implies list search) and get_vault_risk_breakdown (which is risk-only) by emphasizing 'specific vault' and the multi-faceted information. The lookup methods (ID or network+address) further clarify the target resource.

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 when to use the tool (when you need detailed info for a specific vault) and gives lookup key formats. However, it does not explicitly mention alternatives or exclusions, such as 'for risk-only details use get_vault_risk_breakdown' or 'for comparing use compare_vaults'. The guidance is clear context but lacks explicit comparison against 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately indicates a read-only 'get' operation and specifies the output components (Asset Composition, Platform and Strategy, etc.), but it does not mention edge cases, error handling, or any side effects. 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, well-structured sentence that front-loads the action ('Get') and the resource, then lists the specific risk components. Every word contributes meaning, with no redundancy or filler.

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

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

Given no output schema, the description provides a reasonable overview of what is returned by listing the four risk categories and mentioning sub-metrics. This is sufficient for a two-parameter read tool, though it could be enhanced with a brief note on the response structure or typical usage context.

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

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

The input schema already covers both parameters with clear descriptions (vault contract address and network slug), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Get') and resource ('detailed breakdown of a vault's risk vectors'), and enumerates the specific risk categories returned. This distinguishes it from sibling tools like explain_risk_score or get_vault.

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 clear usage context: use this when you need a detailed risk vector breakdown for a specific vault. However, it does not explicitly mention when not to use it or name alternative tools, leaving a slight gap in 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?

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?

With no annotations provided, the description carries the full burden. It discloses that results are paginated and include risk scores and APR, which is useful behavior. However, it does not explain pagination mechanics (e.g., cursor/page parameter), default sorting, or any rate limiting/auth constraints. It implies read-only operation but does not explicitly confirm safety.

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

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

The description is two sentences: first states the core purpose with filter categories, second states the return structure. It is front-loaded and free of filler, though 'and more' is slightly vague, which is a minor issue.

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

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

The description gives a solid high-level overview for a search/filter tool, but given 10 optional parameters, it lacks practical context such as how to combine filters, default sorting behavior, or what 'paginated' means specifically (there's no cursor/offset parameter). The absence of an output schema increases the need to clarify return format, which is only partially addressed.

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

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

Schema coverage is 100%, so the description does not need to restate parameter details. The tool description summarizes the filter options but adds no new semantics beyond the schema. For example, 'asset, risk tier, TVL' are already listed in the schema with examples and enums. Baseline 3 applies.

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

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

The description clearly states the tool's function: 'Search and filter DeFi vaults' with specific filters (chain, protocol, asset, risk tier, TVL) and return content ('paginated list with risk scores and APR'). It distinguishes itself from siblings like get_vault (specific vault retrieval) and compare_vaults (comparison) by focusing on search/filter discovery.

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

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

No guidance is given on when to use this tool versus alternatives such as get_vault, get_market_overview, or find_safest_vaults. The description does not mention exclusions, prerequisites, or typical scenarios, so an agent must infer usage from the name alone.

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