Graph AAVE MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.0.0
Disambiguation3/5
While each tool has a detailed description, there are several pairs with overlapping purposes (e.g., get_aave_liquidations vs get_risk_liquidations, get_aave_reserves vs get_v4_reserves, and multiple user-position tools). The high number of similar names could confuse an LLM despite the descriptions.
Naming Consistency2/5
Tool names use a mix of prefixes (get_, list_, find_, simulate_, query_) and sometimes include version (v4) or omit it. There is no consistent verb_noun pattern across the set, making it harder to infer behavior from the name alone.
Tool Count3/5
40 tools is on the high side, bordering on heavy. However, the server covers multiple AAVE versions, chains, and sub-domains (governance, risk, V4), so the count is somewhat justified. Some tools could be merged without loss of clarity.
Completeness4/5
The tool surface covers most expected queries: reserves, user positions, history, governance, risk, flash loans, liquidations, and raw subgraph access. Minor gaps exist (e.g., no cross-chain V2/V3 user summary, no tool to fetch all positions across chains), but overall it is comprehensive.
Average 4.1/5 across 40 of 40 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 40 commits in the last 12 weeks
- Last stable release on March 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions 'Powered by Chainlink oracles' (data source) and 'No API key needed' (authentication), but does not disclose rate limits, caching behavior, data update frequency, or error handling for invalid token addresses. The behavioral profile is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences covering purpose, source, and access. It is front-loaded with the primary action and resource. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters (all described in schema) and no output schema, the description could be more complete. It does not mention return format (time series, min/max, etc.), data granularity, or time range constraints. For a historical data tool, such details would help the agent understand output shape. However, the schema covers parameter descriptions, so overall completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a baseline description in the schema. The tool description adds 'Powered by Chainlink oracles' and 'No API key needed', which are not parameter-specific. It does not explain parameter semantics like window values (e.g., what 'LAST_WEEK' means) or token address format. Thus, it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get historical price data for an Aave V4 asset', specifying the verb and resource. It distinguishes from siblings like 'get_aave_reserve' or 'get_recent_borrows' by focusing on price history. The additional notes about Chainlink oracles and no API key add context without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_reserve_rate_history' or 'get_v4_exchange_rate'. It does not state prerequisites, when-not to use, or recommend other tools. The only contextual hint is 'No API key needed', which is useful but insufficient for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'No API key needed', which addresses authentication. However, it does not confirm the tool is read-only, describe any side effects, or mention rate limits or data freshness. More behavioral context is needed for safe agent usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, front-loaded with the main action. Every word contributes meaning without redundancy. It is highly concise and structured well for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose and authentication requirement but lacks details on return format, error handling (e.g., invalid address), or behavior when no supplies exist. More completeness would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (chainId as filter, userAddress as EVM address). The description adds no additional parameter semantics beyond the schema, and the mention of 'principal, interest, and collateral status' refers to output, not input parameter meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's Aave V4 supply positions, specifying the included data (principal, interest, collateral status). The verb 'Get' and resource 'supply positions' are specific, and the tool is distinguished from siblings like get_v4_user_borrows and get_v4_user_positions by focusing solely on supplies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It only mentions that no API key is needed, but does not state when not to use it, such as when borrow positions are needed instead. Given the presence of closely related siblings (get_v4_user_borrows, get_v4_user_positions), usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description only indicates a read operation and that no API key is needed. It omits important behavioral details such as side effects, data freshness, pagination, or response format, leaving the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the tool's purpose. It is concise but could benefit from slight restructuring to separate the list of activities from the API key note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and no output schema, the description lists transaction types but lacks information on pagination, time range, ordering, or return structure. This is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description does not add any additional meaning or context beyond what is in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's Aave V4 transaction history and enumerates specific types (supplies, borrows, etc.), distinguishing it from sibling tools like get_v4_user_borrows or get_v4_user_supplies that return narrower subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No API key needed' as a convenience, but it does not provide explicit guidance on when to use this tool versus alternatives like get_v4_user_supplies. Usage context can be inferred but is not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return fields and the health factor condition, but does not disclose pagination behavior, ordering, or any potential side effects (though read-only). Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded with usage examples. Every sentence adds value without redundancy. Structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covers return fields and basic context, but lacks details on data format, ordering, and pagination. Partially complete for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about liquidation events but does not elaborate on parameter semantics beyond example queries. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for AAVE liquidation events with specific example queries, making the purpose unambiguous. However, it does not explicitly distinguish from sibling tool 'get_risk_liquidations', which might cover similar non-AAVE liquidations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios with example questions, but lacks guidance on when NOT to use this tool or mention of alternatives like 'get_risk_liquidations'. No exclusions or contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It fails to disclose any limitations, such as data freshness, pagination, or rate limits. It only notes that no API key is needed, which is a minor access detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence providing the core purpose and the second adding a useful note. No extraneous words, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the basics but could inform about the output format or data granularity. It is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with 'Time window' for the only parameter. The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the specific resource 'Aave V4 protocol-wide historical data', and the data contents 'total deposits and borrows over time in USD'. It is distinct from sibling tools that focus on specific entities like reserves, users, or assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No API key needed', which provides a prerequisite, but does not explicitly compare with sibling tools or indicate when to use this tool versus more specific alternatives like 'get_aave_reserve' or 'get_v4_user_borrows'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read operation via 'Get' but does not disclose any behavioral traits such as rate limits, authentication details (beyond no API key), or potential side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one for purpose and one for authentication. No unnecessary words, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description could be more complete by hinting at the return format (e.g., list of reward amounts or tokens). However, the tool name and context from siblings suggest it returns reward data. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description does not elaborate on parameters beyond what the schema provides, but it adds context by specifying 'claimable Merkl and points rewards', which clarifies the tool's scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'a user's claimable Merkl and points rewards on Aave V4'. It distinguishes the tool from sibling tools, none of which focus on rewards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No API key needed', which provides a positive usage note, but lacks explicit guidance on when to use this tool versus alternatives like get_v4_user_balances or other user-centric tools. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it returns 'principal, debt, interest' but omits details like authentication requirements, rate limits, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences that front-load the purpose and key differentiator (no API key). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains return values (principal, debt, interest) but lacks structural details. For a simple tool it is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters adequately. The description does not add new semantic information beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves a user's Aave V4 borrow positions, listing key data points (principal, debt, interest). This distinguishes it from sibling tools like get_v4_user_supplies or get_v4_user_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 note 'No API key needed' provides some context but no comparison with siblings or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the purpose but does not disclose behavioral details like rate limits, auth requirements, or what happens when no history exists. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. It front-loads the core purpose, adds a usefulness statement, and ends with concrete example queries. Slightly more structure could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an explanation of the output format (e.g., array of objects with health factor and block number) since no output schema is provided. It also does not address error cases or edge conditions. Given the three simple parameters, it is moderately complete but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the input schema (100% coverage). The description adds minimal extra meaning beyond what the schema already provides (e.g., that 'first' controls number of snapshots). The baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's health factor history over time, block by block. It uses a specific verb ('Get') and resource ('health factor history'), and distinguishes itself from snapshot tools like get_user_risk_profile through its focus on historical trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries ('How has this wallet's health factor changed?') and states it is useful for trend analysis and detecting deterioration. It implies when to use but does not explicitly exclude scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool returns transitions between risk states and includes health factor and timestamp. However, it omits details like ordering, pagination limits, and whether alerts are real-time or historical, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the core purpose and then adding example queries. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 lists return fields (previous/new risk level, health factor, timestamp). It covers the primary use case but lacks details on ordering, alert age, or how to interpret missing data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description implicitly references the 'chain' parameter (e.g., Polygon) and 'userAddress' (wallet filter), adding some context beyond the schema. It does not elaborate on the 'first' parameter, which remains default-driven.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent risk level transitions and lists specific fields (previous/new risk level, health factor, timestamp). It distinguishes the tool's purpose from generic risk queries, but does not explicitly differentiate from siblings like get_at_risk_positions or get_health_factor_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three concrete example queries covering common user intents ('Which positions recently became at risk?', 'Show me health factor drops on Polygon', 'Has wallet 0x... had any risk alerts?'). This gives clear usage context, though it does not specify when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states that no API key is needed, which is positive. However, it does not mention other behavioral traits like data freshness, rate limits, expected response size, or any side effects (though it is a read operation). The transparency is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose and ends with a key usage note. Every word adds value, with no redundancy. This is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, no output schema, and no nested objects, the description provides sufficient context: what the tool returns and the lack of authentication requirement. It could be slightly improved by hinting at output format or error cases, but overall it is complete enough for an AI agent to understand its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (chainId and tokenAddress) described in the schema. The description does not add additional meaning to the parameters; it simply restates the tool's purpose. Thus, it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('Aave V4 asset details'), and the specific data returned (total supplied/borrowed, average APY, price). This distinguishes it from sibling tools like get_v4_reserves or get_v4_user_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a useful guideline ('No API key needed'), indicating ease of access. However, it does not provide guidance on when to use this tool versus alternatives, such as get_v4_reserves which might also return asset-level data. No exclusion criteria or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states it supports various tokens but omits critical details like read-only nature, data freshness, error handling, or behavior with conflicting parameters (e.g., 'native' and 'tokenAddress' both set).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences), front-loaded with the core purpose, and avoids any redundant information. Each phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, the description adequately covers the main function. However, since there is no output schema, mentioning what the return value contains (e.g., plain number vs. detailed object) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all four parameters (100% coverage). The description adds meaning by contextualizing parameter usage (e.g., 'native' for ETH, 'to' for fiat, 'tokenAddress' for ERC-20), enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting exchange rates for tokens via Aave V4's Chainlink oracle. It specifies supported types (ERC-20, native tokens, fiat) and distinguishes from sibling tools like 'find_best_rates' or 'get_v4_asset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching exchange rates and mentions 'No API key needed', but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'find_best_rates') or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'No API key needed', which is useful, but lacks details on read-only behavior, rate limits, or response structure. The APY mention adds some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no wasted words. Key information (verb, resource, special features, auth requirement) is conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core functionality and a notable behavioral trait (no API key). It does not explain output format or limitations, but the tool's complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for userAddress. The description does not add extra parameter semantics beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'user's cross-chain token balances in Aave V4', and adds differentiation by mentioning 'highest supply APY and lowest borrow APY per token'. It distinguishes from sibling tools like get_v4_user_positions or get_v4_user_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving balances with APY highlights but does not explicitly state when to use over siblings or when not to use. No alternatives or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It implies a read operation but does not disclose any potential side effects, rate limits, or data freshness. The description adds value by listing output fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear structure, front-loaded with purpose and followed by a list of output fields. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the tool's purpose and output fields. Could mention potential errors or data staleness, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description does not add meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets an aggregated Aave V4 portfolio summary with specific metrics listed. Distinguishes from sibling tools like get_aave_user_position and get_v4_user_positions by being a summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions no API key needed, providing context for authorization. However, it does not explicitly state when to use this tool versus alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool returns specific fields (health factor, risk score, etc.), implying a read-only operation, but does not disclose any behavioral details like rate limits, authentication needs, or whether it modifies data. This is adequate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and output fields, followed by three concrete example queries. Every sentence is efficient and adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description explains the return fields (health factor, risk score, risk level, collateral, debt). It covers the 5 chains and filter options. For a tool with 3 parameters and moderate complexity, it is largely complete, though it could mention pagination or sorting behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters (100% coverage), so the baseline is 3. The description adds marginal value by showing example usage and implying parameter combinations, but does not provide additional semantic context beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds Aave positions at risk of liquidation across 5 chains, listing specific return fields. It distinguishes itself from siblings like get_aave_user_position (single user) and get_cross_chain_risk_summary (summary) by focusing on at-risk positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries (e.g., 'Which positions are close to liquidation on Arbitrum?') that guide when to use the tool. However, it does not mention exclusions or alternatives, though the sibling tools are available for more specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies a read operation but does not explicitly state that it is read-only, nor does it discuss authentication, rate limits, or data freshness. For a simple aggregate query, this is acceptable but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus example queries, with no unnecessary words. Every part adds value, and the structure is front-loaded with the core purpose followed by usage examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers purpose and usage. It could mention the output format or structure, but overall it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (chain) is fully documented in the schema with an enum and description, achieving 100% schema coverage. The description adds no new semantic information beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregate risk statistics for Aave on a chain, listing total positions and danger/warning/critical states. It includes example user queries, making the purpose very specific and distinguishable from sibling tools like get_at_risk_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when asked:' and provides three concrete example queries, giving clear context for when to use the tool. However, it does not mention when not to use it or provide alternatives, which would strengthen the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses read-only nature and no auth requirement, but lacks details on rate limits, pagination, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading key information, no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, description adequately covers purpose, returned data, and auth requirement. Missing minor details like default behavior for omitted parameter (though schema implies default).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (chainId) with schema coverage 100%. Description adds no extra info beyond what schema already provides, so baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (Get), resource (Aave V4 liquidity hubs), and specific data returned (TVL, utilization, supply/borrow caps). It distinguishes from sibling tools that focus on other aspects like reserves or swaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'No API key needed,' providing a usage guideline. However, it does not specify when to prefer this tool over siblings or give exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the operation is read-only, safe, or has any side effects. While the output is described, critical behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The purpose and usage examples are front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the essentials: what it lists and when to use it. However, the lack of behavioral transparency slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. Per the rubric, this yields a baseline of 4. The description adds no parameter info as there are none, but the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'liquidation risk subgraph chains', and specifies the returned fields (names, networks, subgraph IDs, query volumes). It also provides example user queries, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use when asked...') with example questions, offering clear context. However, it does not mention when not to use it or alternatives like list_aave_chains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns queryable root fields and types, implying read-only safe behavior. It lacks details on rate limits, permissions, or side effects, but for a schema introspection tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and to the point. The first sentence states the purpose, the second provides usage context. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity introspection tool with no output schema, the description fully informs the agent of what to expect (all queryable root fields and types) and when to use it. It is complete enough for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'chain' with an enum and description. The tool description adds no extra meaning beyond what the schema already provides (chain identifier including governance). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool introspects the full GraphQL schema for any AAVE chain subgraph, specifying the action and resource. It distinctly differentiates from siblings like query_aave_subgraph by indicating it is a preparatory step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells when to use the tool: before writing a custom query_aave_subgraph call or to understand available data. It implies this is for exploration, not execution, but does not explicitly mention when not to use it or list all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 correctly implies a read-only operation by listing outputs like APYs and risk params. It states no API key is needed. However, it does not explicitly declare read-only status or discuss other behaviors like rate limits or data freshness. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and wastes no words. Every sentence adds value: the first states what the tool returns, the second provides sibling differentiation and access note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the key outputs (APYs, risk params, status) and the access requirement (no API key). It provides enough context for an agent to know what it will receive and that no authentication is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter chainId, which already has a description. The tool description mentions 'No API key needed' but adds no additional meaning to the chainId parameter beyond what the schema provides. According to the baseline rule for high coverage (>,80%), a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Get Aave V4 reserves with supply/borrow APYs, risk params (collateral factor, caps), and status.' It also explicitly differentiates from the sibling tool get_aave_reserves by directing users to that for V2/V3, leaving no ambiguity about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance (for V4) and when-not-to (use get_aave_reserves for V2/V3). It also mentions 'No API key needed,' which is a useful prerequisite note. However, it does not address usage relative to other siblings like get_v4_asset or get_v4_user_summary, but given the large sibling list, focusing on the most similar is reasonable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that flash loans must be borrowed and repaid in one transaction, and lists the return fields. It does not mention pagination, rate limits, or permissions, but for a read-only historical query tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences cover usage, return fields, and a behavioral constraint. Every sentence adds value, with no filler. The information is front-loaded for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description compensates by listing the return fields. It also explains the single-transaction nature of flash loans. It is complete enough for a list tool, though it could mention pagination limits (covered by 'first' in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both 'chain' and 'first' are described in the schema. The description does not add new meaning beyond the schema (e.g., it doesn't explain what 'first' does or how to use 'chain'). Baseline score of 3 is appropriate since schema already documents both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns AAVE flash loans with specific fields (initiator, asset, amount, fee, timestamp). It includes example queries that help the agent match user intents like 'Show me recent flash loans on Ethereum'. This effectively distinguishes it from sibling tools like get_aave_borrows or get_aave_liquidations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user asks about AAVE flash loans' and provides concrete query examples. While it does not list alternatives or when-not-to-use, the context is sufficient for an agent to differentiate from siblings like get_recent_borrows or get_aave_liquidations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is for a read-only query tool; it implicitly indicates no side effects. It adds value beyond annotations (none provided) by listing return fields and providing a post-processing instruction for amount conversion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and usage examples, followed by return field list and data conversion advice. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, examples, return fields, and data manipulation. It lacks explicit definition of 'recent' and ordering, but is complete enough for a simple list tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description does not add additional meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent borrowing events on AAVE, with specific example queries. It distinguishes from sibling tools like get_recent_supplies and get_aave_repays by focusing on borrows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description starts with 'Use this when the user asks about recent borrowing activity' and provides example prompts. However, it does not explicitly state when not to use it or mention alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states the source and fields but does not disclose behaviors like pagination limits, error handling, or read-only nature. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: one for purpose, one for relation to sibling, one for usage examples. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 simple parameters and no output schema, description is fairly complete. It mentions output fields and example queries, but lacks explicit detail on return structure or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are well-described in schema. Description adds no further semantic insight beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets liquidation events from the risk subgraph, listing key fields. It explicitly distinguishes from the sibling get_aave_liquidations, indicating complementarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit example queries: 'Show recent liquidations on Base', 'Was this wallet liquidated?', 'What collateral was seized?' and mentions complementarity, guiding when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and 'No API key needed'. Does not mention any rate limits or potential side effects, but none are expected for a read-only quote. Adds MEV protection detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and key details. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mentions return of 'pricing, fees, and slippage' but no output schema. Sufficient for a read-only query, but could detail the output structure more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has clear descriptions in the schema. The description adds no additional parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get', the resource 'swap price quote', and the source 'Aave V4 (powered by CoW Protocol)'. Distinguishes from sibling tools like get_v4_reserves or get_v4_user_summary that deal with different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'No API key needed', implying simple access. However, lacks explicit guidance on when to use this vs. alternatives like find_best_rates or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is read-only, cross-chain, and requires no API key. It does not mention rate limits or error handling, but the single-parameter input and output field listing offer sufficient transparency for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences convey purpose, outputs, cross-chain behavior, and authentication requirements with no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists key return fields (health factor, collateral, debt, etc.) and mentions cross-chain inclusion. It provides a solid overview, though it could clarify whether results are aggregated or per-spoke. Given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal extra meaning beyond the schema—confirming 'userAddress' is an EVM wallet and that results span all spokes. This is adequate but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's Aave V4 positions across all spokes, listing specific fields like health factor, collateral, debt, borrowing power, and net APY. It distinguishes from siblings by emphasizing cross-chain scope and the list of outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: 'Cross-chain by default' and 'No API key needed.' However, it lacks explicit guidance on when to use this tool versus similar siblings like get_v4_user_summary or get_aave_user_position, which would improve decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains the internal steps (fetch position, compute health factor, apply price change) and defines the liquidatable threshold. However, it does not explicitly state that the operation is read-only or disclose authentication or rate limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the use case, and each sentence serves a distinct purpose: usage, mechanism, and key definition. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core functionality, example queries, and a critical threshold. It lacks detail on the response format or potential side effects, but overall provides sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context by aligning parameters with the simulation scenario (e.g., assetSymbol as the target asset, priceChangePct with negative example). This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: simulating how a price change affects AAVE health factor. It provides specific example queries and explains the computation steps. This distinctly sets it apart from siblings, which are mostly data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance with example user requests. However, it does not mention when not to use it or suggest alternative tools like get_aave_user_position for simply viewing current health factor, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses rate units (RAY, 1e27), conversion formulas for APY percentages, and decimal handling for amounts. Does not mention pagination or data freshness, but for a straightforward read 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage context. Multiple sentences but each contributes: usage trigger, sorting, rate conversion, amount units, and example queries. Slightly verbose (could trim example list) but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers parameter usage, return format interpretation (rates, amounts, sorting), and common queries. Does not detail the JSON structure of each reserve, but the explanations of RAY and decimals make the output understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100% coverage). Description adds valuable context: chain parameter references list_aave_chains for valid options, and includeInactive is explained with default behavior. Also explains return value interpretation (rate conversion, amount decimals) beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes exactly what the tool does: returns all active AAVE reserves sorted by TVL for a given chain. Clearly distinguishes from siblings like get_aave_reserve (single reserve) and find_best_rates (rate comparison) by specifying the scope and sorting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user asks about AAVE markets, supply/borrow rates, etc.) and provides concrete example queries. References sibling tool list_aave_chains for valid chain values. Lacks explicit exclusion guidance (e.g., when to use other tools) but examples cover common cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully explains that the tool queries the AAVE Governance V3 subgraph and lists the return fields. It also enumerates proposal states and their numeric codes, providing essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with usage guidance and then providing technical details. It is slightly lengthy but each sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no nested objects, no output schema), the description covers the purpose, parameters, and return fields comprehensively. It provides enough context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameters (first, state). The description adds value by explaining the meaning of state numbers (e.g., 1=Active) and access levels (1=short executor/2=long executor), which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: querying AAVE governance proposals. It provides concrete example queries and distinguishes it from sibling tools by focusing specifically on governance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage guidance with example queries and context ('when the user asks about AAVE governance'). It doesn't explicitly state when not to use, but the sibling tools are mostly non-governance AAVE operations, making the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the tool returns timestamped snapshots with specific fields (liquidityRate, etc.) and explains the RAY unit conversion to APY. This gives sufficient transparency for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with usage instructions and example queries. It is concise but packs necessary details. A more structured format (e.g., bullet points) could improve readability, but the current form is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description adequately explains the return fields and unit conversion. It also provides a critical hint for obtaining the reserveId. The description is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage). The description adds extra context beyond the schema, such as explaining how to obtain the reserveId from get_aave_reserves and the default/max for 'first'. This enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose by providing example queries ('How has USDC supply rate changed over time?') and states it returns historical AAVE rates and TVL trends. It lists the specific fields returned, making it distinct from siblings like get_aave_reserve which returns current data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context ('Use this when the user asks about historical AAVE rates or TVL trends') and example queries. It also directs the user to get the reserve ID from get_aave_reserves, providing a clear prerequisite. However, it does not explicitly state when not to use it or name alternatives for current rates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that no API key is needed, a useful behavioral trait beyond the empty schema. Could mention rate limits or output format, but the simple nature of the tool makes this adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The main purpose is front-loaded, and the second sentence adds a key note about API key requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description provides all necessary context: what is listed and authentication requirements. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. Baseline for no parameters is 4. Description adds no parameter info, which is acceptable as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all chains supported by Aave V4'), clarifying scope (mainnet and testnet). It clearly distinguishes from siblings like list_aave_chains, which may cover other protocol versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to list all Aave V4 chains) but does not explicitly exclude cases or reference alternatives like list_aave_chains. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that no API key is required and returns a list of spokes with examples. This adds transparency beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first lists examples, second defines spokes and mentions no API key. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description fully covers purpose, examples, and access requirements. The agent can correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for chainId: 'Chain ID. Defaults to Ethereum.' The tool description does not add additional semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves Aave V4 spokes, provides examples (Main, Bluechip, etc.), and defines spokes as chain-specific deployment points. This distinguishes it from sibling tools like get_v4_hubs or get_v4_chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No API key needed,' indicating simple access. It doesn't explicitly contrast with siblings, but the purpose is straightforward enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It states output but does not mention read-only nature, data freshness, or any side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient single paragraph with no wasted words. Clearly states usage, output, and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description fully covers what the agent needs: purpose, when to use, and what data is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. The description adds value by detailing the return contents, which compensates for lack of param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is used to list supported AAVE chains and includes specific output details like subgraph IDs and protocol versions. It clearly distinguishes from siblings by being the go-to for chain discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use (user asks for supported chains, ambiguous chain) and advises to call first. Lacks explicit exclusions or alternative tools, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that queries are in parallel, excludes certain chains/pools, and returns a ranked table with recommendation. It does not cover rate limits, data freshness, or error handling, but the core behavior is well described for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (approximately 100 words) and front-loaded with usage examples. Each sentence adds unique information: examples, behavior, exclusions, output details, and recommendation. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters and no output schema, the description adequately explains the output fields (chain, APYs, utilization, liquidity) and includes a recommendation field. It could mention handling of no results or multiple tokens, but it is sufficient for the tool's scope among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value beyond the schema by clarifying case-insensitive partial match for asset, elaborating on the side parameter's meaning (rank by highest vs lowest), and reinforcing defaults. This provides helpful context for correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: querying AAVE lending deployments for a given asset and ranking by APY. It provides clear usage examples ('Where should I supply USDC for the best yield?') and differentiates from sibling tools that focus on individual reserves or user positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives specific user queries that trigger this tool, indicating when to use it. It also notes exclusions (Fantom, anomalous pools) but does not explicitly state when not to use it or provide alternatives among siblings. The context is clear but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output fields (repayer address, asset, amount, timestamp) and gives transformation guidance (divide by decimals). No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first gives usage with examples, second describes output. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, parameters, and output. Lacks details on ordering or pagination, but the schema provides default and max values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond schema by explaining how parameters filter repay events and mentions specific asset symbols. Also clarifies amount post-processing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for AAVE debt repayment activity with specific example queries, distinguishing it from related tools like get_recent_borrows or get_aave_liquidations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use and provides example queries, but does not mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return values (full reserve config, rates, TVL, etc.) and includes a rate conversion formula. No annotations are provided, so the description carries the full burden, which it handles well. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with usage guidance, then return content, then a conversion tip. Every sentence is informative and concise, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately explains what data is returned and provides a conversion hint. It lacks explicit mention of error cases or performance, but is sufficient for a detail retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter, but the description adds useful context such as case-insensitivity for symbol and examples tying parameters to use cases. This adds marginal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Use this when the user asks about a specific AAVE asset in detail' with concrete examples (e.g., 'Tell me everything about USDC on Ethereum AAVE'), identifying the specific verb (get) and resource (reserve) and distinguishing it from sibling tools like get_aave_reserves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use with examples and context ('e.g. Tell me everything about USDC...'), but does not explicitly state when not to use or provide alternative tools for comparison, though the differentiation from siblings is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses return values (forVotes, againstVotes) and a limitation (no per-voter records). Could specify error handling for invalid proposal IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading usage and return details with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values (aggregate totals). Lacks response format example or error behavior, but sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description already explaining proposalId. Description adds no new parameter semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns aggregate vote totals for an AAVE governance proposal, with specific examples like 'How did proposal #X vote?' and distinguishes from siblings like get_governance_proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples and notes that individual per-voter records are not indexed, guiding the agent to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the action as executing a raw GraphQL query, which implies read-only, but does not explicitly state it is non-destructive or mention any side effects, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet packed with information: purpose, usage condition, prerequisite, and entity lists. Front-loaded with the key usage rule, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw query tool, it provides entity lists and chain options, but lacks explanation of output format or error handling. However, given standard GraphQL responses and the complexity of the tool, it covers essential usage context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value by enumerating chain options (from the enum) and suggesting use of get_aave_schema for query construction, aiding parameter comprehension beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: execute raw GraphQL queries when pre-built tools are insufficient. It specifies the verb 'execute' and resource 'AAVE chain's subgraph', and distinguishes from sibling tools by indicating it's a fallback option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when a pre-built tool doesn't cover the user's need' and advises to 'Use get_aave_schema first to explore available entities and fields'. Lists entities for lending and governance schemas, providing clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns empty arrays if no position exists, explains the health factor formula, mentions amounts in native token units requiring decimal division, and lists return fields. It doesn't mention authentication or rate limits, but these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with usage examples and concisely covers all key aspects: purpose, example queries, return fields, health factor formula, and decimal handling. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description provides a thorough explanation of returns (supplied assets, borrowed assets, health factor, etc.), the health factor formula, and the decimal handling requirement. It is complete enough for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage). The description adds value by explaining the chain enum list, the userAddress format, and the behavior when no position exists (empty arrays). It also describes the output structure, which goes beyond schema requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a wallet's AAVE position including supplied assets, borrowed assets, health factor, collateral flags, and e-mode category. It provides concrete example queries, distinguishing it from siblings like get_aave_reserve or get_aave_liquidations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user asks about a wallet's AAVE position' and gives multiple example queries. While it doesn't explicitly list when not to use, the context of sibling tools (e.g., get_aave_reserve for a single reserve) implies appropriate usage. Could be more explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 return fields (supplier, asset, raw amount, timestamp) and advises adjusting by decimals for human-readable values. It mentions automatic version handling. Missing explicit statement on ordering (presumably descending by time) and pagination limits are covered by the schema. Overall transparent enough for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: 3 sentences, with usage examples embedded in the first sentence. It is front-loaded with the key purpose and usage guidance, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple chains, V2/V3 variants, optional filters), the description covers the main aspects: purpose, usage, parameter handling, and return values. The absence of output schema is mitigated by describing return fields. Minor missing details: ordering of results (most recent first) and any rate limits or authentication needs, but these are not critical for a read action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters have descriptions). The description adds significant value beyond schema: it explains how to convert raw amounts using decimals, that V3 uses 'supply' and V2 uses 'deposit' automatically, and what the returned fields represent. This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent deposit/supply activity on AAVE, with specific examples for different chains and assets. It distinguishes itself from sibling tools like get_recent_borrows and get_aave_liquidations by focusing on supply events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this when the user asks about recent deposit/supply activity on AAVE.' It also explains automatic handling of V2 vs V3 chains. However, it does not explicitly mention when not to use it (e.g., for borrows or liquidations), though the context from sibling tools makes this implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains that the tool returns health factors, risk scores, collateral, and debt, implying a read-only operation. It does not mention any destructive actions, authorization needs, or rate limits, but the behavioral transparency is good for a simple data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with example queries front-loaded. Every sentence adds value without redundancy. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two simple parameters, no output schema, and the description covers the returned data (health factors, risk scores, etc.), it is complete. The examples cover the intended use cases, and the description is sufficient for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds value beyond the schema. The description contextualizes the 'chain' parameter by referencing examples like 'on Base', and clarifies that 'userAddress' is a wallet address. This helps the agent map parameters to use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's full liquidation risk profile on a specific chain, including positions, health factors, risk scores, collateral, and debt. It distinguishes itself from sibling tools like get_aave_user_position and get_at_risk_positions by focusing on risk profile across multiple positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries (e.g., 'Is wallet 0x... at risk of liquidation?', 'What's the health factor for this address on Base?'), guiding the agent on when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, but the examples are sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields: total positions, danger/warning/critical counts. However, does not mention read-only nature or lack of side effects, but given zero parameters, is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering purpose, output, and usage examples. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No parameters or output schema, yet description fully explains what the tool does and returns. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, baseline is 4. Description adds context on output, exceeding baseline. No schema to compensate for, so high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a cross-chain risk overview across all 5 chains' with specific verb and resource. Distinguishes from sibling tools like 'get_protocol_risk_stats' which are single-chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit example queries such as 'Which chain has the most at-risk positions?' and 'Compare Aave risk levels across networks', telling when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![graph-aave-mcp MCP server](https://glama.ai/mcp/servers/PaulieB14/graph-aave-mcp/badges/card.svg)](https://glama.ai/mcp/servers/PaulieB14/graph-aave-mcp)

Score Badge

Copy to your README.md:

[![graph-aave-mcp MCP server](https://glama.ai/mcp/servers/PaulieB14/graph-aave-mcp/badges/score.svg)](https://glama.ai/mcp/servers/PaulieB14/graph-aave-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaulieB14/graph-aave-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server