MetaVault MCP

Server Quality Checklist

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

Latest release: v2.1.0
Disambiguation5/5
Tools are clearly organized by protocol (spectra_, pendle_, morpho_, mv_) with distinct purposes. Even similar-sounding tools like spectra_scan_opportunities and pendle_scan_opportunities are well-differentiated by the protocol they target and their descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with protocol prefixes (e.g., spectra_list_pools, pendle_get_market_details). Naming is uniform and predictable, making it easy for agents to understand tool purpose from name alone.
Tool Count2/5
With 56 tools, the server is significantly over the typical 3-15 range for a well-scoped server. While the domain is complex, this many tools risks overwhelming agents and suggests the tool surface could be consolidated.
Completeness5/5
The tool set covers all major operations across Spectra, Pendle, Morpho, and MetaVaults: listing, details, quotes, portfolio, activity, history, strategies, risk, governance, and cross-protocol analysis. No obvious gaps for the intended yield optimization and risk management use case.
Average 4.5/5 across 56 of 56 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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, the description carries full burden. It discloses non-uniform coverage but omits behavioral details like output format, authentication needs, or rate limits, providing only minimal transparency.
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?
Three sentences efficiently convey purpose and key usage notes. Front-loaded with main action, it is concise but could be slightly more structured.
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 no-parameter list tool without output schema, the description covers the essential purpose and provides context about varying coverage, making it sufficiently complete for an AI agent.
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 exist (0 params), so baseline is 4 per rules. The description adds value by explaining the tool's purpose and coverage nuances, which complements the empty 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 lists all blockchain networks supported by Spectra Finance, with a specific verb and resource. It distinguishes from siblings by being a starting point, though not explicitly differentiating from other list tools like spectra_list_pools.
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?
It advises using this as a starting point to discover available networks and notes that coverage varies, providing examples. However, it lacks explicit guidance on when not to use it or alternatives, leaving usage context implied but not fully specified.
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 burden. It explains the comparison logic between underlying APY and implied rate, and contrasts execution with Spectra. It implies a read-only scan operation, which is consistent. Could be more explicit about no side effects.
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 with bullet points and comparisons, earning its length. It is slightly verbose but each part adds value. Could be trimmed slightly but remains effective.
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 explains the concept and related tools but lacks details about the output format. Without an output schema, describing typical return fields (e.g., opportunity list with spreads, APYs) would improve completeness.
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 9 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds minimal extra semantics beyond the schema, mainly reinforcing the spread concept. It does not introduce new parameter details.
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 scans Pendle markets for YT mispricing, explaining the concept of positive/negative spreads. It distinguishes from sibling tools like pendle_scan_opportunities and spectra_scan_yt_arbitrage by explicitly mentioning execution differences.
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 explains when to use the tool (scan for YT arbitrage) and provides cross-references to pendle_get_market_details for deep dives and mv_compare_yield for cross-protocol comparison. It does not explicitly state when not to use it, but the context is 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?
No annotations provided, so the description fully bears the burden. It discloses the tool uses the Pendle logit AMM model and estimates outputs including slippage. It implies no side effects or destructive actions, which is appropriate for a quote tool.
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 moderately long but well-organized with bullet points for outputs, a clear side explanation, and sibling tool references. Every sentence adds value; no redundant or wasted 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?
Given the tool's complexity (trade estimation with slippage, APY), the description covers key outputs and parameter semantics. It references sibling tools for deeper analysis. No output schema exists, but the description lists expected outputs sufficiently.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds context for the side parameter (buy vs sell token types) and mentions default slippage, but this information is already in the schema. The description adds minimal extra meaning beyond what is already structured.
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 estimates expected output, price impact, and effective APY for a Pendle PT trade. It differentiates from siblings like pendle_get_market_capacity and pendle_get_market_details, and is explicitly linked as the Pendle equivalent of spectra_quote_trade.
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 explains the tool is for trade estimation and provides side semantics. It directs users to pendle_get_market_capacity for multi-size impact curves and pendle_get_market_details for full market info, offering clear alternatives. No explicit 'when not to use' but strong 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?
Discloses parallel calls, honest failure reporting, and specific detection features. No side effects or destructive actions are needed, but lacks details on data freshness or rate limits. Without annotations, the description is fairly transparent.
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?
Well-structured with front-loaded purpose, a bulleted feature list, and usage guidance. Each sentence adds value, though slightly lengthy for a tool description.
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?
Complex tool without output schema. Description outlines output contents (summaries, totals, contradictions) but lacks specifics on format or structure. Adequate but could be more precise for agent invocation.
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%, and the description does not add meaning beyond the schema. The description mentions omitting chain scans all, but the schema already states that. No additional parameter insight.
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 'Cross-protocol position map' and lists specific capabilities (per-protocol summaries, governance tokens, contradiction detection). It distinguishes from siblings by explicitly naming per-protocol tools it does not replace.
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 recommends using as 'the FIRST call when analyzing a wallet' and clarifies it does not replace per-protocol tools, suggesting when to use alternatives like spectra_get_portfolio.
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, so description bears full burden. Details weighting formula, file format, default directory, and env var override. Does not mention auth or side effects, but tool appears read-only and safe.
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?
Well-structured with purpose first, then usage, formula, file format, and defaults. A bit lengthy but each section earns its place. Could be slightly more terse.
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?
Covers usage, weighting, file format, and parameters thoroughly. However, lacks description of the output format (what the loaded scars look like). Tool is complex; output structure is important for an agent.
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%, adding baseline of 3. Description adds significant value: explains top_n limiting, include_body default, filter_type options, and scar_dir override chain. Also describes weighting formula and file frontmatter 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 'Load the system's accumulated scars' with specific verb and resource. It explains the weighting by recency × reinforcement, and the tool is distinct from all DeFi siblings.
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?
Specifies use in audit lenses, especially the Diverger lens. Provides concrete usage context but does not explicitly exclude alternative tools or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not explicitly state that the tool is read-only or has no side effects. However, the 'get' verb implies a safe operation, but transparency 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?
Concise and well-structured: purpose first, then return fields, then usage guidance. Every 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?
Despite no output schema, the description lists all major return fields (market name, addresses, APY, TVL, etc.), making it comprehensive for typical use. Also provides contextual sibling and follow-up tool suggestions.
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 parameters fully described in schema). The description adds no additional semantic detail 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 tool retrieves detailed information about a specific Pendle market by address, distinguishing it from listing tools like pendle_list_markets and the Spectra equivalent spectra_get_pt_details.
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 states when to use (after finding via pendle_list_markets, mv_compare_yield, etc.), mentions equivalence to spectra_get_pt_details, and suggests follow-up tools like mv_check_ibt_health and mv_compare_yield.
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; description explains the underlying logit AMM model and time-decay pricing behavior, though it does not mention read-only nature 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with key information front-loaded, but could be slightly more structured; no wasted sentences.
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?
Provides sufficient context for understanding purpose and use, but lacks description of the output format or return values.
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%; description does not add meaningful context beyond the schema's parameter 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 computes price impact and effective APY degradation as capital grows, and distinguishes it from siblings like pendle_get_market_details and pendle_scan_opportunities.
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 guidance on when to use (finding sweet spot and exhaustion point) and explicitly mentions alternatives and equivalent tools (spectra_get_pool_capacity).
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. Describes output grouping by urgency with clear thresholds (≤7d, ≤14d, ≤threshold). Does not explicitly state read-only behavior but implies it as a scanning tool. Lacks details on output structure (e.g., market addresses, maturity dates), but provides sufficient context for an agent to understand what this tool does.
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 main purpose and then provides urgency details, use cases, and alternatives. Well-structured but slightly verbose with the bullet-style urgency descriptions. Could be more concise, but each 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?
Completeness is high given the tool's complexity and no output schema. Description covers purpose, urgency grouping, use cases, and alternatives. However, it does not explain the exact output fields or how the grouping is presented (e.g., categories as separate arrays), leaving some ambiguity.
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?
Parameter schema coverage is 100%, so baseline is 3. Description does not add any additional meaning to the parameters; it focuses on output grouping and use cases. The schema descriptions are already adequate for understanding each parameter.
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 'Scan Pendle chains for markets approaching maturity' and explicitly differentiates from sibling tool spectra_list_expiring_pools. The verb 'scan' and resource 'markets approaching maturity' are specific and distinct from other Pendle tools.
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 use cases for portfolio managers, curators, and traders. Lists three alternative tools with specific scenarios: pendle_get_market_details for full info, mv_plan_rollover for rollovers, and pendle_get_yield_curve for replacements. This gives clear guidance on when to use this tool vs 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?
Discloses that rankings are by raw APY without considering capital size or liquidity, and explains the different focus from the sibling tool. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three paragraphs, front-loaded with main purpose. Additional explanation of ranking trade-offs is useful but could be slightly trimmed. No redundant 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?
Covers purpose, parameters, and differentiation from sibling. No output schema, but description implies return of top opportunities ranked by APY. Missing details on actual response format, but sufficient for a read-only query 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. Description adds context for compact parameter ('use for quick scanning') and states asset filter, but does not substantially enhance understanding 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?
Clearly states 'Find the best fixed-rate yield opportunities across all Spectra chains' and distinguishes from sibling spectra_scan_opportunities by explaining difference in ranking methodology.
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 tells when to use (to find best fixed yields), and provides guidance on when to use this vs. spectra_scan_opportunities, with clear explanation of the intentional disagreement in rankings.
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 automatic symbol normalization (USDC.e, WETH, wstETH → normalized), sorting by maturity, and implied APY calculation. However, it does not mention read-only behavior, auth requirements, or rate limits. Still, the behavioral traits are well communicated.
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?
Well-structured with a brief headline, explanatory paragraph, and bullet-like usage guidance. Each sentence adds value. Front-loaded with main purpose. Could be slightly more concise by removing redundant phrasing, but overall 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's complexity (cross-chain yield curve with normalization) and lack of output schema, the description sufficiently explains what the tool does and how it processes data. It omits output format details but provides enough context for an agent to understand the result type.
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 does not add much beyond schema for parameters; it provides context for 'underlying' and 'chain' in the usage paragraph. The schema descriptions are already clear. No additional semantic enrichment.
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 it shows the yield curve (term structure) for a given underlying asset across all chains. Specifies it fetches PTs, sorts by maturity, and displays implied APY. Distinguishes from siblings like spectra_get_pt_details and spectra_compare_yield.
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 describes when to use (fixed-income view, term premium analysis, maturity selection) and when not to (defers to spectra_get_pt_details, mv_check_ibt_health, spectra_get_pool_capacity, spectra_compare_yield for specific purposes). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly discloses data completeness (fully paginated, cached 15min memory + 30min disk), campaign types, and server-side filtering. This exceeds minimal expectations.
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?
Description is well-structured with sections, but somewhat lengthy (multiple paragraphs). It could be more concise, but every sentence adds value. 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?
Given no output schema and 4 parameters all described, the description is very complete: covers return data, caching, pagination, filtering, and campaign types. It fully equips the agent to use the tool 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?
Schema description coverage is 100%, so baseline is 3. Description adds value by explaining expected outputs and interpretation but does not add significant parameter details beyond the schema. It reiterates asset_filter behavior already in 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?
Description clearly states tool discovers live Merkl incentive campaigns, lists returned data (APR, reward tokens, daily rewards, TVL, campaign type), and provides examples. It distinguishes from sibling tools by focusing on Merkl-specific incentives, while siblings target other protocols like Morpho, Pendle, and Spectra.
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?
Description provides explicit use cases: verifying subsidized rates, finding opportunities, understanding yield stack. It suggests checking this tool when no subsidy is reported. However, it lacks explicit when-not-to-use guidance or alternative tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return fields (AUM, APY, fees, curator info, market allocations) and explains vault allocation dynamics (supply caps, uncapped allocations). Slightly lacks explicit statement that operation is read-only, but implied by 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?
Well-structured with a clear purpose statement first, followed by protocol context and usage notes. Slightly lengthy but all sentences add value.
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?
Completeness is high given no output schema: describes return fields, explains APY derivation, supply caps, and how vaults relate to PT markets. Also situates tool within broader protocol ecosystem.
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. Description does not add semantic detail beyond schema; it provides protocol context but not parameter-specific meaning.
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 'List Morpho vaults on a chain' with verb and resource, and explicitly distinguishes from sibling tools like morpho_get_market_suppliers and morpho_list_markets by referencing them.
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 guidance ('discover where supply-side liquidity lives') and when-not-to ('Not all vaults... allocate to PT markets'). Lists three specific alternatives: morpho_get_market_suppliers, morpho_list_markets, spectra_get_looping_strategy.
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 full burden. It mentions that 'protocol_pulse' fetches real-time data (5-15 seconds), but does not explicitly state that the tool is read-only or has no side effects. While the description implies a safe operation, it could be more explicit about behavioral traits like idempotency or potential rate limits.
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 with paragraphs and bullet points, front-loading the core purpose and then listing topics with usage advice. However, it is somewhat verbose and includes some redundancy (e.g., topics listed twice), which could be trimmed slightly without losing clarity.
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 lack of an output schema, the description does not explain the return format or data structure. However, it covers all necessary usage context and topic descriptions, making it adequate for an agent to use the tool correctly. A minor gap is the absence of output details, but the tool's nature (teaching mechanics) makes this less critical.
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 coverage is 100% with a single optional parameter 'topic' and an enum of 12 values. The description adds significant meaning by explaining each topic's purpose and context, far beyond the schema's enum list, making it easy for the agent to select the correct topic.
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: 'Get essential protocol mechanics for Spectra, Pendle, and Morpho — needed for correct reasoning.' It distinguishes itself from sibling tools by being a meta-context tool that explains how all protocols and their tools work, rather than performing protocol-specific actions.
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?
The description provides explicit guidance on when to use specific topics, such as recommending 'pendle_morpho' first for understanding multi-protocol scope, and 'workflow_routing' for learning which tools to call. It also explains when to omit the topic parameter to get all topics at once, leaving no 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?
With no annotations, the description carries full burden. It discloses the tool's cross-protocol nature, capital-aware computation, inclusion of price impact, maturity matching, Morpho looping, Merkl campaigns, and protocol tags. It also notes potential ranking disagreements. Could be more explicit about being read-only, but overall transparent.
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?
Well-structured with bullet points and clear comparisons. Front-loaded with purpose. Slightly long due to future-phase notes, but overall efficient and informative.
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?
Comprehensively covers the tool's role, differentiation, and usage context. Despite no output schema, it describes the output nature (ranked list, one-line compact option). All relevant aspects are addressed.
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 clear parameter descriptions. The tool description adds context about capital-aware behavior and compact output but does not add new parameter-level semantics beyond what the schema provides. Baseline 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 scans both Spectra and Pendle chains for best yield opportunities sized to capital. It explicitly contrasts with Spectra-only and Pendle-only siblings, and highlights cross-protocol matching, capital-aware impact, and unified ranking.
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 guidance: contrasts with spectra_scan_opportunities, spectra_get_best_fixed_yields, and pendle_list_markets. Also lists alternative tools for specific use cases (mv_compare_yield, spectra_model_metavault, spectra_get_curator_dashboard).
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 output includes timestamped buy/sell volume in USD and optionally a volume/liquidity ratio when pool data is available. Lacks details on data range, pagination, or caching, but for a read tool it is reasonably transparent.
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 at about 130 words, well-structured with the purpose first, then output, usage tips, context note, and alternatives. Every sentence adds value with 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 no output schema or annotations, the description effectively covers the tool's purpose, usage, and integration with other tools. It explains the return value and provides important context about using volume with liquidity. Minor gaps like missing time range or pagination, but overall very complete for a 2-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?
Input schema coverage is 100% with clear descriptions for both parameters. The description does not add significant meaning beyond what the schema provides, such as the chain enum or pool address pattern, so baseline 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 historical trading volume for a specific Spectra pool, returning timestamped buy/sell volume in USD. It differentiates from siblings by explicitly mentioning volume and directing users to other tools for transaction details or price impact.
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 guidance on using spectra_list_pools first to find pool addresses, suggests combining with liquidity data from other tools, and directs users to spectra_get_pool_activity for transaction details and spectra_quote_trade for price impact, covering when to use 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 present, so description carries full burden. It details returned metrics, definitions, conditional output, and configuration effects. However, it does not explicitly state read-only nature or rate limits, which would push to 5.
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?
Well-structured with purpose first, then details, then alternative tools. Slightly verbose but efficient for the level of detail needed. Front-loads key info.
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 output schema, but description thoroughly explains return values (metrics, definitions, conditional interpretations). Also provides context with sibling tools. Complete for a list 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?
Input schema has 100% coverage with parameter descriptions. The description adds metric definitions but does not significantly enhance per-parameter meaning beyond the schema. Baseline 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 'List all active Spectra pools on a given chain' with specific verb and resource, and distinguishes from sibling tools like spectra_get_best_fixed_yields and spectra_scan_opportunities.
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 provides when to use this tool vs alternatives, e.g., 'For multi-chain discovery, use spectra_get_best_fixed_yields...' and 'Use spectra_get_pool_activity on a specific pool...'.
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 explains the spread calculation, break-even assumptions, rate fluctuation risks, and execution mechanics. However, it does not explicitly state if the tool is read-only or requires authentication.
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 with clear sections but is somewhat lengthy. Every sentence adds value, though the execution mechanics section could be slightly trimmed without losing clarity.
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 no output schema, the description thoroughly explains return values: opportunities sorted by spread with capital-aware sizing, break-even analysis, IBT APR composition, and Merkl campaign APR. It also provides execution context and risk notes, making it 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 description coverage is 100%, so baseline is 3. The description provides high-level context for parameters but does not add detailed meaning beyond what the input schema already provides. It explains concepts like spread and capital-aware entry sizing, which indirectly inform parameter use.
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 scans all Spectra chains for YT arbitrage opportunities by comparing IBT APR vs YT implied rate. It distinguishes itself from siblings like spectra_compare_yield and spectra_get_pool_activity.
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?
The description explicitly mentions when to use this tool and provides alternatives: 'Use spectra_compare_yield for a detailed fixed-vs-variable breakdown on a specific pool. Use spectra_get_pool_activity to monitor recent trading patterns.' It also covers execution mechanics.
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. Describes output including signals (rate spikes, stability assessments), implying read-only behavior. Does not explicitly state side effects or permissions, but context suggests no destructive actions.
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?
Well-structured with clear sections: purpose, usage context, output signals, parameter details, sibling references. Slightly verbose but each sentence adds value. Could be more concise.
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 output includes signals and trends. Provides sufficient information for an agent to understand what the tool returns, though not exhaustive details.
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 parameter descriptions. Description adds extra context: period options with data frequency, interval override explanation, and default values. Adds 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?
Clearly states it provides historical rates and growth for a specific Morpho market, listing specific metrics (borrow APY, supply APY, utilization, TVL trends). Distinguished from siblings like morpho_get_rate and morpho_list_markets.
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 states when to use ('assessing rate stability before entering a looping position') and when not ('use morpho_get_rate for current live rates'). Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: scans all chains, ranks by implied APY, focuses on PT buyer perspective, and notes it's a quick raw-APY ranking without price impact analysis. This is complete and transparent.
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 and well-structured, with a clear purpose statement, comparisons to siblings, and a list of chains. Every sentence adds value without unnecessary verbosity.
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?
While the description explains the tool's purpose and usage, it does not describe the output format or fields returned. Given no output schema, this is a gap that could be filled to improve completeness.
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?
Input schema has 100% coverage with descriptions for each parameter. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the best fixed-rate opportunities across all Pendle chains, using specific verbs and resources. It distinguishes itself from sibling tools like pendle_list_markets (single chain) and pendle_scan_opportunities (capital-aware).
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 mentions when to use this tool (initial screening) and when not to (for capital-aware analysis, use pendle_scan_opportunities). Provides alternative tools for deeper analysis.
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?
Since no annotations are provided, the description carries the full burden. It explains the tool is for historical data, lists available fields, and provides interpretation guidance. It does not explicitly state it is a read-only operation, but the context implies it.
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 informative but not overly verbose. It uses bullet-like listing for fields and provides context on interpretation. Could be slightly more structured with separate sections, but it is 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, the description explains the return data (time-series of metrics), provides interpretation guidance, and mentions the default period. It is complete enough for an agent to understand what the tool does and how to use it.
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 baseline is 3. The description adds value by listing all available fields in text, explaining the default period, and clarifying that 'all' can be used for the fields parameter. This goes beyond just repeating schema 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 it returns 'historical time-series data for a Pendle market' with specific metrics. It distinguishes itself from sibling tools like pendle_get_market_details (current snapshot) and pendle_list_markets (find addresses).
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 tells when to use this tool ('trend analysis, yield stability assessment') and provides alternatives ('Use pendle_get_market_details for current market snapshot. Use pendle_list_markets to find market addresses.').
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 details the output: PT, YT, LP balances, USD valuations, maturity dates, APY, strategy inference, expiry warnings. However, it does not explicitly state that it is read-only, though 'View' implies no side effects.
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 with two main sentences, a bullet-like list of output fields, and three usage guidelines. It is front-loaded and every sentence provides value.
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 (2 params, no output schema), the description adequately explains the output details and usage context. It covers balance types, valuations, dates, APY, and provides references to related tools.
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. Description adds minimal parameter meaning beyond schema, only repeating 'all chains or specific chain' which is already in the chain parameter description.
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 'View a wallet's Pendle positions' and specifies it can be across all chains or a specific chain. It distinguishes from siblings like spectra_get_portfolio and other Pendle tools, providing a specific verb-resource pair.
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 provides alternatives: 'Use pendle_get_market_details to drill into a specific market. Use mv_plan_rollover to plan rollovers. Use spectra_get_portfolio for Spectra positions.' It also states it is the Pendle equivalent of spectra_get_portfolio, guiding selection.
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 adds useful behavioral context: the output surfaces competing interpretations when data is ambiguous (e.g., positive raw spread but negative effective spread), and explains protocol context for rates (implied APY, IBT APR, LP APY) and entry cost amortization. It does not explicitly state read-only but implies it.
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 in three paragraphs (purpose, protocol context, alternative tools). While it is slightly long, every sentence adds value and avoids redundancy. It is front-loaded with the core purpose.
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 (4 parameters, no output schema, protocol-specific) the description covers key aspects: rates, entry costs, LP alternative, ambiguous outputs. It does not explain return format, which is acceptable without output schema. Overall, it provides sufficient context for an agent to use the tool appropriately.
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 description coverage is 100%, but the description adds value beyond schema: it explains the formula for real boost using ve_spectra_balance (B = min(2.5, 1.5*(v/V)*(D/d)+1)), and the default for capital_usd and its interaction with ve_spectra_balance. This provides deeper context for the 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 it compares fixed yield vs variable yield, helping users decide if locking in a fixed rate is worthwhile. It distinguishes from sibling tools by explicitly naming alternative tools like spectra_get_looping_strategy, spectra_get_portfolio, and spectra_scan_opportunities.
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?
The description gives explicit guidance on when to use this tool (deciding fixed vs variable) and when to use alternatives (e.g., spectra_get_looping_strategy for leveraging, spectra_get_portfolio for current positions, spectra_scan_opportunities for multi-chain comparison). It also notes that the output may be ambiguous in certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description compensates fully by detailing coverage blind spots, invisible event types, and warning that results are incomplete for position sizing. Thoroughly discloses limitations.
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?
Well-structured and front-loaded: core function, use cases, comparisons, limitations. Concise but not overly terse; each sentence earns its place. Slight room for tightening.
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 structure (per-pool breakdown, cross-pool totals, observation coverage). Addresses completeness concerns bluntly. Sufficient for an aggregation 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 parameters already have descriptions. Description adds minimal extra detail beyond schema (e.g., no elaboration on min_volume_usd beyond default). Meets baseline but no significant added value.
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 scans all pools on a chain for an address's activity, returning per-pool breakdown and cross-pool aggregates. Distinguishes from siblings like spectra_get_pool_activity and spectra_get_portfolio by specifying use cases.
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 recommends use for multi-pool strategy discovery and warns against using for deep per-pool analysis or current holdings, providing alternative tool names. Offers clear context and exclusions.
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 on-chain reading from Base chain, auto-population logic, and the boost formula. Lacks explicit mention of read-only nature and absence of side effects.
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?
Concise and well-structured: one-line summary, explanation of data source, formula, and usage note. 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?
With no output schema, description compensates by stating output is an exact boost multiplier. Could elaborate on other return fields (e.g., total supply) but sufficient for agent decision-making.
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?
All 5 parameters have schema descriptions, but the description adds significant value by explaining the formula, auto-population when wallet_address is given, and the requirement of capital_usd with ve_spectra_balance.
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 gets live veSPECTRA info and computes boost scenarios using a specific formula. It distinguishes itself from sibling tools by focusing on governance token boost calculation.
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?
Clearly states usefulness for understanding veSPECTRA needed for max boost. Does not explicitly state when not to use, but context is clear among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It details the double-loop mechanism, dual Morpho market strategy, curator economics, and blended allocation, providing full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and detailed, covering conceptual explanations (double loop, dual market) that, while valuable, could be truncated or moved to external documentation. Every sentence earns its place, but overall verbosity reduces 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?
Given 14 parameters and no output schema, the description adequately explains inputs and modeling purpose. However, it lacks explicit mention of output format or example results, which would complete the picture.
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 coverage is 100% (baseline 3), but the description adds substantial meaning beyond schema: explains live vs manual mode for chain/metavault_address, curator fee semantics (earned vs cost), and dependencies like pendle_allocation_pct requiring pendle_lp_apy.
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 models a MetaVault 'double loop' strategy, specifying verb (model), resource (MetaVault strategy), and scope (economics, leverage loops). It distinguishes from sibling tools by focusing on the unique double-loop concept.
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?
Describes two explicit usage modes (live and manual) and provides context for when to use each. However, it lacks explicit exclusions or comparisons to sibling tools like mv_compare_yield or spectra_compare_yield.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the process (fetches position and pool data, computes quote, shows before/trade/after with deltas) and edge case (works even without existing position). Clearly explains side semantics and limitations (YT not supported).
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 the main purpose, followed by stepwise explanation, edge case, side semantics, YT clarification, and sibling references. Slightly verbose but all sentences add 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?
Covers inputs, process, edge cases, and output format (BEFORE / TRADE / AFTER with deltas). No output schema, but description suffices. References sibling tools for further context.
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 well-described parameters. The description adds context about the overall flow but does not significantly enhance parameter understanding 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 verb ('Preview'), resource ('Spectra portfolio'), and scope ('after a PT trade'). It distinguishes from sibling tools like spectra_quote_trade and spectra_get_portfolio by explaining their different purposes.
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 states when to use (PT trades only, not YT) and when not to (YT acquisition via minting, YT sale via Router). Also references alternative tools: spectra_get_portfolio for current positions, spectra_quote_trade for standalone quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations (none provided). It explains the underlying query (marketPositions), cross-referencing with vault registry, and the inference logic for loopers with appropriate caveats ('inference from position shape, not confirmed'). It also discusses supply concentration implications and the effect of reward incentives, providing full transparency.
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 with a clear front-loaded purpose, followed by protocol context sections. It is informative without being overly verbose, though it could be slightly shortened. Each sentence adds value, making it efficient for an AI agent.
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 complexity of the Morpho protocol and lack of output schema, the description is complete. It covers the return content, operational details, limitations, and contextual signals (concentration, loopers, incentives). An agent can fully understand what the tool does and how to interpret results.
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 baseline is 3. The description adds some context (e.g., market_key pattern explanation, top_n default and max) and reinforces the chain enum, but does not significantly extend beyond the schema. The mention of 'Use morpho_list_markets to find it' adds value but not enough to raise the 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?
The description clearly states the tool's purpose: 'Show who supplies lending liquidity to a specific Morpho market.' It specifies the output (top suppliers ranked by supply size, identification of vaults vs EOAs vs loopers, concentration analysis) and distinguishes from sibling tools by mentioning related tools for other aspects (e.g., morpho_list_markets for finding markets).
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?
The description provides explicit usage guidance: 'Use morpho_list_markets to find market keys first.' It also notes alternatives for borrow-side analysis ('Use morpho_get_rate for borrow-side rate') and vault discovery ('Use morpho_list_vaults to discover all vaults'). This gives clear when-to-use and when-not-to-use context.
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?
Without annotations, the description effectively discloses that rates are live, dynamic, and can change unpredictably. It explains the return values (borrow APY, supply APY, utilization, liquidity) and implies a read-only operation. However, it does not cover error handling or requirements like authentication, slightly reducing transparency.
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 structured into three concise paragraphs, each serving a purpose: main action, behavior note, and integration advice. It is front-loaded with the core functionality, and no superfluous sentences are present. Slightly longer than minimal but justified.
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 no output schema, the description fully explains the return data (borrow APY, supply APY, utilization, liquidity) and its purpose in looping strategies. It also provides pre-requisites (morpho_list_markets) and post-steps (spectra_get_looping_strategy), making it self-contained for the intended use case.
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 baseline is 3. The description adds value by explaining the market_key is a hex ID to be obtained from morpho_list_markets and by describing the output fields, which are not in the schema. This goes beyond simple repetition.
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 the borrow rate and market state for a specific Morpho market, distinguishing it from sibling tools like morpho_list_markets and morpho_get_positions. It also explicitly guides users on prerequisites and related tools.
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?
The description provides explicit when-to-use guidance: for retrieving rates for looping profitability. It instructs users to first use morpho_list_markets to discover market keys, warns about rate volatility, and directs to spectra_get_looping_strategy for projections, offering clear alternatives and context.
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 explains automation of steps 1-3, scanning sources, ranking by effective APY, and details the behavior of the verify_onchain parameter. Lacks disclosure of potential failure modes or data freshness, but overall transparent.
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?
Front-loaded main purpose, well-structured with bullet points for steps, clear return description, and usage guidance. Every sentence adds value, no fluff.
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 (ranked list with entry impact, yield gap, etc.). Addresses 8 parameters adequately. Slight gap on error handling or edge cases, but sufficient for task understanding.
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 has 100% coverage with descriptions. Description adds meaning beyond schema: explains pt_address omission defaults, max_maturity_days behavior, and provides extensive detail for verify_onchain. Additional context for parameter interactions.
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 plans rollovers for expiring MetaVault positions, using a specific verb 'plan' and resource 'rollover'. It distinguishes from siblings like spectra_get_curator_dashboard and mv_scan_curator_opportunities.
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 provides when-to-use and when-not-to-use guidance, listing three sibling tools with specific use cases: spectra_get_curator_dashboard for seeing approaching maturity, mv_scan_curator_opportunities for broader discovery, and spectra_get_pool_capacity for depth assessment.
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 discloses key behaviors: auto-fetches live Morpho borrow rate and LLTV, calculates projected yields at different leverage levels, and explains the looping strategy. It does not explicitly state read-only nature or rate limits, but no annotations are provided so the description carries the burden.
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 with a clear summary, strategy explanation, outputs, note, and alternative tool references. It is slightly verbose but every sentence contributes value, earning a 4.
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?
Despite no output schema, the description explicitly lists return values (projected yields, effective APY, risk parameters, etc.). It covers prerequisites, auto-fetching, and alternative tools, making it complete for a tool with 5 parameters and 2 required.
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 all parameters. The description adds meaning beyond schema by explaining that morpho_ltv and borrow_rate are overrides with auto-detection, and max_loops defaults to 5. This adds useful context.
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 calculates a leveraged fixed-yield strategy using Pendle PT + Morpho looping, explains the strategy, and explicitly distinguishes from sibling tools like pendle_get_market_details and pendle_scan_opportunities.
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?
The description provides explicit when-to-use and when-not-to-use guidance, including alternative tools (pendle_get_market_details, pendle_scan_opportunities, morpho_list_markets) and prerequisites (requires Morpho market accepting PT).
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 full burden. It explains the tool fetches and aggregates data across chains, filters by TVL/liquidity, and has a compact mode. However, it does not explicitly state that it is a read-only operation, though 'Show' implies no mutation. Missing explicit safety 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?
The description is well-structured: first line summarizes, then details, use cases, and sibling differentiation. It is front-loaded and every sentence adds value without unnecessary verbosity.
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 explains the output (implied APY at each maturity) but does not specify the exact format (e.g., list of objects). It covers parameter semantics and usage well. A bit more detail on return structure would increase 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?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds context beyond schema: explains underlying with examples, chain behavior when omitted, and compact mode output. It also mentions sorting by maturity and displaying implied APY, which is not in 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 shows the yield curve for a given underlying asset across Pendle chains, specifying it fetches active markets, sorts by maturity, and displays implied APY. It distinguishes from siblings like pendle_get_market_details and pendle_get_market_capacity.
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?
The description explicitly provides when to use the tool (fixed-income view, spot anomalies) and when to use alternatives (drill into maturity, check capacity, compare to Spectra). It also mentions the Pendle equivalent of spectra_get_yield_curve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: it computes entry price impact using Pendle's logit AMM model, effective APY, pool capacity, Morpho looping availability, and Merkl incentives. It clearly states what the tool does and how it differs from a simple APY ranking.
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: a brief introductory sentence, a bullet list of computed metrics, and two sentences for alternative tools. No fluff, front-loaded, and well-structured.
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?
Although no output schema is provided, the description lists the key computed values (entry price impact, effective APY, pool capacity, etc.) giving a good sense of the output. It provides sufficient context for an agent to understand what the tool returns, though not fully detailed. Slight deduction for missing explicit output structure.
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 individual parameter descriptions. The tool description only implicitly references capital_usd ('sized to your capital') and provides context for why parameters matter (e.g., price impact), but does not explain each parameter in detail. Baseline 3 is appropriate as schema already does the heavy lifting.
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 scans all Pendle chains for yield opportunities sized to capital, distinguishes it from raw APY ranking (pendle_get_best_fixed_yields) by listing specific computed metrics, and positions it as the Pendle equivalent of spectra_scan_opportunities. It effectively differentiates from sibling tools.
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?
Explicit guidance on when to use this tool versus alternatives: mentions spectra_scan_opportunities for Spectra-only, mv_scan_curator_opportunities for cross-protocol, and contrasts with pendle_get_best_fixed_yields. This makes selection straightforward.
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 clearly states the tool is 'purely informational' and does not execute any transaction, which is the key behavioral trait. However, it does not mention any potential side effects, authorization requirements, or error conditions. Given no annotations, it carries the full burden but covers the essential non-execution nature.
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 succinct and well-structured: a main sentence, bullet points of outputs, a clear negative statement, a sibling equivalence, and usage pointers. No redundant information; 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?
Given the 5 required parameters, no output schema, and the domain complexity, the description provides a good overview of the tool's functionality and outputs. It explains what the simulation returns but could benefit from more detail on the return format. Still, it is largely complete for agent decision-making.
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 enhances semantic understanding for the 'amount' parameter (context-dependent: underlying/SY for buy, PT for sell) and the 'side' parameter (buys vs sells PT). This adds value 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 specifies the tool simulates a Pendle PT trade and its effect on a wallet's portfolio. It lists specific outputs (before/after comparison, positions, APY, concentration) and distinguishes from the sibling pendle_quote_trade and pendle_get_portfolio. The mention of being the Pendle equivalent of spectra_simulate_trade further clarifies its role.
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?
The description explicitly states when to use (simulate trade impact) and what not to do (does not execute any transaction). It provides clear alternatives: use pendle_quote_trade for a detailed quote and pendle_get_portfolio for the full portfolio. This gives unambiguous guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It exhaustively discloses behaviors: estimated yield, cross-chain handling, default values, and the verify_externals parameter's performance cost and degradation behavior. Caveats like 'actual yield may differ' ensure realistic expectations.
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 lengthy but well-structured with clear sections (Returns: with sub-bullets, important notes on cross-chain positions and epoch flows). Every sentence provides value, and key information is front-loaded (purpose, target user, required params). 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?
Given the tool's complexity and lack of output schema, the description covers all aspects: return fields (vault health, position status, external positions, capital decomposition, depositor flows, fee revenue, action items), edge cases (flagging maturities, unknown protocols, missing LP balance, cross-chain positions), and limitations (estimated yield, verify_externals performance impact).
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 coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining the purpose of curator_fee_pct (for fee estimation) and verify_externals (verification details and when to use). It also clarifies chain and metavault_address usage.
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 defines the tool as an operational dashboard for MetaVault curators, listing aggregated data like vault health, position status, depositor flows, etc. It distinguishes itself from sibling tools like spectra_list_metavaults and spectra_model_metavault by targeting a quick operational overview.
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 specifies the target user (curators managing live MetaVaults) and provides explicit pointers to alternative tools for related tasks (e.g., spectra_list_metavaults for addresses, spectra_model_metavault for leverage modeling, spectra_get_pool_activity for trading patterns). It lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains return data concepts (voting APR formula, bribe efficiency, Merkl campaign statuses with emojis), stale detection logic, and what the tool does not do (e.g., personal boost). It lacks explicit mention of read-only nature, but overall behavior is clearly disclosed.
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?
Well-structured with bullet points and emojis. Front-loaded with main purpose. Every sentence adds value, though slightly verbose; could be trimmed slightly without loss of clarity.
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 complexity and no output schema, the description is very complete: explains metrics, formulas, indicators, edge cases (stale detection), and interpretations. Covers all major aspects expected from a governance dashboard 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?
Input schema has 100% description coverage. The description adds value by explaining the meaning of sort options (votes, voting_apr, emissions, bribes) and clarifying that min_votes is in SPECTRA, not wei, which goes 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 identifies the tool as a 'Full veSPECTRA governance dashboard' covering gauge vote distribution, voting APRs, bribes, emissions, and Merkl campaign health. It distinguishes from siblings by listing related tools like spectra_get_ve_info, spectra_list_pools, and spectra_list_expiring_pools.
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?
Explicit guidance on when to use: deciding where to direct votes, finding pools with bribe markets, understanding emission concentration, evaluating bribe efficiency, and detecting broken emission pipelines. Sibling tools are recommended for related tasks, providing clear decision context.
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 full burden for behavioral traits. It discloses that Merkl rewards are best-effort and may fail, and explains fundamental protocol mechanics (PT+YT=1, IB depositing mints both). However, it does not mention potential rate limits, performance considerations, or data freshness, which would elevate it to a 5. Nonetheless, the transparency about data sources and limitations is strong.
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 longer than ideal but well-structured: core purpose first, then Merkl rewards caveat, then protocol context and cross-referencing. It is front-loaded with the most important information. Could be slightly more concise (e.g., condensing protocol context), but it is clear and organized, earning a 4.
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 lack of output schema, the description comprehensively explains return fields (PT, YT, LP, USD, yield, rates, Merkl rewards). It also provides protocol context to interpret balances (e.g., position shape). With many sibling tools, it offers cross-referencing guidance. This fully equips an agent to use the tool correctly and interpret results, achieving maximum 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that omitting the 'chain' parameter scans all chains, which is a critical usage hint beyond the schema's enum list. This incrementally improves clarity, justifying a 4.
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 that the tool retrieves wallet positions on Spectra, including PT, YT, LP balances, USD values, claimable yield, current rates, and Merkl rewards. It explicitly distinguishes from sibling tools like spectra_get_pool_activity, stating that this tool shows 'what' the holder's position is, while the other shows 'how' (transaction patterns). This level of specificity and differentiation earns a top score.
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?
The description provides explicit when-to-use guidance, including cross-referencing with spectra_get_pool_activity and spectra_get_address_activity. It also advises checking multiple wallets if activity is concentrated. This directly helps an agent select the appropriate tool and avoid misuse, meeting the highest standard.
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 full burden. It describes the tool as getting stats (read-only) and includes extensive protocol context (rebase formula, emissions decay). It does not mention any side effects or restrictions, but the read-only nature is clearly implied. Could be slightly improved by explicitly stating no side effects, but overall transparent enough.
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 purpose, followed by useful protocol context and a pointer to an alternative. It is not overly long, though the protocol context adds some verbosity. Every sentence serves a purpose; no waste.
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 zero-parameter tool with no output schema, the description provides comprehensive context: detailed rebase formula explanation, emissions decay behavior, gauge emissions boost reference, and a link to a related tool. It fully covers what the agent needs to know to invoke 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?
The input schema has 0 parameters, and schema coverage is 100% (vacuously). The rule sets baseline 4 for zero-parameter tools. The description adds value by explaining the output content beyond the empty 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 gets Spectra protocol-wide statistics, listing specific data points (SPECTRA token supply, circulating supply, current weekly emissions, rebase formula). It also distinguishes from sibling tools like spectra_get_ve_info by recommending that for live veSPECTRA data.
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 for questions about SPECTRA tokenomics or protocol health' and provides an alternative: 'Use spectra_get_ve_info for live veSPECTRA data and boost calculations.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details that the output surfaces conditional warnings (e.g., PT above par, skewed reserves, incentive-dominated APR) and explains protocol mechanics (PT discount, PT+YT=1, YT leverage). This goes beyond a simple listing of fields.
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 with a clear overview, bullet-point fields, protocol context, and usage guidelines. It is slightly long but every sentence provides value; could be tighter but still effective.
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 complexity (many return fields, no output schema, conditional behavior), the description is remarkably complete. It explains the protocol, return values, edge-case warnings, and sibling alternatives. No gaps are evident.
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 clear descriptions for both parameters (chain enum and pt_address pattern). The description does not add new semantic details about the parameters beyond what the schema provides, but it does contextualize the parameters within the broader protocol explanation. Baseline 3 is appropriate as schema already does most of the work.
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: 'Get detailed information about a specific Spectra Principal Token (PT).' It lists specific return fields, and distinguishes from sibling tools by naming alternatives for different use cases, such as compare fixed vs variable rates or check wallet holdings.
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?
Explicit when-to-use and when-not-to-use guidance: it directs to spectra_compare_yield, spectra_get_looping_strategy, spectra_get_portfolio, and spectra_get_pool_activity for related but different tasks. This fully helps the agent choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: what checks are performed, verdict types (HEALTHY/CAUTION/WARNING), limitations (rate trajectory, governance, transient imbalance), and mode-specific behaviors. It surfaces competing explanations for pool imbalances.
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 with clear sections (purpose, checks, verdict, limitations, modes). It is concise for the amount of information provided, though slightly lengthy. 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 no output schema, the description adequately describes return value (verdict + per-check details) and limitations. It covers modes, alternatives, and edge cases (e.g., which address takes priority). Could mention error handling but not required.
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 baseline is 3. The description adds significant value by explaining the two modes, fallback behavior, and that pt_address provides richer data. It clarifies the relationship between parameters and their usage context.
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 performs a multi-signal health assessment of the IBT underlying a PT pool, with specific checks and verdicts. It distinguishes from sibling tools by mentioning alternative tools (spectra_get_pool_capacity, spectra_compare_yield).
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?
The description explicitly explains two modes (Spectra vs Direct), when to use each, and priority rules. It also references alternatives for related tasks, providing clear guidance on when to use this tool versus others.
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 the return structure (normal range, current status, anomaly threshold, peer comparison, assertion hints) and the auto-detection logic for target_type. However, it does not explicitly state whether the tool is read-only or describe potential side effects, though read-only is implied. This is a minor gap, but overall transparent.
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 well-structured, starting with a clear purpose, then explaining return values, supported protocols, and usage guidance. Every sentence is informative, and it avoids redundancy. The length is appropriate for the tool's complexity, and it front-loads the most important 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?
Given the tool has no output schema, the description comprehensively explains the return structure. It covers all five parameters, includes auto-detection logic, lists supported protocols, and distinguishes from sibling tools. For a tool with this complexity, the description is complete and anticipates user needs.
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 baseline is 3. The description adds value by explaining the auto-detection of target_type from address format and describing the return structure, which helps in understanding how parameters map to results. This goes beyond the schema's enum descriptions and justifies a 4.
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 as a 'calibration oracle' that produces statistical baselines from historical data. It specifies what it does (returns percentiles, anomaly thresholds, peer comparison, assertion hints) and distinguishes it from siblings like morpho_get_history and mv_check_ibt_health.
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?
The description explicitly tells when to use the tool ('when you need to CALIBRATE — set thresholds, compare to peers, or export knowledge') and when not to use it (for raw time-series use morpho_get_history/pendle_get_market_history, for single-point health snapshots use mv_check_ibt_health). This provides clear guidance on 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, but the description is transparent about the output: it includes per-chain breakdown, aggregate metrics, and mentions chain overlap with Spectra. It doesn't explicitly state read-only behavior but implies a query 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?
The description is well-structured with bullet points, clear sections, and 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.
Completeness5/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 thoroughly explains the return values (per-chain breakdown, aggregate metrics, etc.). It is complete for a tool with zero parameters.
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?
There are no parameters, so schema coverage is trivially 100%. With 0 parameters, baseline is 4. The description adds value by explaining the output contents 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 gets Pendle protocol-wide statistics, listing specific metrics like total TVL, market count, liquidity, and volume. It differentiates from siblings by mentioning the equivalent tool in Spectra and directing users to pendle_list_markets for detailed market-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (for protocol overview) and what to use instead for detailed market-level data (pendle_list_markets) and cross-protocol ranking (mv_scan_curator_opportunities). This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully shoulders behavioral disclosure. It explains the tool is a read-only listing (no mutations), notes that Merkl campaigns are 'fetched best-effort per chain', and describes the nature of Pendle markets (AMM with time-decay pricing, incentive tokens). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured: starts with core purpose, then adds context (Pendle vs Spectra), return fields, chain lists, Merkl info, and sibling tool references. It is front-loaded with essential information. Some redundancy could be trimmed, but overall efficient for the complexity.
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 7 parameters and no output schema, the description is comprehensive: explains return fields, chain lists, Merkl APR, and cross-protocol use cases. It does not detail output format (e.g., JSON structure), but parameter descriptions and return list are sufficient for an agent to understand the output.
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 detailed parameter descriptions. The description adds meaningful context beyond schema, such as the full list of supported chains (including which overlap with Spectra) and the meaning of 'asset_filter' (matches against market name). While baseline is 3, the extra contextualization merits a 4.
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 'List active Pendle markets on a given chain, or scan all Pendle-supported chains.' and lists specific return fields (market name, implied APY, etc.). It distinguishes from sibling tools by explaining Pendle's role relative to Spectra and directing to other tools for specific use cases.
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?
Explicit guidance on when to use this tool vs alternatives: 'Use mv_compare_yield to do a head-to-head comparison...', 'Use mv_scan_curator_opportunities for unified cross-protocol ranking...', and 'Use spectra_scan_opportunities for Spectra-native opportunity ranking.' Also explains the tool's role in building MetaVaults.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 of behavioral transparency. It thoroughly explains the tool's behavior, including that it returns only the Curve pool's perspective (IBT â†” PT swaps and LP events), details about event types (no BUY_YT/SELL_YT), and complex protocol mechanics like flash-minting and flash-redeeming. It also describes output features like Address Concentration, Sequence Analysis, Flow Accounting, and coverage metrics, giving a complete picture of what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long (multiple paragraphs) and includes extensive detail and examples. While well-structured with headings, it is not concise. For a complex tool, the length is justified, but conciseness is sacrificed. A 3 indicates it is adequate but could be trimmed without losing 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?
Given the tool's complexity (5 parameters, no output schema), the description is extremely complete. It covers edge cases (e.g., PT address resolution, high SELL_PT count interpretations), interacts with other tools (spectra_get_portfolio, spectra_compare_yield), and provides analysis tips. All necessary context for an AI agent to use the tool correctly is present.
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 description coverage is 100%, so the baseline is 3. The description adds significant meaning beyond the schema, especially for the 'address' parameter (explaining it enables chronological sort, sequence analysis, capital efficiency hints, and contract detection). It also clarifies the 'type_filter' parameter by listing event types and explaining that some events like AMM_ADD_LIQUIDITY may represent YT acquisition. While it adds a lot, the schema already describes the parameters adequately, so a 4 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 'Get recent trade and liquidity activity for a specific Spectra pool' with specific verb and resource. It distinguishes from siblings like spectra_get_address_activity and spectra_get_portfolio by explaining what it returns (individual transactions) and what it does not (full mechanics of Router batching, which is covered by mv_get_protocol_context).
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?
The description provides explicit guidance on when to use this tool, including analysis tips that emphasize cross-referencing with spectra_get_portfolio for holdings. It also highlights when not to rely solely on this tool (e.g., 'Do not assume SELL_PT means...') and suggests alternative tools like mv_get_protocol_context for Router mechanics and spectra_get_address_activity for multi-pool scanning. This is comprehensive and helps an agent select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: independent tier quoting (non-cumulative), on-chain vs. math-only estimation, and the different impact profiles of pt_buy and lp_add modes. It also notes real execution would face additional pool state changes, setting accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but verbose (multiple paragraphs). It uses lists and clear sections, but contains some redundancy (e.g., the note about MetaVault curators appears twice). Could be trimmed for brevity without losing 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?
Given the tool's complexity (6 parameters, two modes, no output schema), the description covers all essential aspects: mode differences, tier quoting mechanics, on-chain vs. off-chain options, and links to related tools. It provides sufficient information for an agent to decide when and how to use this 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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the purpose of steps and max_capital, clarifying the use_on_chain trade-off, and providing context-specific guidance for the mode parameter (e.g., 'Use this mode for MetaVault curator capacity analysis').
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 analyzes pool capacity by quoting PT trades at increasing capital sizes, detailing two distinct modes (pt_buy and lp_add). It explicitly distinguishes the purpose for directional traders vs. LP deployers (MetaVault curators), making it easy to understand what the tool does.
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?
The description provides explicit when-to-use guidance for each mode and recommends lp_add for MetaVault curator capacity analysis. It also lists three alternative tools (spectra_quote_trade, spectra_scan_opportunities, mv_check_ibt_health) with specific contexts, enabling correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns specific position fields, explains health factor calculation, net value formula, and default multi-chain scan. Provides protocol context (looper detection, health warnings) that goes beyond a simple read 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?
Well-structured with front-loaded purpose and clear sections. Some redundancy (e.g., 'Useful for understanding' and later 'The position shape reveals the strategy'). Could be slightly more concise, but every sentence adds value.
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 no output schema, description sufficiently explains return structure (collateral, borrows, supply, vaults, health factors). Covers protocol context and cross-chain behavior. References sibling tools for deeper insights. Complete for a data query 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%; both parameters have descriptions. The description adds context: chain enum values are listed, default behavior (scan all chains) is clarified, and the address regex is implied. Adds value beyond schema by explaining the purpose of each parameter.
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 queries a user's Morpho positions across markets and vaults, listing returned data (collateral, borrows, supply, vault deposits, health factors, signals). Distinguishes from siblings like morpho_list_markets, morpho_get_rate, and spectra_get_portfolio.
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 explains when to use this tool (understanding wallet holdings) and cross-references siblings. Provides protocol context including health factor formula and chain scanning behavior. Tells agent to specify chain to narrow scope, and points to morpho_list_markets for PT markets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior. It details what comparisons are shown (implied APY, LP APY, liquidity, TVL, variable rate, winner analysis, maturity match quality) and explains maturity categories and Merkl campaign inclusion.
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?
Well-structured with bullet points and front-loaded main purpose. Some redundancy (chain list repeated in description and schema) but overall efficient. Could be slightly tighter but still good.
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 no output schema, no annotations, and complexity as a comparison tool, description is thorough. Covers when to use, outputs, matching logic, chains, and alternative tools. Complete for agent decision-making.
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 description adds value by explaining maturity tolerance categories (exact ≤7d, close ≤30d, loose ≤90d) and providing examples for asset_filter. This goes beyond schema definitions.
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 compares Pendle and Spectra yield opportunities side-by-side. It uses a specific verb ('compare') and resource ('yield opportunities'), and distinguishes from siblings by mentioning alternative tools like pendle_list_markets and mv_scan_curator_opportunities.
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 when to use ('Essential for MetaVault curators') and lists three alternative tools with specific use cases. Also specifies chain requirements clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the looping mechanism step-by-step, that it fetches live data but allows overrides, and provides detailed risk context about variable borrow rates, liquidation risk, and entry cost. Discloses key behavioral traits such as auto-detection of LTV and borrow rate.
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?
Well-structured with a summary sentence upfront, then bullet-rich paragraphs. Slightly lengthy but each sentence adds essential context (e.g., risk notes, prerequisites). Could be trimmed slightly without losing value, but still efficient.
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 complexity (5 params, no output schema), description covers prerequisites, risks, return values (projected yields, effective APY, risk parameters), and links to related tools. All necessary context for an agent to understand and correctly invoke the tool is present.
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 description adds value beyond schema: clarifies that morpho_ltv and borrow_rate can be auto-detected or manually overridden, and that max_loops defaults to 5. This reduces ambiguity and aids correct usage.
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 calculates a leveraged fixed-yield strategy using Spectra PT and Morpho looping. It uses specific verbs ('calculate', 'returns projected yields') and distinguishes from sibling tools like pendle_get_looping_strategy (different protocol) and morpho_list_markets (different purpose).
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 mentions when to use: 'Automatically fetches the live Morpho borrow rate' and constraints: 'requires a Morpho market that accepts the specific PT as collateral'. Provides alternatives: 'Use morpho_list_markets to find available Morpho markets. Use spectra_scan_opportunities to discover the best looping opportunities...'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses behavioral traits: gauge status is fetched 'best-effort' and 'does not block results'; urgency and readiness are independent dimensions; default shows active pools only; output includes operator checklist. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear sections (urgency levels, readiness assessment, operator checklist). Every sentence adds value, though it could be slightly more concise. Structure is front-loaded with purpose and use cases.
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 complex tool scanning multiple chains with cross-referencing and multiple output dimensions, the description is complete. It covers parameters, edge cases (best-effort gauge), output format, and relationships between urgency and readiness. No output schema, but description explains results adequately.
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 baseline 3. The description adds meaning beyond parameter descriptions by explaining the output fields, urgency levels, readiness assessment, and the implication of thresholds. It does not repeat schema but enriches context.
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 starts with a clear verb+resource: 'Scan all Spectra chains for pools approaching maturity.' It specifies the resource (pools) and action (scan for expiring). It distinguishes itself from siblings by listing alternative tools like mv_plan_rollover, spectra_get_yield_curve, and spectra_list_pools.
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 states when to use this tool versus alternatives: 'Use mv_plan_rollover on a specific MetaVault for automated rollover candidate discovery. Use spectra_get_yield_curve to see what maturities already exist for the same underlying. Use spectra_list_pools to check if a successor pool has already been created.' It also provides context for operators and specifies default parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden, detailing entry price impact, effective APY, Morpho looping, pool capacity, risk warnings, ranking logic, and caveats about conservative modeling and ambiguous rankings.
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 dense but well-structured, starting with a summary and using bullet points and notes. While every part adds value, it is lengthy and could be slightly more compact.
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?
Without an output schema, the description explains that results are ranked by effective APY and MetaVaults are in a separate section. It mentions conditional interpretations but could be more explicit about the output structure.
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 coverage is 100%, but the description adds substantial context beyond the schema, such as how capital_usd affects sizing, the formula for ve_spectra_balance, and how max_price_impact interacts with pool capacity.
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 scans Spectra chains for best risk-adjusted yield opportunities sized to capital, and distinguishes itself from spectra_get_best_fixed_yields which ranks by raw APY.
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 specifies when to use (capital-sized scanning) and when not (raw APY ranking), and provides alternative tools like mv_scan_curator_opportunities and spectra_get_looping_strategy for deeper analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It exhaustively explains the liquidity waterfall tiers, what is included/excluded (e.g., Tier 1b nuances), the ERC-7540 constraint (no cancelRequest), and the detailed behavior of the verify_onchain parameter, including failure modes and caching. No contradictions are present.
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 lengthy but well-structured with bullet points and clear sections. It front-loads the purpose and uses concise language. Every sentence adds value, though some redundancy (e.g., repeating the tier descriptions) could be trimmed. Overall, it is appropriately detailed without being rambling.
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 complexity (simulation with multiple parameters, no output schema), the description is remarkably complete. It explains what the tool computes (total coverage, cost, max safe redemption), describes the liquidity waterfall in detail, and provides usage guidance. No gaps are apparent.
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 description coverage is 100%, so baseline is 3. The tool description adds significant context beyond the schema for the verify_onchain parameter, explaining its effect, caching, and behavior on failure. For other parameters, the schema descriptions are sufficient, but the overall description provides a richer understanding of how parameters interact in the simulation.
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: 'Simulate a large redemption on a MetaVault to assess withdrawal liquidity.' It uses a specific verb ('simulate') and resource ('large redemption on MetaVault'), and differentiates from sibling tools by mentioning related tools like spectra_get_curator_dashboard and spectra_get_pool_capacity.
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?
The description provides explicit guidance on when to use this tool: 'Use spectra_get_curator_dashboard for operational overview before stress testing.' It also lists alternatives for other tasks, such as spectra_get_pool_capacity and morpho_monitor_risk. Additionally, it highlights the ERC-7540 constraint, making the importance of pre-stress liquidity checks clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it explains search modes, precedence, enriched Merkl data, subsidized rates (potentially negative), and protocol context like LLTV and utilization. It fully discloses 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?
The description is well-organized with sections (intro, search modes, enrichment, protocol context, alternatives). It is front-loaded with purpose and every sentence adds value. It is appropriately sized for the complexity.
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 complexity (6 params, no output schema, many siblings), the description is complete: it explains search modes, enrichment, protocol context, and references related tools. It adequately covers what the tool returns and how to use it.
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% (baseline 3), but the description adds significant meaning beyond schema: it explains the two search modes in detail, the difference between pt_symbol_filter and collateral_filter, and precedence rule. It provides high-level guidance 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 clearly states the tool's purpose: 'Find Morpho Blue lending markets by collateral type.' It specifies the verb, resource, and scope, and distinguishes it from siblings like spectra_get_looping_strategy and morpho_get_rate.
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?
The description provides explicit guidance on when to use this tool vs alternatives, e.g., 'Use spectra_get_looping_strategy for leveraged yield calculation. Use morpho_get_rate for live borrow APY.' It also explains the two search modes and when to use each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It explains the no-close-factor quirk, defines alert levels with thresholds, and notes that multiple signals may disagree. This is highly transparent.
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 well-structured, starting with the core purpose, then key metrics, alert levels, and sibling tool usage. Every sentence adds value, with no redundancy or fluff.
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 complexity of risk monitoring and no output schema, the description thoroughly covers inputs, output interpretation (alert levels), behavioral quirks, and alternatives. No critical 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?
Schema description coverage is 100%, so baseline is 3. The description adds context by explaining the significance of distance-to-liquidation and the default threshold behavior, going slightly beyond the schema's parameter 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 monitors liquidation risk across a curator's Morpho positions, computing health factor, liquidation price, distance-to-liquidation, and borrow rate. It distinguishes from siblings like morpho_get_positions and morpho_get_history.
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?
Explicit guidance is provided on when to use this tool vs alternatives: use morpho_get_positions for raw data, morpho_get_history for rate stability, and spectra_get_looping_strategy for deleverage scenarios. This helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Comprehensively discloses behavioral traits: returns raw token amounts (no USD), block range strategies, parallel fetching, contract types, limitations (max 500k blocks, public RPC rate limits), and RPC override behavior.
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?
Well-structured with bullet points and sections; each sentence adds value. Slightly lengthy but appropriate given the complexity; could be trimmed slightly without loss.
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?
Covers all necessary aspects including contract types, events, parallel fetching, block ranges, limitations, and alternative tool reference. No output schema, but return values (raw token amounts) are clearly stated.
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?
Despite 100% schema coverage, the description adds significant context beyond schema: explains event types for each contract, behavior when both addresses provided, block range logic, RPC fallback, and hints for token_decimals.
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 fetches historical on-chain activity via eth_getLogs and distinguishes itself from the sibling tool spectra_get_pool_activity by focusing on historical data beyond the API's retention window.
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 states when to use this tool (when spectra_get_pool_activity returns empty/incomplete data) and when to use the alternative, providing clear comparison and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It thoroughly details the tool's behavior: what data is returned (curator info, TVL, APY, LP positions, external positions with caveats, cross-chain modules, status flags, vault flows, bridge transactions, epoch history), how the verify_onchain flag works (adds chain-truth line, never aborts on failure, concurrency capped at 6), and the handling of HIDDEN vaults. It even notes that the external positions field is undocumented and may change.
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 with a summary, bullet points of returned data, and usage guidance. It is somewhat verbose but each sentence adds value. The dissolution note on verify_onchain is a nice touch but slightly wordy. Overall, it earns a 4 for being clear and organized despite length.
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 complexity of the tool (many sibling tools, chain reads, cross-chain features) and the lack of an output schema, the description is remarkably complete. It covers all relevant aspects: what the tool returns, how to use it with other tools, edge cases (HIDDEN vaults, fallback for unknown protocols), and behavioral details like concurrency limits and failure handling.
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 coverage is 100% with descriptions for both parameters. The description adds significant value beyond the schema: for 'chain', it clarifies that omitting the parameter scans all chains. For 'verify_onchain', it provides extensive context on behavior, use cases, and even a potential future deprecation path, giving the agent deep 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 defines the tool's purpose: listing live MetaVaults from the Spectra API. It provides a solid definition of MetaVaults and explicitly distinguishes the tool from siblings like spectra_model_metavault and spectra_get_curator_dashboard, giving the agent a precise understanding of when to use this tool.
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?
The description offers explicit usage guidance: use this tool to discover live MetaVaults, then pass the address to spectra_model_metavault for detailed modeling or spectra_get_curator_dashboard for operational views. It also provides clear alternatives for investigating curator activity (spectra_get_address_activity) and explains when to use the verify_onchain flag, including its trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the quote method (on-chain get_dy() or math estimate), accuracy differences, and return contents including pool context and source indication. No annotations exist, so description fully covers behavior.
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?
Well-organized with front-loaded purpose, but slightly lengthy. However, every section adds value, so it's still highly effective.
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 no output schema, the description thoroughly explains return values (expected output, rates, pool context, etc.) and covers all necessary context for a quoting tool.
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?
All 5 parameters have schema descriptions. The tool description adds extra meaning, such as defining side meanings ('buy' vs 'sell'), explaining slippage formula, and clarifying amount units.
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 estimates expected output, price impact, and minimum output for a PT trade. It distinguishes from YT and mentions specific sibling tools for alternatives.
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 explains when to use on-chain vs fallback, and suggests alternatives like spectra_simulate_trade and spectra_compare_yield for additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: input modes, case-insensitive label resolution, cross-chain scanning, suppression rules for single-vault/single-underlying curators, and silent handling of no genuine signals. 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?
Well-structured with numbered modes and bullet-point return fields. Every sentence provides essential information. Front-loaded with purpose. Efficient use of ~200 words.
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?
Despite no output schema, description thoroughly lists all return fields (AUM, APY, fee revenue, concentration, per-vault summary, cross-vault items) with conditions. Covers input modes, edge cases, and suppression rules. Complete for agent decision-making.
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 coverage is 100% but description adds significant context: explains three input modes and their priority, clarifies curator_label resolves case-insensitively across chains, and details curator_fee_pct default and purpose. Adds 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 the tool aggregates multiple MetaVaults into a portfolio view, with specific verb 'Aggregate' and resource 'MetaVaults'. It distinguishes from siblings like spectra_get_curator_dashboard and morpho_monitor_risk.
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 describes three input modes with priority order (explicit > label > address). Provides use cases for each mode and references sibling tools for alternative actions (deep-dive, risk monitoring, stress test).
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:

[![spectra-mcp-server MCP server](https://glama.ai/mcp/servers/Finanzgoblin/spectra-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Finanzgoblin/spectra-mcp-server)

Score Badge

Copy to your README.md:

[![spectra-mcp-server MCP server](https://glama.ai/mcp/servers/Finanzgoblin/spectra-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Finanzgoblin/spectra-mcp-server)

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/Finanzgoblin/spectra-mcp-server'

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