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 the full disclosure burden. It compensates partially by listing comparison dimensions (TVL, APR, risk score, audited status), but omits mutation status, rate limits, auth requirements, and response format details. No contradiction with annotations.

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

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

Single efficient sentence with action front-loaded. The phrase 'and more' introduces minor vagueness after an otherwise specific list, but overall zero waste. Appropriate length for the tool's complexity.

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 lack of output schema, the description effectively compensates by enumerating the comparison dimensions returned (TVL, APR, risk metrics). With 100% input schema coverage and complete parameter descriptions, the definition provides sufficient context for invocation decisions.

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%, establishing a baseline of 3. The description adds domain context (DeFi vaults) and reinforces the 2-3 vault constraint, but does not elaborate on parameter syntax (e.g., address format requirements, valid network slugs) 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 uses a specific verb (Compare) with a clear resource (DeFi vaults) and explicitly limits scope to 2-3 vaults. The 'side-by-side' phrasing and comparison metrics (TVL, APR, risk score) clearly distinguish this from sibling tools like get_vault (single vault retrieval) and search_vaults (discovery/filtering).

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 a comparison use case but provides no explicit guidance on when to use this tool versus alternatives (e.g., when to use compare_vaults vs. calling get_vault multiple times, or prerequisites like needing specific vault addresses beforehand). No 'when not to use' exclusions are mentioned.

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 provided, so description carries full burden. Discloses content scope well (tiers, calculation method, thresholds) but omits operational traits: doesn't indicate if this is static cached data, expensive computation, or if it returns formatted text vs structured data.

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

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

Single front-loaded sentence with zero waste. Each element earns its place: identifies subject (Philidor risk score) and specific aspects covered (tier, calculation, thresholds). No redundant phrases 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?

Adequate for a single-parameter reference tool. Describes what knowledge is returned despite lacking output schema. Could improve by indicating return format (educational text) or that Philidor is a specific proprietary risk framework, but sufficient for agent selection.

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

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

Schema coverage is 100% with complete parameter documentation ('Risk score (0-10) to explain'). Description provides baseline value by mentioning 'risk score' in context but adds no additional parameter guidance, syntax examples, or usage clarification beyond the schema.

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

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

Clear specific verb 'Explain' combined with specific resource 'Philidor risk score'. Distinguishes from siblings like get_vault_risk_breakdown (which analyzes specific vaults) by focusing on the scoring methodology and meaning rather than vault-specific analysis.

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

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

Implies educational use case versus operational vault queries, but lacks explicit 'when to use' guidance. Does not clarify relationship to get_vault_risk_breakdown (use this to interpret scores returned by that tool) or when user needs this context versus raw data.

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?

Discloses sorting order, audited requirement, and that scores are not a safety guarantee. As a read-only tool with no annotations, this provides decent transparency, though could note pagination or limit 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?

Two sentences, front-loaded with key info, no unnecessary words.

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

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

Adequately explains return value (top 10, sorted) and caveat, but lacks details on output fields, edge cases (e.g., fewer than 10 vaults), and no output schema to supplement.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds context that parameters are optional and filters, but does not expand beyond the schema's meaning.

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 finds vaults with the highest Philidor risk score, returns top 10, and supports optional filters. However, 'highest risk-scored' is ambiguous given that higher score indicates lower risk, which could confuse.

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?

Implied usage for finding safest vaults, but no explicit guidance on when to use this over siblings like search_vaults or list_vaults_with_incidents, nor when not to use it.

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

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

With no annotations provided, the description carries full burden. It compensates for missing output schema by disclosing returned data fields (managed vaults, TVL, chain distribution, performance), but lacks behavioral details like error handling for invalid curator IDs, rate limits, or caching 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?

Single well-structured sentence that is front-loaded with the action verb and efficiently lists specific return data categories. No wasted words or redundant phrasing.

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 1-parameter lookup tool with no output schema, the description adequately compensates by outlining what detailed information is returned. Sufficient for agent selection despite missing error behavior documentation.

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 has 100% description coverage (curatorId: 'Curator ID'), establishing baseline 3. The description adds no additional semantics about parameter format, valid ID patterns, or how to obtain curator IDs, relying entirely on schema documentation.

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 specific verb 'Get' and resource 'vault curator', and distinguishes from vault-focused siblings by detailing curator-specific metrics (managed vaults, TVL, chain distribution, performance). However, it doesn't explicitly clarify when to use this vs. get_protocol_info 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?

No guidance provided on when to prefer this tool over alternatives like get_vault or get_protocol_info, nor any prerequisites mentioned. The description only states what the tool does, not when to invoke it.

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

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

No annotations provided, so description carries full burden. It adequately discloses the data domains covered (TVL, risk distribution, etc.) acting as proxy for return value documentation, but lacks details on data freshness, caching, or whether market data is real-time versus aggregated.

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

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

Single efficient sentence with action-oriented front-loading. Lists four specific data points without redundancy or waste. Appropriate length for the tool's complexity.

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-parameter tool without output schema, the description provides sufficient context by enumerating the specific market metrics retrieved. Absence of authentication or rate limit details prevents a 5, but adequate for tool selection.

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

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

Input schema contains zero parameters. Per evaluation rules, zero parameters establishes a baseline score of 4, as there are no parameter semantics to clarify beyond the schema.

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

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

Clear specific verb ('Get') + resource ('high-level overview of the DeFi vault market') and explicitly enumerates the four aggregate metrics returned (TVL, vault count, risk distribution, TVL by protocol). Effectively distinguishes from sibling vault-specific tools by positioning as broad market-level data.

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

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

Provides no explicit guidance on when to use this aggregate tool versus specific alternatives like get_protocol_info (which may also return TVL data) or search_vaults. No 'when not to use' or prerequisite conditions specified.

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 discloses the type of information returned (TVL, etc.), but does not state whether the tool is read-only, requires authentication, or has rate limits. Basic behavioral context is present but incomplete.

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

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

The description is a single, concise sentence that front-loads the action and resource. No unnecessary words.

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

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

Given no output schema, the description adequately covers the return fields (TVL, vault count, versions, auditors, security incidents). It provides a good summary of what to expect, though could mention error responses or additional fields.

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

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

Schema coverage is 100% for the single parameter 'protocolId', with examples in the schema. The description adds no additional parameter meaning beyond the schema, 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 clearly specifies the tool's action ('Get detailed information') and the resource ('DeFi protocol'), listing specific data points (TVL, vault count, versions, auditors, security incidents). This distinguishes it from sibling tools that focus on vaults or risk scores.

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 use for protocol-level details, but lacks explicit guidance on when to use this tool versus alternatives like get_vault or get_curator_info. No exclusions or when-not-to-use mentioned.

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 states the tool retrieves information, which implies a read-only operation, but does not disclose other behavioral aspects like data freshness, cancellation, or permissions. This is adequate but not thorough.

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

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

Two sentences: first states purpose and content, second states lookup methods. No unnecessary words, front-loaded with key information. Every sentence earns its place.

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

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

Given 3 optional parameters and no output schema, the description explains what the tool returns (risk breakdown, recent events, historical snapshots) and how to specify the vault. It does not detail the exact response structure but covers the essential aspects for an information retrieval 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 already covers all three parameters (id, address, network) with descriptions. The tool description adds valuable relational context by stating you can look up by ID or by network+address, implying that not all combinations are valid. This goes beyond the schema.

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

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

The description clearly states the tool retrieves detailed information about a specific DeFi vault, listing included aspects (risk breakdown, recent events, historical snapshots) and two lookup methods, distinguishing it from sibling tools like compare_vaults or search_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 explains when to use this tool (to get info on a specific vault) and how to look it up (by ID or by network+address). It does not explicitly mention when not to use it or compare it to alternatives, but context is clear.

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

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

With no annotations, the description carries the full burden. It states the tool provides a breakdown, which implies a read-only operation, but does not explicitly confirm this or disclose any other behavioral traits (e.g., rate limits, dependencies, or whether the breakdown is computed in real-time).

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

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

The description is a single, tightly written sentence that front-loads the action and details. Every word is necessary, and the structure is clear and scannable.

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

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

Given the tool's complexity (four risk vectors with sub-metrics) and lack of output schema, the description provides a high-level overview but omits specifics like the return format, whether scores are numeric or categorical, and if any additional context is returned. It is adequate but not fully 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 input schema covers both parameters ('address' and 'network') with descriptions. The tool description does not add any additional meaning or context to these parameters beyond what the schema already provides, so 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 a detailed breakdown of risk vectors, listing four specific categories (Asset Composition, Platform and Strategy, etc.). It uses a specific verb ('Get') and resource ('vault's risk breakdown'), and distinguishes well from sibling tools like 'compare_vaults' or 'explain_risk_score'.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage when a detailed risk breakdown is needed, but does not mention exclusions or contexts where other tools (e.g., 'explain_risk_score' or 'find_safest_vaults') might be more appropriate.

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, description carries full burden and succeeds well: defines the 365-day time window, clarifies severity logic ('Critical = severity Critical or incident_severity major'), and discloses sorting behavior (TVL desc, then time since event asc). Missing return structure details.

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 information-dense sentences with zero waste. Front-loaded with the core action, followed immediately by scope constraints and result ordering. 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 parameterless tool, description comprehensively documents the query logic (severity criteria, time window, sorting). Minor gap: lacks description of return values, though 'List vaults' provides some implicit guidance.

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?

Zero input parameters per schema, which establishes baseline score of 4. Description correctly implies no user-configurable filters are available (all filtering is preset by the tool's business logic).

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?

Excellent specific purpose: verb 'List' + resource 'vaults' + specific scope 'that had a recent critical incident (last 365 days)'. The incident-focused criteria clearly distinguishes this from siblings like search_vaults, get_vault, 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?

Defines the specific domain (critical incidents within 365 days) which implicitly suggests when to use it (incident investigation), but lacks explicit contrasts with alternatives like search_vaults or guidance on when this vs. get_vault_risk_breakdown is more appropriate.

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 should fully disclose behavior, but it only mentions pagination without detailing pagination mechanism (e.g., page token, offset). It omits important behaviors like rate limits, auth requirements, data freshness, or whether filters are exact or fuzzy.

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

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

The description is concise with two sentences, front-loading the main purpose and key features. No unnecessary words 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?

Given 10 parameters, no output schema, and many siblings, the description is insufficient. It lacks details on pagination mechanics, output structure (beyond risk scores and APR), and how to interpret results. Missing critical context for effective use.

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 each parameter already has a description. The tool description adds no extra meaning beyond summarizing filter types (e.g., 'by chain, protocol, asset'). It does not explain defaults, interactions, or output behavior beyond mentioning pagination.

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 searches and filters DeFi vaults by various criteria, including chain, protocol, asset, risk tier, and TVL, and returns a paginated list with risk scores and APR. However, it does not explicitly differentiate from sibling tools like compare_vaults or get_vault, which could cause confusion about when to use each.

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 provided on when to use this tool versus alternatives. The description lacks any mention of prerequisites, when not to use it, or how it compares to siblings like find_safest_vaults or get_vault_risk_breakdown.

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