REI Crypto MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Tools are generally distinct by resource type (e.g., bridges, prices, protocols), but there is notable overlap in some areas. For example, multiple price-related tools (get_current_prices, get_historical_prices, get_price_chart, get_price_percentage) could cause confusion about which to use for specific price queries. Similarly, overview and summary tools for derivatives, dexs, and options have overlapping purposes that might require careful reading of descriptions to differentiate.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, all starting with 'get_' followed by a descriptive noun phrase (e.g., get_bridge_details, get_historical_prices). There are no deviations in naming style, making it easy to predict tool names and understand their general purpose at a glance.
Tool Count2/5
With 61 tools, the count is excessive for a single server, making it overwhelming and difficult for an agent to navigate efficiently. While the server covers a broad crypto domain (prices, bridges, protocols, yields, etc.), the toolset feels bloated and could benefit from consolidation or modularization into more focused servers.
Completeness4/5
The toolset provides extensive coverage across multiple crypto domains (e.g., prices, bridges, protocols, yields, stablecoins), with CRUD-like operations for many resources. However, there are minor gaps, such as limited update or delete operations (typical for read-heavy APIs) and some areas like user data or emissions lacking full lifecycle coverage, though agents can likely work around these given the breadth of read operations.
Average 3.1/5 across 61 of 61 tools scored. Lowest: 2.5/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?
No annotations are provided, so the description carries full burden. It mentions a parameter 'pool_old' but doesn't disclose behavioral traits like whether this is a read-only operation, what data format is returned, or any constraints. The description is insufficient for understanding how the tool behaves beyond a vague parameter mention.
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 brief but poorly structured. It starts with 'GET /yields/poolsOld' which is redundant with the tool name, and the second sentence adds minimal context. While concise, it lacks front-loaded clarity and wastes space on tautological elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and an output schema exists, the description doesn't need to explain return values. However, with no annotations and a vague purpose, it fails to provide complete context for tool selection. It's minimally adequate but has clear gaps in explaining what this tool does compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description mentions a parameter 'pool_old' which might be confusing since the schema shows none, but this doesn't negatively impact the score as the baseline for 0 parameters is 4. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Same as /pools' which is tautological with the tool name 'get_yield_pools_old' and doesn't clearly articulate what the tool does. It mentions a parameter 'pool_old' but doesn't explain what resource or data this tool retrieves. The purpose remains vague and circular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_yield_pools' or 'get_yield_pools_borrow' from the sibling list. It only mentions a parameter difference without context on use cases or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions it's a GET operation but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what the output contains. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by parameter details. It avoids unnecessary verbosity, though the structure could be improved by integrating the HTTP endpoint more naturally into the 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?
Given 2 parameters with 0% schema coverage and an output schema present, the description is incomplete. It lacks details on parameter semantics and behavioral context, but the output schema mitigates some gaps by presumably defining return values. This results in a minimally adequate but insufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters with brief examples ('e.g., 'activeUsers'') but doesn't explain valid values, constraints, or the relationship between type and protocol_id. This adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get user data by type and protocol' which provides a basic purpose, but it's vague about what 'user data' entails and doesn't distinguish from sibling tools like 'get_active_users'. The HTTP method 'GET' is mentioned but doesn't clarify the action beyond retrieving data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_active_users' that might overlap, the description offers no context on differentiation, prerequisites, or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Unlocks data' but does not clarify if this is a read-only operation, requires authentication, has rate limits, or what the output entails (though an output schema exists). The term 'Unlocks' is vague and could imply mutative or computational behavior without further explanation.
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 brief but includes unnecessary technical details (e.g., 'GET /api/emission/{protocol}') that do not aid the AI agent. The core purpose and parameter explanation are front-loaded, but the structure could be more streamlined by omitting the API endpoint and focusing solely on functional guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with low schema coverage and an output schema present, the description provides basic parameter semantics but lacks details on behavioral traits, usage context, or output interpretation. It is minimally adequate for a simple data-fetching tool but misses opportunities to clarify scope or differentiate from siblings like 'get_emissions.'
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 description adds meaning by specifying that the 'protocol' parameter is a 'protocol slug' with an example ('aave'), which is valuable since the input schema has 0% description coverage and only provides a title. With 1 parameter, this compensates well, though it could further clarify allowed values or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Unlocks data for a given token/protocol,' which provides a vague purpose but lacks specificity about what type of data (e.g., emission rates, schedules, metrics) or what 'unlocks' means operationally. It distinguishes from siblings by focusing on emission data, but the verb 'Unlocks' is ambiguous compared to clearer alternatives like 'Retrieves' or 'Fetches.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as sibling tools like 'get_emissions' (which might overlap) or other data-fetching tools. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it's a GET operation, lacking details on rate limits, authentication needs, response format, or error handling. This leaves significant behavioral gaps for an agent.
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?
It's brief but inefficiently structured with redundant URL-like text ('GET /etfs/overviewEth'). The core description 'Get ETH ETFs' is clear but could be more front-loaded without the extra line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, 100% schema coverage, and an output schema exists, the description minimally covers purpose. However, without annotations and with sibling tools present, it lacks sufficient context on usage and behavior, making it incomplete for optimal agent guidance.
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?
With 0 parameters and 100% schema coverage, the input schema fully documents no inputs. The description doesn't add parameter info, which is acceptable here as there are no parameters to explain, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get ETH ETFs' which provides a basic verb+resource combination, but it's vague about what specific data is retrieved (e.g., overview, list, metrics). It doesn't distinguish from sibling 'get_etf_overview' which likely provides general ETF data, leaving ambiguity about the ETH-specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_etf_overview' or 'get_etf_history_eth'. The description merely restates the action without context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool is a GET operation, implying it is read-only, but does not confirm this or address other aspects like rate limits, authentication needs, error handling, or response format. The description lacks details on what the breakdown includes (e.g., token types, address categories) or any constraints, making it insufficient for a tool with no annotation support.
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 appropriately sized and front-loaded, starting with the purpose in the first sentence. The parameter explanations are concise and directly relevant. However, the inclusion of 'GET /bridgedaystats/{timestamp}/{chain}' is somewhat redundant with the tool name and could be omitted for better flow, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (as per context signals), the description does not need to explain return values. However, for a tool with 3 parameters, 0% schema description coverage, and no annotations, the description is moderately complete: it covers the purpose and parameter semantics but lacks behavioral details like rate limits or error cases. It is adequate but has clear gaps in guiding the agent on usage and transparency.
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 0%, so the description must compensate. It adds meaning by explaining that 'timestamp' is a 'Unix timestamp for the 24hr period starting at 00:00 UTC', 'chain' is a 'chain slug (e.g., 'Ethereum')', and 'id' is a 'bridge ID (optional, can be retrieved from /bridges)'. This clarifies the purpose and format of parameters beyond the basic schema, but it does not provide examples for 'chain' beyond one slug or detail how 'timestamp' aligns with UTC, leaving some gaps.
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 the tool's purpose: 'Get a 24hr token and address volume breakdown for a bridge.' It specifies the verb ('Get'), resource ('24hr token and address volume breakdown'), and scope ('for a bridge'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'get_bridge_volume' or 'get_bridge_transactions', which might offer related data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that the 'id' parameter is optional and can be retrieved from '/bridges', which hints at a prerequisite, but it does not explain when to use this tool versus alternatives like 'get_bridge_volume' or 'get_bridge_transactions'. There is no explicit context on when or when not to use it, leaving the agent to infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the action ('Get the closest block') but doesn't explain what 'closest' means (e.g., before, after, or nearest in time), potential errors (e.g., invalid chain or timestamp), rate limits, or authentication needs. This is insufficient for a tool with no annotation coverage.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a URL and parameter list. There's no wasted text, but the structure could be slightly improved by integrating the URL more seamlessly. Overall, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters) and the presence of an output schema, the description is partially complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. The output schema likely handles return values, so the description doesn't need to explain those, but it should address other gaps like error handling or constraints.
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 0%, but the description compensates by listing parameters with brief explanations: 'chain: chain identifier' and 'timestamp: UNIX timestamp to find closest block for.' This adds meaning beyond the schema's generic titles. However, it doesn't detail valid chain values or timestamp constraints, leaving gaps. With 0% coverage, baseline is lower, but the description provides some value.
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 the tool's purpose: 'Get the closest block to a timestamp.' It specifies the verb ('Get') and resource ('closest block'), and the URL path '/coins/block/{chain}/{timestamp}' reinforces this. However, it doesn't differentiate from sibling tools, which appear unrelated (e.g., get_active_users, get_historical_prices), so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites, such as valid chain identifiers or timestamp ranges, and doesn't mention any sibling tools that might serve similar purposes. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'GET /api/entities' which implies a read-only HTTP operation, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'entities' encompasses. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short lines, front-loading the purpose. However, it includes the endpoint path 'GET /api/entities' which might be redundant if the tool name already implies this, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and an output schema exists, the description doesn't need to explain return values. However, with no annotations and a generic purpose among many siblings, it lacks context on what 'entities' are and operational behavior, making it incomplete for effective use.
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 with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List all entities' which provides a clear verb+resource combination, but it doesn't differentiate from sibling tools like 'get_protocols' or 'get_categories' that might also list different types of entities. The purpose is understandable but generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools that fetch different data types (e.g., get_protocols, get_stablecoins), the description lacks context on what 'entities' refers to or when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes a read operation ('Get chart') but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'chart' entails (e.g., format, size). The mention of 'narratives' and 'weighted by mcap' adds some context, but key operational details are missing.
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 appropriately sized with three sentences: purpose, parameter explanation, and a brief note on weighting. It's front-loaded with the main action. No wasted words, though it could be slightly more structured (e.g., bullet points for parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with good description coverage and an output schema (implied by context signals), the description is adequate for basic use. However, without annotations and with vague terms like 'narratives' and 'chart', it lacks completeness for understanding the tool's full behavior and output. Sibling tools suggest this is part of a financial data API, but the description doesn't integrate that context.
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 0%, but the description compensates by explaining the 'period' parameter with its enum values ['7', '30', 'ytd', '365']. This adds meaning beyond the schema's title 'Period', clarifying the specific time intervals. Since there's only one parameter, this is sufficient for good understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get chart of narratives based on category performance' which provides a general purpose, but it's vague about what 'narratives' and 'category performance' specifically mean. It mentions coins weighted by market cap, but doesn't clarify the resource or output format. Compared to siblings like 'get_categories' or 'get_price_chart', the distinction is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention any prerequisites, exclusions, or suggest other tools for related tasks. Given many sibling tools for data retrieval (e.g., 'get_categories', 'get_price_chart'), the lack of comparative context leaves usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the TVL excludes liquid staking and double-counted TVL, which is useful context, but lacks details on permissions, rate limits, response format, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded, starting with the core purpose and then detailing parameters. It uses two sentences efficiently, with no wasted words, though it could be slightly more structured (e.g., separating usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is somewhat complete. However, with no annotations and missing usage guidelines, it falls short of providing full context for effective tool invocation, especially compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates by explaining the 'chain' parameter as a 'chain slug (e.g., 'Ethereum')', adding semantic meaning beyond the schema's basic type. However, with only one parameter, the baseline is high, and it doesn't fully detail format constraints or provide examples beyond one, so it meets but doesn't exceed expectations.
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 the tool's purpose: 'Get historical TVL (excludes liquid staking and double counted tvl) of a chain.' It specifies the verb ('Get'), resource ('historical TVL'), and scope ('of a chain'), with important exclusions noted. However, it doesn't explicitly differentiate from sibling tools like 'get_historical_chain_tvl' (which appears to be a similar but distinct tool), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions exclusions in the TVL calculation but doesn't compare it to other TVL-related tools in the sibling list, such as 'get_historical_chain_tvl' or 'get_protocol_tvl', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool provides liquidity data but doesn't specify whether it's read-only, requires authentication, has rate limits, or details the response format (though an output schema exists). For a tool with no annotation coverage, this is a significant gap in describing behavioral traits.
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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. It uses two sentences efficiently, though the parameter section could be integrated more smoothly. There's no wasted text, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameter example but lacks usage guidelines and behavioral context. The output schema mitigates some gaps, but overall, it's adequate with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It explains the 'token' parameter as 'token slug (e.g., 'usdt')', which provides an example but doesn't clarify format constraints or source. With 0% schema description coverage and 1 parameter, this is adequate but not comprehensive, aligning with the baseline expectation.
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 the tool's purpose: 'Provides the available liquidity for swapping from one token to another on a specific chain.' It specifies the verb ('Provides'), resource ('available liquidity'), and scope ('swapping from one token to another on a specific chain'). However, it doesn't explicitly differentiate from sibling tools like 'get_historical_prices' or 'get_current_prices', which might also involve tokens but serve 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts (e.g., historical vs. current data, swapping scenarios). With many sibling tools related to tokens and prices, this lack of differentiation leaves the agent uncertain about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a GET operation, implying read-only behavior, but doesn't clarify aspects like rate limits, authentication needs, error handling, or what the historical data entails (e.g., time range, format). For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
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 appropriately sized and front-loaded, starting with the HTTP method and endpoint, followed by a clear purpose statement and parameter details. It avoids unnecessary fluff and is structured for quick comprehension, though it could be slightly more concise by integrating the parameter explanations more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values, which is adequate. However, with no annotations, 2 parameters (one with low schema coverage), and complexity around options data, the description is minimal. It covers the basics but lacks depth on usage context, behavioral details, and parameter nuances, making it just sufficient but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the input schema by explaining that 'protocol' is a 'protocol slug' with an example ('lyra') and 'data_type' has a default value and specifies the data type. However, with 0% schema description coverage, it doesn't fully compensate for the lack of schema descriptions, as it doesn't detail the enum values' implications or provide further context for the parameters.
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 the tool's purpose: 'Get summary of options dex volume with historical data.' It specifies the action ('Get summary'), resource ('options dex volume'), and scope ('with historical data'), which is specific and informative. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_options_overview' or 'get_options_overview_by_chain', which might also relate to options data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the parameters but doesn't explain the context for selecting this tool over other options-related tools in the sibling list, such as 'get_options_overview' or 'get_options_overview_by_chain'. There are no usage prerequisites, exclusions, or comparisons provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'GET /api/raises' which implies a read-only HTTP GET operation, but doesn't disclose any behavioral traits like rate limits, authentication requirements, pagination, data freshness, or what happens if no raises exist. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences. The first sentence provides the API endpoint, and the second explains the purpose. No wasted words, though it could be more informative. The structure is front-loaded with the endpoint information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, for a data retrieval tool with no annotations, it lacks important context about what 'raises' means, the data format, or usage constraints. The output schema will handle return values, but the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't discuss parameters, which is appropriate. Baseline for 0 parameters with complete schema coverage is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Overview of all raises on our Raises dashboard' which provides a general purpose (retrieving raise data) but lacks specificity about what 'raises' means or what data is included. It distinguishes from siblings by mentioning 'raises' but doesn't clarify if this is about fundraising, price increases, or other types of raises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description mentions 'Raises dashboard' which implies a specific context, but doesn't explain when this tool is appropriate versus other data retrieval tools in the sibling list. No explicit when/when-not statements or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is a GET request and describes the output ('historical mcap sum'), but lacks critical details like rate limits, authentication requirements, error handling, or pagination behavior. For a data-fetching tool with no annotations, this is a significant gap in 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 concise and well-structured, with the endpoint path upfront followed by a clear purpose statement and parameter details. There's no wasted text, and information is presented in a logical order, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should cover return values), the description provides basic purpose and parameter info. However, for a tool with no annotations and incomplete parameter documentation, it lacks sufficient context on usage, behavior, and integration details. It's minimally adequate but has clear gaps in guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some parameter semantics by noting that 'stablecoin' is an 'optional' 'stablecoin ID', which clarifies its purpose beyond the schema's generic 'Stablecoin' title. However, with 0% schema description coverage and only one parameter, it doesn't fully compensate—e.g., it doesn't explain what a 'stablecoin ID' is or provide examples. The baseline is adjusted due to low coverage but limited improvement.
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 the tool's purpose: 'Get historical mcap sum of all stablecoins.' It specifies the verb ('Get') and resource ('historical mcap sum of all stablecoins'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_stablecoin_charts_by_chain' or 'get_stablecoin_history', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools such as 'get_stablecoin_charts_by_chain' or 'get_stablecoin_history'. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a GET operation (implying read-only) and describes the output ('historical mcap sum'), but lacks critical details: it doesn't specify the time range or granularity of 'historical' data, whether results are paginated, rate limits, authentication requirements, or error conditions. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded: the first line states the purpose clearly, followed by a structured parameters section. There's no wasted text, and each sentence adds value (e.g., the parameters list clarifies usage). However, it could be slightly more concise by integrating the parameter details into a single flowing sentence, and the URL path duplication is minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, historical data fetching), the description is minimally adequate. It explains the purpose and parameters but lacks behavioral context (e.g., time ranges, pagination). The presence of an output schema (not shown) means the description doesn't need to detail return values, but without annotations, it should cover more operational aspects like data freshness or constraints. It's complete enough for basic use but leaves gaps for robust 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 0%, so the schema provides no parameter descriptions. The description adds value by explaining 'chain' as a 'chain slug (e.g., 'Ethereum')' and 'stablecoin' as an 'optional' 'stablecoin ID', giving basic semantics. However, it doesn't clarify where to find valid chain slugs or stablecoin IDs, the format of the ID (integer vs. string), or how the optional parameter affects results (e.g., filtering vs. aggregation). With 2 parameters and low schema coverage, this partial compensation earns a baseline 3.
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 the tool's purpose: 'Get historical mcap sum of all stablecoins in a chain.' This specifies the verb ('Get'), resource ('historical mcap sum'), and scope ('all stablecoins in a chain'). It distinguishes from siblings like 'get_stablecoin_charts_all' (which lacks chain filtering) and 'get_stablecoin_history' (which focuses on individual stablecoin history rather than aggregate mcap). However, it doesn't explicitly contrast with all relevant siblings (e.g., 'get_stablecoin_chains'), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions an optional 'stablecoin' parameter but doesn't explain when to include it (e.g., to filter to a specific stablecoin vs. get all). There's no mention of prerequisites, data freshness, or comparison to siblings like 'get_stablecoin_charts_all' (for all chains) or 'get_stablecoin_history' (for individual stablecoin details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a GET operation, implying read-only behavior, but lacks details on authentication needs, rate limits, error handling, or output format. The mention of 'largest coin in a chain' adds some context, but overall behavioral traits are insufficiently covered.
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 concise and front-loaded, starting with the core purpose. It uses two sentences effectively, with no wasted words. However, the inclusion of 'GET /stablecoins/stablecoindominance/{chain}' is somewhat redundant with the tool name, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and an output schema present, the description provides basic purpose and parameter info but lacks usage guidelines and detailed behavioral context. It is minimally adequate for a read-only tool with output schema, but could be more complete by explaining when to use it and clarifying parameter details.
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 0%, so the description must compensate. It explains 'chain' as 'chain slug (e.g., 'Ethereum')' and 'stablecoin' as 'stablecoin ID (optional)', adding basic semantics. However, it does not clarify what 'stablecoin dominance' means or provide examples for 'stablecoin ID', leaving gaps in parameter understanding.
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 the tool's purpose: 'Get stablecoin dominance per chain along with the info about the largest coin in a chain.' It specifies the verb ('Get'), resource ('stablecoin dominance'), and scope ('per chain'), but does not explicitly differentiate from sibling tools like 'get_stablecoin_charts_by_chain' or 'get_stablecoins', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lists parameters but does not mention use cases, prerequisites, or comparisons to sibling tools such as 'get_stablecoin_charts_by_chain' or 'get_stablecoins', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a GET operation (implying read-only) and mentions retrieving historical data, but lacks details on authentication needs, rate limits, error handling, data freshness, or output format. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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 concise and front-loaded, starting with the HTTP method and endpoint, followed by the core purpose and a parameter list. It avoids unnecessary fluff, with every sentence contributing directly to the tool's definition. However, the structure could be slightly improved by integrating the parameter explanation more seamlessly, but it remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (historical data retrieval), no annotations, and an output schema present, the description is partially complete. It covers the basic purpose and parameter, but lacks behavioral context (e.g., data scope, limitations) that annotations would typically provide. The output schema mitigates the need to explain return values, but overall, the description feels minimal for a tool with potential nuances in historical data access.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics: it lists 'asset: stablecoin ID' as a parameter, which matches the input schema's single required parameter 'asset' of type integer. However, schema description coverage is 0%, so the schema provides no additional details. The description doesn't clarify what a 'stablecoin ID' entails (e.g., numeric codes, naming conventions), offering only basic context without compensating for the low schema coverage.
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 the tool's purpose: 'Get historical mcap and historical chain distribution of a stablecoin.' It specifies the verb ('Get') and resource ('historical mcap and historical chain distribution'), making it distinct from sibling tools like 'get_stablecoins' (list) or 'get_stablecoin_prices' (current prices). However, it doesn't explicitly differentiate from 'get_stablecoin_charts_all' or 'get_stablecoin_charts_by_chain', which might also involve historical data, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_stablecoin_charts_all' or 'get_stablecoin_charts_by_chain', which could be related for historical data, nor does it specify prerequisites or exclusions (e.g., asset ID format, time ranges). Usage is implied only by the tool name and description, with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what data is retrieved ('active users') without mentioning response format, pagination, rate limits, authentication requirements, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but includes redundant information - the HTTP method 'GET' is already implied by the tool name starting with 'get_'. The second sentence is useful but could be more efficiently integrated. The structure is front-loaded with the API endpoint, which is less helpful than starting with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and it's a simple data retrieval operation, the description is minimally adequate. However, with no annotations and a generic 'active users' concept, more context about what constitutes 'active' or the data format would be helpful. The existence of an output schema reduces but doesn't eliminate the need for some behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. This meets the baseline expectation for parameterless tools.
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 the tool's purpose with a specific verb ('Get') and resource ('active users'), and specifies the scope ('on our chains and protocols pages'). It doesn't explicitly differentiate from sibling tools, but the specificity of 'active users' makes its purpose distinct from other data retrieval tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparison with sibling tools like 'get_user_data' or 'get_protocols' that might overlap in user-related data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a GET operation (implying read-only) and mentions 'overview' but doesn't describe response format, pagination, rate limits, authentication requirements, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but includes redundant information - the HTTP method 'GET /api/categories' could be inferred from the tool name. The second sentence provides the core value. While concise, the structure could be more front-loaded with the essential purpose rather than leading with implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, for a data retrieval tool with no annotations, it should ideally describe what 'categories' means in this context, the response structure, or any limitations. The existence of an output schema reduces but doesn't eliminate the need for contextual explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, which is correct. Baseline for 0 parameters is 4.
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 the tool's purpose as 'Overview of all categories across all protocols' which is a specific verb+resource combination. It distinguishes itself from siblings by focusing on categories rather than users, prices, bridges, or other data types. However, it doesn't explicitly contrast with potential similar tools (though none appear in the sibling list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or how it differs from other data retrieval tools in the sibling list. The agent must infer usage from the title and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a GET operation, implying read-only behavior, but lacks details on permissions, rate limits, pagination, or response format. For a tool with no annotations, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, but includes redundant information (the API endpoint 'GET /api/chainAssets') that doesn't add value for an AI agent. It could be more streamlined by focusing solely on the functional intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0 parameters, and an output schema exists, the description is minimally adequate. It states the purpose but lacks behavioral context (e.g., what 'assets' entail, data freshness). The output schema likely covers return values, so completeness is borderline but has clear gaps.
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 with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is acceptable here. Baseline is 4 for zero parameters, as it doesn't need to compensate for any gaps.
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 the verb ('Get') and resource ('assets of all chains'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_chains' or 'get_historical_chain_tvl', which might also relate to chain data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to chains and assets (e.g., 'get_chains', 'get_historical_chain_tvl'), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't mention any behavioral traits such as rate limits, authentication needs, data freshness, or error handling. For a tool with zero annotation coverage, this is a significant gap in 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 concise with two sentences, but the first sentence ('GET /stablecoins/stablecoinchains') is redundant API endpoint information that doesn't add value for an AI agent. The second sentence is the core description. While efficient, the inclusion of the endpoint reduces clarity and front-loading effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, an output schema exists, and no annotations, the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral details, or output interpretation. The presence of an output schema means return values are documented elsewhere, but the description doesn't fully compensate for the missing behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, and it doesn't add or contradict any parameter information. A baseline of 4 is appropriate for a parameterless tool where the schema fully covers the absence of inputs.
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 the tool's purpose: 'Get current mcap sum of all stablecoins on each chain.' It specifies the verb ('Get'), resource ('mcap sum of all stablecoins'), and scope ('on each chain'). However, it doesn't explicitly differentiate from sibling tools like 'get_stablecoins' or 'get_stablecoin_charts_by_chain', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to stablecoins (e.g., 'get_stablecoins', 'get_stablecoin_charts_by_chain'), there is no indication of context, prerequisites, or exclusions. The agent must infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves historical prices but doesn't disclose behavioral traits such as rate limits, authentication requirements, data freshness, pagination, error handling, or response format. This is a significant gap for a tool with no annotation coverage.
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 concise with two sentences, but the first sentence ('GET /stablecoins/stablecoinprices') is redundant API endpoint information that doesn't add value for an AI agent. The second sentence is clear but could be more front-loaded with essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and siblings offering similar functionality, it lacks completeness in distinguishing use cases and behavioral context, which could confuse 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?
The tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter semantics, as there are none to document. It appropriately focuses on the tool's purpose without unnecessary parameter details.
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 the tool's purpose: 'Get historical prices of all stablecoins.' It specifies the verb ('Get'), resource ('historical prices'), and scope ('all stablecoins'). However, it doesn't differentiate from sibling tools like 'get_stablecoin_history' or 'get_current_prices', which might offer similar data with different timeframes or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_stablecoin_history' and 'get_current_prices' available, there's no indication of whether this tool is for bulk historical data, real-time prices, or specific time ranges. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a GET operation, implying read-only, but doesn't specify rate limits, authentication needs, response format, or data freshness. The description adds minimal behavioral context beyond the HTTP method.
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 brief with two sentences, but the first sentence is just the endpoint path, which adds little value beyond the tool name. The second sentence states the purpose efficiently. It's front-loaded with the endpoint, but could be more informative by integrating the purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, for a data retrieval tool with no annotations, it lacks details on data scope (e.g., time period, LSD types), response structure, or error handling, leaving gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could mention if any implicit parameters (like time range) are assumed. Baseline is 4 for zero-parameter tools.
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 the tool retrieves APY rates of multiple LSDs (Liquid Staking Derivatives), which is a specific verb ('GET') and resource ('yields/lsdRates'). It distinguishes from siblings by focusing on LSD yield rates rather than other yield-related tools like get_yield_chart or get_yield_pools. However, it doesn't explicitly contrast with all siblings, just implies a specific data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it refer to sibling tools like get_yield_pools or get_yield_chart that might offer related data. Usage is implied only by the endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions the action (GET) and data type (borrow costs APY), but fails to disclose critical traits like rate limits, authentication needs, error handling, or response format, which are essential for safe and effective use.
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 concise with three lines, but it includes redundant information (the endpoint 'GET /yields/poolsBorrow') that may not add value beyond the tool name. The core purpose is stated clearly, but the structure could be more streamlined by focusing solely on the functional 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?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, it lacks details on behavioral aspects like data freshness, scope (e.g., all assets or filtered), or integration context, which would enhance completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, but this is acceptable given the lack of parameters, aligning with the baseline for zero parameters.
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 the tool's purpose: retrieving borrow costs APY of assets from lending markets. It specifies the resource (borrow costs APY) and action (GET), though it doesn't explicitly differentiate from sibling tools like 'get_yield_pools' or 'get_yield_pools_old', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about use cases, prerequisites, or comparisons to sibling tools such as 'get_yield_pools' or 'get_yield_chart_lend_borrow', leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'List all bridges' but doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, or what 'recent' means temporally. The description is minimal and lacks crucial operational details for a 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?
The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter details. Every sentence adds value without redundancy. However, it could be slightly more structured by separating the purpose and parameters more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no annotations, but with an output schema), the description is moderately complete. It covers the purpose and parameter semantics adequately, but lacks behavioral transparency and usage guidelines. The output schema likely handles return values, so the description doesn't need to explain those.
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 description adds meaningful context for the single parameter 'include_chains', explaining it as 'set whether to include current previous day volume breakdown by chain'. This clarifies the parameter's purpose beyond the schema's basic title and type, compensating for the 0% schema description coverage. No other parameters exist, so this is sufficient.
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 the tool's purpose: 'List all bridges along with summaries of recent bridge volumes.' It specifies the verb ('List'), resource ('bridges'), and scope ('summaries of recent bridge volumes'), which distinguishes it from siblings like 'get_bridge_details' or 'get_bridge_transactions'. However, it doesn't explicitly differentiate from 'get_bridge_volume', which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_bridge_details' for detailed info or 'get_bridge_volume' for volume-specific data, nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves historical volumes, implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, error handling, or data freshness. While it hints at the scope ('historical volumes'), it lacks details on time ranges, data formats, or pagination, which are critical for an agent to use it effectively.
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 appropriately sized and front-loaded, starting with the core purpose in the first sentence. The parameter explanations are concise and directly relevant. There's no unnecessary fluff, and the structure (purpose followed by parameters) is logical. However, it could be slightly more polished by integrating the parameter details more seamlessly into the narrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters well, but lacks behavioral context like rate limits or error handling. The presence of an output schema means the description doesn't need to explain return values, but it should still address usage nuances and potential constraints to be fully adequate.
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 description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains that 'chain' is a 'chain slug (e.g., 'Ethereum') or 'all' for volume on all chains' and that 'id' is an 'optional' 'bridge ID' that 'can be retrieved from /bridges'. This clarifies the parameter roles, formats, and relationships, compensating well for the schema's lack of descriptions.
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 the tool's purpose: 'Get historical volumes for a bridge, chain, or bridge on a particular chain.' It specifies the verb ('Get historical volumes') and resource ('bridge, chain, or bridge on a particular chain'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_bridge_day_stats' or 'get_bridge_transactions', which might also involve bridge-related data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions that 'id' is optional and can be retrieved from '/bridges', but offers no explicit advice on when to use this tool versus alternatives like 'get_bridge_day_stats' or 'get_bridge_transactions'. There's no mention of specific use cases, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API endpoint ('GET /coins/prices/current/{coins}') and a default parameter value, but doesn't describe error handling, rate limits, authentication needs, response format, or what happens with invalid inputs. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by parameter details. There's no wasted text, and the structure (purpose then parameters) is logical. It could be slightly more concise by integrating the endpoint into the purpose statement, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters well, but lacks behavioral context (e.g., error cases, rate limits). The presence of an output schema means return values don't need explanation, but other operational aspects are missing, making it adequate but with clear gaps.
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 description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains the 'coins' parameter format ('comma-separated tokens in format {chain}:{address}') with an example, and clarifies 'search_width' as 'time range on either side to find price data' with a default. This compensates well for the schema's lack of documentation, though it doesn't detail all possible values or constraints.
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 the tool's purpose: 'Get current prices of tokens by contract address.' It specifies the verb ('Get'), resource ('current prices of tokens'), and mechanism ('by contract address'). However, it doesn't explicitly differentiate from sibling tools like 'get_historical_prices' or 'get_stablecoin_prices', which is why it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'get_historical_prices' for historical data, 'get_stablecoin_prices' for stablecoins) or any prerequisites. The only implied context is the need for current token prices, but no explicit usage instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is a GET operation and describes some response exclusions, but does not cover critical aspects like rate limits, authentication needs, error handling, or the structure of the returned volume details. For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded, starting with the purpose and followed by parameter details. It uses bullet points for parameters, making it easy to scan. However, the first sentence could be more polished, and some redundancy exists (e.g., repeating 'total data chart'), but overall it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters adequately, but lacks behavioral context and usage guidelines. The presence of an output schema means return values are documented elsewhere, so the description's focus on parameters is acceptable, but overall completeness is moderate due to missing operational 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?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'protocol' is a 'slug (e.g., 'hyperliquid')' and clarifies the boolean parameters as exclusions for specific chart types. This compensates well for the schema's lack of descriptions, though it could provide more context on protocol options or chart details.
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 the tool's purpose: 'Volume Details about a specific perp protocol.' It specifies the verb ('GET') and resource ('derivatives summary'), but does not explicitly differentiate it from sibling tools like 'get_derivatives_overview' or 'get_options_summary', which might have overlapping scopes. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, such as when to choose this over 'get_derivatives_overview' or other summary tools. Usage is implied only by the parameter details, with no explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'GET' operation, implying read-only behavior, but doesn't clarify aspects like authentication requirements, rate limits, response format, or pagination. For a tool with no annotations, this is a significant gap in 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 appropriately sized and front-loaded, starting with the HTTP method and purpose, followed by parameter details. Every sentence adds value, with no redundant information. It could be slightly more structured with bullet points for parameters, but it remains efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, with no annotations and 0% schema description coverage, it partially compensates with parameter semantics but lacks behavioral details like authentication or rate limits. For a tool with two parameters and sibling alternatives, this is adequate but leaves gaps in usage context.
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 0%, so the description must compensate. It provides clear semantics for both parameters: 'exclude_total_data_chart: true to exclude aggregated chart from response' and 'exclude_total_data_chart_breakdown: true to exclude broken down chart from response.' This adds meaningful context beyond the schema's titles and types, though it doesn't cover default values or other nuances.
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 the tool's purpose: 'List all dexs along with summaries of their volumes and dataType history data.' It specifies the verb ('List'), resource ('dexs'), and what information is included ('summaries of their volumes and dataType history data'). However, it doesn't explicitly differentiate from sibling tools like 'get_dex_overview_by_chain' or 'get_dex_summary,' which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_dex_overview_by_chain' or 'get_dex_summary,' nor does it specify any prerequisites or contexts for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('List') and mentions data filtering, but lacks critical details like whether this is a safe read-only operation, potential rate limits, authentication requirements, or what the output looks like (though an output schema exists). For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by parameter details. Every sentence adds value, with no redundant information. However, the formatting could be slightly improved for readability (e.g., bullet points for parameters), but it remains efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 1 required), no annotations, and the presence of an output schema, the description is minimally adequate. It covers the purpose and parameters but lacks behavioral context and usage guidelines. The output schema mitigates the need to explain return values, but more detail on tool behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'chain' is a chain name with an example ('ethereum'), and clarifies the purpose of the two boolean parameters for excluding charts. This compensates well for the schema's lack of descriptions, though it doesn't detail all possible chain values or chart specifics.
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 the tool's purpose: 'List all dexs along with summaries of their volumes and dataType history data filtering by chain.' It specifies the verb ('List'), resource ('dexs'), and scope ('filtering by chain'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_dex_overview' or 'get_dex_summary', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions filtering by chain but doesn't explain why one would choose this over other dex-related tools in the sibling list, such as 'get_dex_overview' or 'get_dex_summary'. There are no explicit when-to-use or when-not-to-use instructions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a GET operation (implying read-only) and mentions historical data, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, pagination, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded, with the core purpose stated first. The parameter explanations are clear and necessary. However, the inclusion of the HTTP method 'GET /api/summary/dexs/{protocol}' is redundant with the tool name and could be omitted for better conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 1 required), no annotations, and the presence of an output schema, the description is partially complete. It covers the purpose and parameters adequately but lacks behavioral details (e.g., auth, errors) and usage guidelines. The output schema likely handles return values, so that gap is mitigated, but overall completeness is limited.
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 description adds meaningful context beyond the input schema. While the schema has 0% description coverage (only titles), the description explains that 'protocol' is a 'slug (e.g., 'uniswap')' and clarifies the boolean parameters control exclusion of specific chart types from the response. This compensates well for the schema's lack of descriptions, though it doesn't detail all possible protocol values or chart formats.
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 the tool's purpose: 'Get summary of dex volume with historical data.' It specifies the verb ('Get'), resource ('summary of dex volume'), and scope ('with historical data'). However, it doesn't explicitly differentiate from sibling tools like 'get_dex_overview' or 'get_dex_overview_by_chain', which might provide overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_dex_overview' or 'get_dex_overview_by_chain', nor does it specify prerequisites, exclusions, or appropriate contexts for usage. The only implied usage is based on the parameter descriptions, but no explicit guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'GET' and 'List', but doesn't specify details like pagination, rate limits, authentication requirements, or what constitutes 'basic info'. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is brief and front-loaded, consisting of two sentences: the HTTP endpoint and the core functionality. There's no unnecessary information, making it efficient. However, the structure could be slightly improved by combining the two sentences for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, 100% schema coverage, and an output schema exists), the description is adequate but minimal. It covers the basic purpose but lacks behavioral details that would be helpful for an agent, such as output format hints or usage context. The presence of an output schema reduces the need to describe return values, but more guidance on when to use this tool would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. This aligns with the baseline expectation for zero-parameter tools.
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 the tool's purpose: 'List of all tokens along with basic info for each.' It specifies the verb ('List') and resource ('tokens'), and the HTTP method 'GET /api/emissions' reinforces this as a read operation. However, it doesn't explicitly differentiate from sibling tools like 'get_emission_data' or 'get_token_protocols', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_emission_data' or 'get_token_protocols', leaving the agent to infer usage context based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a GET operation for historical data, implying read-only behavior, but doesn't cover important aspects like rate limits, authentication needs, data freshness, pagination, or error handling. For a data retrieval tool with zero annotation coverage, this is insufficient.
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 very concise with just two lines: the endpoint path and a brief explanation. It's front-loaded with the key information (GET operation and historical AUM focus). While efficient, it could potentially benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, for a historical data retrieval tool with no annotations, it lacks context about data format, time ranges, or comparison to siblings. The output schema helps, but the description itself is too sparse for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and it doesn't contradict the schema. A baseline of 4 is appropriate since no parameters exist and the schema coverage is complete.
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 the tool retrieves historical AUM (Assets Under Management) data for BTC ETFs, which is a specific verb ('GET') and resource ('historical AUM of all BTC ETFs'). It distinguishes from some siblings like 'get_etf_overview' or 'get_etf_history_eth', though not all siblings are directly comparable. However, it doesn't explicitly differentiate from all similar tools, keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when-not scenarios, prerequisites, or compare it to siblings like 'get_etf_history_eth' (for ETH ETFs) or 'get_etf_overview' (for overview data). This lack of contextual usage information results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a GET operation (implying read-only) and describes the type of data returned, but lacks critical information about rate limits, authentication requirements, response format, pagination, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with the HTTP method first, followed by a clear purpose statement. Both sentences earn their place - the first establishes the endpoint, the second specifies the data returned. No wasted words, though it could be slightly more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, 100% schema coverage, and an output schema exists, the description provides adequate basic information about what data is retrieved. However, with no annotations and multiple sibling tools in the same domain, it should provide more context about when to choose this specific ETF overview tool versus alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage (empty schema). The description appropriately doesn't waste space discussing non-existent parameters. A baseline of 4 is appropriate for zero-parameter tools where the schema already fully documents the absence of inputs.
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 the verb ('Get') and resource ('BTC ETFs and their metrics') with specific examples (aum, price, fees). It distinguishes from sibling 'get_etf_history' by focusing on current overview rather than historical data. However, it doesn't explicitly differentiate from 'get_etf_overview_eth' which appears to be an Ethereum-specific variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_etf_history' or 'get_etf_overview_eth'. It mentions what data is returned but gives no context about appropriate use cases, prerequisites, or limitations compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions historical data but doesn't specify time ranges, data freshness, rate limits, authentication requirements, or what the output contains beyond 'summary.' For a data retrieval tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences: the endpoint, core purpose, and parameter explanations. Each sentence adds value, though the parameter section could be slightly more structured. It's front-loaded with the most important information first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 2 parameters with reasonable description coverage, and no complex behavioral annotations needed, the description is moderately complete. However, it lacks usage context and some behavioral details that would help an agent understand when and how to invoke it effectively.
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 description adds meaningful parameter context beyond the schema. While schema description coverage is 0%, the description explains that 'protocol' is a 'slug (e.g., 'lyra')' and 'data_type' has a default value with implied options ('dailyFees', 'dailyRevenue'). This compensates well for the schema's lack of descriptions, though it doesn't fully document all parameter nuances.
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 the tool's purpose: 'Get summary of protocol fees and revenue with historical data.' It specifies the verb ('Get summary'), resource ('protocol fees and revenue'), and includes historical data scope. However, it doesn't explicitly differentiate from sibling tools like 'get_protocol_details' or 'get_protocol_tvl' that might also provide protocol-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or contextual scenarios where this specific fee/revenue summary would be preferred over other protocol data tools in the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('Get') but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the output looks like. For a tool with no annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. It avoids unnecessary fluff, though the inclusion of 'GET /coins/prices/first/{coins}' (which appears to be an API endpoint) adds minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one parameter, no annotations, but with an output schema), the description is minimally adequate. It covers the purpose and parameter format but lacks behavioral context. The presence of an output schema means return values are documented elsewhere, so the description doesn't need to explain them.
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 0%, but the description compensates by explaining the 'coins' parameter: 'comma-separated tokens in format {chain}:{address}'. This adds crucial semantic context beyond the schema's basic type information. With only one parameter, this is sufficient for a high score.
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 the tool's purpose: 'Get earliest timestamp price record for coins.' It specifies the verb ('Get'), resource ('price record'), and scope ('earliest timestamp'). However, it doesn't explicitly differentiate from sibling tools like 'get_current_prices' or 'get_historical_prices', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to prices (e.g., 'get_current_prices', 'get_historical_prices'), there's no mention of when this specific 'first price record' tool is appropriate or what distinguishes it from other price-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'GET' and 'Overview', implying a read-only operation, but lacks details on rate limits, authentication needs, response format, pagination, or error handling. This is inadequate for a tool with no annotation coverage, as it leaves critical behavioral traits unspecified.
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 brief and front-loaded with the API endpoint and purpose in two sentences, with no wasted words. However, the second sentence 'Overview of all forks across all protocols.' could be more precise (e.g., specifying what data is included in the overview), slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's minimal content is somewhat acceptable. However, with no annotations and many sibling tools, it lacks sufficient context on behavior, usage, and differentiation, making it incomplete for effective agent operation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed in the description. The description does not add any parameter semantics, but this is acceptable given the absence of parameters, warranting a baseline score of 4 as it does not detract from usability.
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 the tool retrieves an 'Overview of all forks across all protocols' with the verb 'GET' and resource '/api/forks', making the purpose specific and understandable. However, it does not explicitly differentiate this tool from its many sibling tools (e.g., get_protocols, get_protocol_details) beyond the focus on 'forks', leaving some ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like get_protocols or get_protocol_details, there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a GET operation (implying read-only) and returns an overview, but lacks details on permissions, rate limits, pagination, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the API endpoint and purpose. Both sentences are relevant, though the first sentence 'GET /api/hacks' is somewhat redundant with the tool name. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is moderately complete. However, with no annotations and a read operation, it should ideally mention the scope (e.g., time range, data freshness) or format of the overview to better guide the 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is acceptable given no parameters exist. Baseline is 4 for 0 parameters, as no compensation is needed.
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 the tool retrieves an 'Overview of all hacks on our Hacks dashboard' with the verb 'GET' and resource 'hacks'. It distinguishes from siblings by specifying the 'Hacks dashboard' context, though not explicitly contrasting with other tools. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions the 'Hacks dashboard' context, but there are no explicit instructions on prerequisites, timing, or comparisons with sibling tools like 'get_forks' or 'get_raises' that might relate to security incidents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is a GET operation, implying read-only behavior, but doesn't cover critical aspects like rate limits, error handling, authentication needs, or response format. The mention of 'search_width' hints at time-range behavior, but overall, the disclosure is insufficient for a tool with no annotation support.
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 and appropriately sized, with a clear purpose statement followed by parameter details. It uses bullet points for parameters, making it easy to parse. There's no wasted text, and it's front-loaded with the core functionality. A minor deduction for not being maximally concise (e.g., the URL line is redundant with the tool name).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is adequate but has gaps. It covers parameters well, and the output schema likely handles return values, so that's not needed. However, it lacks behavioral context (e.g., rate limits) and usage guidelines, making it incomplete for optimal agent operation. It meets the minimum viable standard but could be more comprehensive.
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 description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'timestamp' as a UNIX timestamp, 'coins' as comma-separated tokens in a specific format, and 'search_width' with its default value and meaning ('time range on either side to find price data'). This compensates well for the schema's lack of descriptions, though it doesn't detail all possible formats or constraints.
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 the tool's purpose: 'Get historical prices of tokens by contract address.' It specifies the verb ('Get'), resource ('historical prices'), and target ('tokens by contract address'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'get_current_prices' or 'get_batch_historical_prices', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings such as 'get_current_prices' for real-time data or 'get_batch_historical_prices' for multiple timestamps, nor does it specify prerequisites like required parameters or context. This lack of usage context leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is a GET endpoint for listing data, implying it's a read-only operation, but doesn't clarify permissions, rate limits, response format, or pagination. For a tool with zero annotation coverage, this is insufficient to ensure safe and effective use.
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 appropriately sized and front-loaded, starting with the HTTP method and endpoint, followed by the core purpose, then parameter details. Each sentence adds value without redundancy. It could be slightly more structured by separating the purpose from parameters with a line break, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters adequately, but lacks behavioral context like error handling or response structure. The presence of an output schema mitigates some gaps, but without annotations, more guidance on usage and safety would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains all three parameters: 'exclude_total_data_chart' and 'exclude_total_data_chart_breakdown' control chart exclusions, and 'data_type' specifies the desired data type with its default. This compensates well for the schema's lack of descriptions, though it doesn't detail the enum values beyond the default.
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 the tool's purpose: 'List all options dexs along with summaries of their volumes and dataType history data.' It specifies the verb ('List'), resource ('options dexs'), and scope ('summaries of their volumes and dataType history data'). However, it doesn't explicitly differentiate from sibling tools like 'get_options_overview_by_chain' or 'get_options_summary', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_options_overview_by_chain' or 'get_options_summary', nor does it specify any prerequisites, exclusions, or contextual cues for usage. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions retrieving historical data but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or pagination. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by parameter details. It's efficient with minimal waste, though the structure is simple and could be more polished for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema, the description is adequate but incomplete. It explains the parameter but lacks behavioral context, and the output schema reduces the need to describe return values, though more operational details would help.
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 0%, but the description compensates by explaining the 'protocol' parameter as a slug with an example ('aave'). This adds meaningful semantics beyond the bare schema, though it's brief and could be more detailed.
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 the tool retrieves historical TVL data with breakdowns by token and chain for a specific protocol. It specifies the verb (GET/retrieve) and resource (protocol details), though it doesn't explicitly differentiate from sibling tools like 'get_protocol_tvl' or 'get_protocols'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'get_protocol_tvl' and 'get_protocols', the description lacks context about use cases, prerequisites, or comparisons, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists data (implying a read operation) but doesn't cover critical aspects like rate limits, authentication needs, error handling, or response format. For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is appropriately sized and front-loaded, starting with the API endpoint and a clear purpose statement. The parameter explanations are concise and directly relevant. There's no wasted text, though it could be slightly more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and the description compensates for the 0% schema coverage with parameter semantics, the description is adequate but incomplete. It lacks behavioral details (e.g., rate limits, auth) and usage guidelines, which are important for a tool with no annotations and multiple siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'protocol' is a 'protocol slug' with an example ('compound-v3') and 'timestamp' is a 'unix timestamp' with an example (1700006400). This clarifies the parameter formats, compensating well for the schema's lack of descriptions.
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 the tool's purpose: 'Lists the amount of inflows and outflows for a protocol at a given date.' It specifies the verb ('Lists') and resource ('inflows and outflows for a protocol'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_protocol_details' or 'get_protocol_tvl', which might also provide protocol-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools such as 'get_protocol_details' or 'get_protocol_tvl', leaving the agent to infer usage context from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool lists protocols with TVL but doesn't cover critical aspects like whether it's a read-only operation, potential rate limits, authentication needs, pagination behavior, or data freshness. This leaves significant gaps for a tool that likely fetches financial data.
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 efficiently structured in two sentences: the first provides the API endpoint, and the second explains the functionality. There's no wasted text, though it could be slightly more polished by combining the sentences for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and 0 parameters with full schema coverage, the description's main job is purpose clarification. It does this adequately but lacks behavioral context (especially important with no annotations) and usage guidance relative to siblings, making it minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the input requirements. The description appropriately doesn't add parameter information, maintaining focus on the tool's purpose. A baseline of 4 is appropriate for zero-parameter tools.
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 the tool's purpose with a specific verb ('List') and resource ('protocols on defillama'), and includes the additional output detail ('along with their tvl'). However, it doesn't explicitly differentiate from sibling tools like 'get_protocol_details' or 'get_protocol_tvl', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_protocol_details' for specific protocol information or 'get_protocol_tvl' for TVL-focused queries, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool gets 'current TVL,' implying a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication needs, data freshness, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear parameter explanation. There's no wasted text, and the structure is logical. It could be slightly more polished but efficiently conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and a simple purpose, it lacks context on usage guidelines and behavioral traits, making it incomplete for optimal agent 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?
The description adds meaningful semantics beyond the input schema. The schema has 0% description coverage (only a title 'Protocol'), but the description explains that the 'protocol' parameter is a 'protocol slug' and provides an example ('uniswap'). This clarifies the expected format and usage, compensating well for the low schema coverage.
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 the tool's purpose: 'Simplified endpoint to get current TVL of a protocol.' It specifies the verb ('get'), resource ('current TVL'), and target ('protocol'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_historical_chain_tvl' or 'get_protocol_details', which might offer overlapping or related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions it's a 'simplified endpoint,' but doesn't clarify what that means in practice or when to choose it over other TVL-related tools in the sibling list. There are no explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool lists stablecoins with circulating amounts and includes an optional price parameter, but doesn't describe critical behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, response format, or pagination. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 appropriately concise with three sentences: the endpoint, core functionality, and parameter explanation. It's front-loaded with the main purpose, and every sentence adds value without redundancy. The structure is clear, though it could be slightly more polished by integrating the parameter explanation more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and only one parameter with good description coverage, the description is minimally adequate. However, it lacks behavioral context (e.g., read-only nature, potential limitations) that would be important for a tool fetching financial data. It's complete enough for basic use but misses operational 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?
The description adds meaningful context for the single parameter: 'include_prices: whether to include current stablecoin prices (default: True)'. This explains the parameter's purpose and default value, which is valuable since schema description coverage is 0% (the schema only provides a title and type). The description fully compensates for the lack of schema documentation for this parameter.
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 the tool's purpose: 'List all stablecoins along with their circulating amounts.' This specifies the verb ('List'), resource ('stablecoins'), and key output information ('circulating amounts'). It distinguishes from siblings like 'get_stablecoin_prices' by focusing on comprehensive listing rather than price-specific queries, though it doesn't explicitly contrast with all stablecoin-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_stablecoin_prices' (which might fetch only prices) or 'get_stablecoin_charts_all' (which might provide chart data), leaving the agent to infer usage from tool names alone. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('lists') but doesn't describe key traits like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or the format of returned data. While it implies a safe read operation, the absence of detailed behavioral context is a significant gap.
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 appropriately sized and front-loaded, starting with the core purpose followed by parameter details. It uses two sentences with no wasted words, making it efficient. However, the structure could be slightly improved by integrating the parameter explanation more seamlessly, but it remains clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema, the description is moderately complete. It covers the purpose and parameter semantics adequately, but lacks behavioral details and usage guidelines. With no annotations and minimal context, it meets basic needs but leaves gaps in operational 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?
The description adds meaningful semantics beyond the input schema, which has 0% coverage. It explains that the 'symbol' parameter is a 'token slug' and provides an example ('usdt'), clarifying the expected format. Since there's only one parameter and the schema lacks descriptions, this compensation is effective, though it could be more detailed (e.g., explaining slug conventions).
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 the tool's purpose: 'Lists the amount of a certain token within all protocols.' It specifies the verb ('lists'), resource ('amount of a certain token'), and scope ('within all protocols'), providing a concrete action. However, it doesn't explicitly differentiate from sibling tools like 'get_stablecoins' or 'get_chain_assets', which might also involve token data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools (e.g., 'get_protocols' or 'get_stablecoin_charts_all'), leaving the agent to infer usage based on the name and description alone. This lack of explicit context reduces its effectiveness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists protocols but does not describe any behavioral traits such as rate limits, authentication needs, pagination, or response format. This leaves significant gaps in understanding how the tool operates beyond its basic purpose.
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 concise and front-loaded, consisting of two sentences that directly state the tool's purpose. There is no wasted text, and it efficiently communicates the essential information. However, the inclusion of the API endpoint ('GET /api/treasuries') is slightly redundant but not detrimental to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, an output schema exists, and no annotations are provided, the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects and usage context. With the output schema handling return values, the description is complete enough for basic understanding but could be more informative.
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 with 100% coverage, meaning no parameters are documented. The description does not add parameter information, which is acceptable since there are no parameters to explain. It meets the baseline for tools with zero parameters, though it doesn't compensate for any gaps (as there are none).
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 the tool's purpose: 'List all protocols on our Treasuries dashboard.' It specifies the verb ('List') and resource ('protocols on our Treasuries dashboard'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools (e.g., 'get_protocols'), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools like 'get_protocols' or 'get_protocol_details' that might serve similar purposes. This lack of usage instructions limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool performs a GET operation (implying read-only) and specifies the data returned, but lacks details on behavioral traits like rate limits, authentication needs, pagination, error handling, or data freshness. For a tool with zero annotation coverage, this is a significant gap in 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 concise and front-loaded, consisting of two sentences that directly state the tool's purpose and scope. There's no wasted text, though it could be slightly more structured by explicitly separating the HTTP method from the data 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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a read operation with no annotations, it lacks completeness in areas like behavioral context (e.g., rate limits, data sources) and doesn't leverage the output schema to hint at return structure, leaving room for improvement.
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 with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate given the schema completeness. A baseline of 4 is assigned as the description doesn't need to compensate for any parameter gaps.
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 the tool retrieves 'Funding rates and Open Interest of perps across exchanges, including both Decentralized and Centralized.' It specifies the resource (perps) and data types (funding rates, open interest) with scope (across exchanges). However, it doesn't explicitly differentiate from sibling tools like get_derivatives_overview or get_derivatives_summary, which might cover similar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as get_derivatives_overview or get_yield_chart, leaving the agent to infer usage context solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is a GET operation (implying read-only) and describes the basic functionality, but lacks critical details like rate limits, authentication requirements, error handling, or response format. For a tool with no annotations, this is insufficient.
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 efficiently structured: a clear purpose statement followed by parameter explanations. Every sentence adds value without redundancy. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters with nested objects), no annotations, and an output schema (which reduces the need to describe return values), the description is moderately complete. It covers parameters well but lacks behavioral context like rate limits or error handling. The presence of an output schema helps, but more disclosure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'coins' parameter structure ('dict where keys are coins in format {chain}:{address} and values are arrays of timestamps') and clarifies the 'search_width' default and purpose. This compensates well for the schema's lack of documentation.
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 the tool's purpose: 'Get historical prices for multiple tokens at multiple different timestamps.' It specifies the verb ('Get'), resource ('historical prices'), and scope ('multiple tokens at multiple different timestamps'). However, it doesn't explicitly differentiate from sibling tools like 'get_historical_prices' or 'get_current_prices', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_historical_prices' (which appears to fetch prices for a single token) or 'get_current_prices', nor does it specify prerequisites or exclusions. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') and data type ('current TVL of all chains'), but lacks details on permissions, rate limits, data freshness, pagination, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency about how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the HTTP method and endpoint ('GET /api/v2/chains') followed by the core purpose in a single sentence. There is zero waste or redundancy, making it easy to parse quickly. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the purpose is simple (fetching current TVL), the description is minimally adequate. However, with no annotations and sibling tools that might overlap (e.g., historical TVL tools), it lacks context on data scope, freshness, or differentiation. The output schema will handle return values, but the description doesn't fully compensate for the missing behavioral context.
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 with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline score of 4 is given because the tool has no parameters, and the description correctly avoids unnecessary parameter explanations.
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 the tool's purpose: 'Get current TVL of all chains.' It specifies the verb ('Get') and resource ('TVL of all chains'), making the function unambiguous. However, it doesn't differentiate this from sibling tools like 'get_historical_chain_tvl' or 'get_historical_chain_tvl_by_chain', which likely provide similar TVL data but with different scopes or timeframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'current TVL' but doesn't clarify if this is real-time data, daily snapshots, or how it differs from historical TVL tools in the sibling list. There are no explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'Historical AUM' but doesn't specify time ranges, data granularity, authentication needs, rate limits, or response format. The HTTP method 'GET' implies read-only, but this isn't explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with three short lines: endpoint, purpose, and scope. Every sentence is essential, front-loading the key information without any wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and an output schema exists, the description is minimally adequate. However, for a data retrieval tool with no annotations, it lacks context on data format, time periods, or usage constraints, leaving gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate given the empty schema, earning a baseline score above minimum viable.
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 the tool retrieves historical AUM (Assets Under Management) data for ETH ETFs, with a specific verb ('GET') and resource ('/etfs/historyEth'). It distinguishes from sibling 'get_etf_history' by specifying 'Eth' scope, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_etf_history' or 'get_etf_overview_eth' is provided. The description only states what it does, not when it's appropriate or what distinguishes it from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the HTTP method (GET) and data exclusions (liquid staking and double counted TVL), but lacks details on rate limits, authentication needs, response format, pagination, or error handling. For a data-fetching tool, this is a significant gap in transparency.
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 highly concise and front-loaded: it starts with the HTTP endpoint, then directly states the purpose in a single sentence. There is no wasted text, and every element (method, resource, exclusions) serves a clear purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (historical data fetching), no annotations, and an output schema present, the description is minimally adequate. It covers the core purpose and exclusions but lacks behavioral context (e.g., data freshness, limitations). The output schema reduces the need to explain return values, but more guidance on usage and constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. However, it could have mentioned implicit parameters like date ranges or filters if applicable, but given the schema, a baseline of 4 is justified.
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 the tool's purpose: 'Get historical TVL (excludes liquid staking and double counted tvl) of DeFi on all chains.' It specifies the action (GET), resource (historical TVL), and scope (all chains, with exclusions). However, it doesn't explicitly differentiate from sibling tools like 'get_historical_chain_tvl_by_chain' or 'get_protocol_tvl', which might handle similar data differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_historical_chain_tvl_by_chain' (which might filter by chain) or 'get_protocol_tvl' (which might focus on protocols), leaving the agent to infer usage based on names alone. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions it's a GET operation (implying read-only) and returns an 'overview,' but doesn't specify what 'overview' entails (e.g., list format, pagination, rate limits, authentication needs, or data freshness). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 extremely concise and front-loaded: it states the HTTP method, endpoint, and purpose in just two short sentences. There's no wasted text, and every word contributes directly to understanding the tool's basic function. This is an example of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and many sibling tools, it lacks context about when to use it, what the output contains, or any behavioral constraints. The description meets the bare minimum but doesn't provide enough guidance for optimal agent use in a crowded toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema is fully described). The description doesn't need to explain parameters, and it correctly implies no inputs are required. A baseline of 4 is appropriate for a parameterless tool where the schema already covers everything.
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 the tool's purpose: 'Overview of all oracles across all protocols.' It specifies the verb ('GET') and resource ('oracles'), and the scope ('all oracles across all protocols') is explicit. However, it doesn't distinguish this tool from its many sibling 'get_' tools, which all follow a similar naming pattern for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 65+ sibling tools (e.g., get_protocols, get_chains, get_stablecoins), there's no indication of how this tool relates to them or when an agent should choose it over other data retrieval options. The description merely states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a GET operation, implying it's likely read-only, but doesn't confirm if it's safe or has any side effects. It also doesn't mention rate limits, authentication needs, or what the output looks like (though an output schema exists, which helps). For a tool with no annotations, this is a significant gap in transparency.
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: it starts with the HTTP method and endpoint, states the purpose clearly, and lists parameters with brief explanations. Every sentence earns its place, with no redundant information, making it easy to parse quickly.
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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose, parameter semantics, and a hint on usage. However, it lacks behavioral details like safety or rate limits, which would be beneficial since no annotations are provided, keeping it from a perfect score.
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 description adds meaningful context for the single parameter: 'id: bridge ID (can be retrieved from /bridges)'. This clarifies what 'id' represents and how to obtain it, which is valuable since the input schema has 0% description coverage (only providing type and title). With one parameter, this compensation is sufficient to score highly, though it doesn't detail format constraints beyond being an integer.
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 the tool's purpose: 'Get summary of bridge volume and volume breakdown by chain.' This specifies the verb ('Get'), resource ('bridge'), and what information is retrieved ('summary of bridge volume and volume breakdown by chain'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_bridge_volume' or 'get_bridge_day_stats', which might offer similar or overlapping data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions that the 'id' parameter 'can be retrieved from /bridges', which hints at a prerequisite but doesn't specify when to use this tool versus alternatives. There's no explicit guidance on when to choose this over sibling tools like 'get_bridge_volume' or 'get_bridge_transactions', leaving the agent to infer based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the 'limit' parameter has a maximum of 6000, which is useful context. However, it doesn't describe other important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or error conditions. For a tool with 6 parameters and no annotations, this is a significant gap.
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 and appropriately sized. It starts with the HTTP method and endpoint, states the purpose clearly, then lists all parameters with helpful explanations. Every sentence earns its place, though it could be slightly more concise by combining some parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and the description provides good parameter semantics, the description is reasonably complete. However, for a tool with 6 parameters and no annotations, it should ideally include more behavioral context about how the tool actually works, error handling, and performance characteristics to be fully complete.
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?
The description provides excellent parameter semantics beyond the input schema. With 0% schema description coverage, the description fully compensates by explaining all 6 parameters: what 'id' represents and where to get it, that timestamps are Unix format, examples for 'source_chain' and 'address' formats, and the maximum value for 'limit'. This adds substantial value beyond the bare 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 the tool's purpose: 'Get all transactions for a bridge within a date range.' This specifies the verb ('Get'), resource ('transactions'), and scope ('bridge within a date range'). However, it doesn't explicitly differentiate from sibling tools like 'get_bridge_day_stats' or 'get_bridge_volume', which might provide related but different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that the 'id' parameter can be retrieved from '/bridges', but doesn't specify when to use this tool versus alternatives like 'get_bridge_day_stats' or 'get_bridge_volume'. No explicit when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions the tool lists derivatives with volume summaries filtered by chain, it doesn't describe important behavioral aspects: whether this is a read-only operation, what permissions might be needed, how results are formatted, whether there are rate limits, or what the output contains beyond the chart exclusion parameters. The description provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that each serve a purpose: stating the endpoint, explaining the tool's function, and detailing parameters. It's front-loaded with the core functionality. While efficient, the inclusion of the endpoint path 'GET /api/overview/derivatives' might be slightly redundant if the tool name already conveys this information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values), 0 required parameters, and only 2 boolean parameters, the description is reasonably complete for this level of complexity. However, as a data retrieval tool with no annotations, it should ideally mention that this is a read-only operation and provide more context about the filtering mechanism ('by chain'). The parameter explanations are strong, but overall behavioral context is lacking.
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?
The description provides excellent parameter semantics despite 0% schema description coverage. It clearly explains both parameters: 'exclude_total_data_chart: true to exclude aggregated chart from response' and 'exclude_total_data_chart_breakdown: true to exclude broken down chart from response.' This adds crucial meaning beyond the schema's bare boolean types and titles, explaining what these parameters actually control in the response.
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 the tool's purpose: 'Lists all derivatives along summaries of their volumes filtering by chain.' This specifies the verb (lists), resource (derivatives), and scope (summaries of volumes filtered by chain). However, it doesn't explicitly differentiate from sibling tools like 'get_derivatives_summary' or 'get_options_overview', which appear to be related derivatives/options tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_derivatives_summary' and 'get_options_overview' available, there's no indication of how this tool differs or when it should be preferred. The mention of 'filtering by chain' might imply some context, but no explicit usage instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool fetches price data at intervals, but lacks critical details: it doesn't specify if this is a read-only operation (implied by 'GET' but not explicit), what the output format is (though an output schema exists), rate limits, authentication needs, or error handling. For a data-fetching tool with 6 parameters, this leaves significant gaps in understanding its 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?
The description is well-structured and appropriately sized. It starts with the purpose, lists parameters with clear explanations, and uses bullet-like formatting for readability. Every sentence adds value, with no redundant information. It could be slightly more concise by integrating the purpose into the parameter list, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations), the description does a decent job but has gaps. It fully documents parameters, which is crucial with 0% schema coverage, and an output schema exists to handle return values. However, it lacks behavioral context like rate limits or error scenarios, and doesn't differentiate from sibling tools, leaving the agent to guess when to use it. This is adequate but not comprehensive.
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?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains all 6 parameters in detail: 'coins' as 'comma-separated tokens in format {chain}:{address}', 'start' and 'end' as Unix timestamps, 'span' as 'number of data points returned', and default values for 'period' and 'search_width'. This fully compensates for the schema's lack of descriptions, making parameter usage clear.
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 the tool's purpose: 'Get token prices at regular time intervals.' This specifies the verb ('Get') and resource ('token prices'), and the URL path '/coins/chart/{coins}' reinforces it's about price charts for tokens. However, it doesn't explicitly differentiate from sibling tools like 'get_current_prices' or 'get_historical_prices', which might offer similar data in different formats or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_current_prices' (for real-time prices) or 'get_historical_prices' (which might serve a similar purpose), nor does it specify prerequisites or exclusions (e.g., time range constraints). The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a GET operation for historical data, implying read-only behavior, but doesn't disclose other traits like rate limits, authentication needs, error handling, or what 'historical' entails (e.g., time range, granularity). The description is minimal and lacks behavioral details beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the endpoint and core purpose. The two sentences are efficient, with no wasted words. However, the structure could be slightly improved by integrating the parameter note more seamlessly, but it remains clear and concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) and no annotations, the description is moderately complete. It covers the purpose and parameter semantics adequately but lacks behavioral transparency and usage guidelines relative to siblings. For a tool with historical data retrieval, more context on data scope and limitations would enhance 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 0%, so the description must compensate. It adds meaningful context for the single parameter 'pool', explaining it's a pool ID and can be retrieved from '/poolsBorrow'. This clarifies the parameter's purpose and source, though it doesn't detail format constraints (e.g., string pattern) or provide examples.
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 the tool's purpose: retrieving historical borrow cost APY from a specific pool on a lending market. It specifies the verb ('GET'), resource ('/yields/chartLendBorrow/{pool}'), and scope ('historical borrow cost APY'). However, it doesn't explicitly differentiate from sibling tools like 'get_yield_chart' or 'get_yield_pools_borrow', which appear related but have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning that the pool parameter can be retrieved from '/poolsBorrow', which suggests a prerequisite. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., 'get_yield_chart' or 'get_yield_pools_borrow'), nor does it specify exclusions or ideal scenarios for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieving 'latest data' and 'enriched information such as predictions,' which hints at read-only behavior and data freshness, but doesn't explicitly state whether this is a read operation, if it requires authentication, rate limits, or what the response format entails. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that efficiently convey the purpose and scope. Every word earns its place, with no redundant or unnecessary information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is reasonably complete. It specifies the resource (pools), data recency (latest), and enrichment (predictions), which provides good context. However, with no annotations, it could better address behavioral aspects like read-only nature or response format, though the output schema mitigates some of this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no filtering or arguments are required by stating it retrieves data for 'all pools.' This aligns well with the schema, earning a baseline 4 for zero-parameter tools.
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 the tool retrieves latest data for all pools with enriched information like predictions. It specifies the verb (retrieve), resource (pools), and scope (all pools with enriched data). However, it doesn't explicitly differentiate from sibling tools like get_yield_pools_borrow or get_yield_pools_old, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_yield_pools_borrow or get_yield_pools_old, nor does it specify any context or prerequisites for usage. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('List') but doesn't cover critical aspects like rate limits, authentication needs, error handling, or response format. While it hints at data filtering and exclusions, it lacks details on pagination, data freshness, or any side effects, leaving significant gaps for an AI agent.
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 appropriately sized and front-loaded, starting with the core purpose followed by parameter details. It uses bullet points for parameters, enhancing readability. However, the first sentence is slightly wordy ('summaries of their volumes and dataType history data'), and there's minor redundancy in parameter explanations, but overall it's efficient with zero 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?
Given the tool's complexity (4 parameters, 1 required), no annotations, and the presence of an output schema, the description does a good job. It covers the purpose and parameters thoroughly, and since an output schema exists, it doesn't need to explain return values. However, it lacks behavioral context like rate limits or error handling, which slightly reduces completeness for a tool with no annotations.
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?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'chain' is described with an example ('ethereum'), 'exclude_total_data_chart' and 'exclude_total_data_chart_breakdown' clarify what they exclude from the response, and 'data_type' specifies the default value and context. This compensates fully for the schema's lack of descriptions.
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 the tool's purpose: 'List all options dexs along with summaries of their volumes and dataType history data filtering by chain.' It specifies the verb ('List'), resource ('options dexs'), and scope ('filtering by chain'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_options_overview' or 'get_options_summary', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions filtering by chain but doesn't compare to sibling tools such as 'get_options_overview' (which might not filter by chain) or 'get_options_summary' (which might provide different data). There's no mention of prerequisites, exclusions, or specific contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is a GET operation and describes parameters, but lacks critical behavioral details: it doesn't specify authentication needs, rate limits, error conditions, or what the output contains (though an output schema exists). For a tool with no annotations, this is insufficient to understand its operational 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?
The description is well-structured and appropriately sized. It starts with the endpoint and a clear purpose statement, followed by a bullet-point list of parameters with explanations. Each sentence earns its place, but it could be slightly more concise by integrating the endpoint into the purpose statement.
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 moderate complexity (4 parameters, 1 required) and the presence of an output schema, the description is reasonably complete. It covers the purpose and parameters in detail, which addresses the main gaps. However, it lacks usage guidelines and behavioral context, which are important for a tool with no annotations, preventing a perfect score.
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?
The description adds significant value beyond the input schema, which has 0% schema description coverage. It explains the format for 'coins' ('comma-separated tokens in format {chain}:{address}'), clarifies 'timestamp' as 'timestamp of data point (defaults to now)', defines 'look_forward' as 'whether to look forward from timestamp (default: False)', and specifies 'period' as 'duration between data points (default: '24h')'. This fully compensates for the schema's lack of descriptions.
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 the tool's purpose: 'Get percentage change in price over time.' This specifies the verb ('get'), resource ('percentage change in price'), and scope ('over time'), making it distinct from sibling tools like get_current_prices or get_historical_prices. However, it doesn't explicitly differentiate from all siblings, such as get_fdv_performance, which might also involve price-related metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_price_chart or get_historical_prices, nor does it specify use cases, prerequisites, or exclusions. This leaves the agent without context for tool selection among the many price-related options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving historical data (APY and TVL), which suggests a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, data freshness, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is concise and well-structured: it starts with the HTTP method and endpoint, states the purpose in a clear sentence, and lists parameters with brief explanations. There's no wasted text, and the information is front-loaded, making it easy to scan. It could be slightly more polished but is efficient overall.
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 (simple retrieval with one parameter), the description covers the essential purpose and parameter semantics adequately. The presence of an output schema means the description doesn't need to explain return values, and the lack of annotations is partially offset by the clear read-only implication. However, more behavioral details would enhance completeness for a tool with no annotations.
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 description adds meaningful context for the single parameter 'pool', explaining it's a 'pool id (can be retrieved from /pools)'. This clarifies the parameter's purpose and source, which is valuable since the schema description coverage is 0% (the schema only provides a title 'Pool' without explanation). The description compensates well for the schema's lack of detail.
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 the tool's purpose: 'Get historical APY and TVL of a pool.' It specifies the verb ('Get') and resources ('historical APY and TVL of a pool'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_yield_chart_lend_borrow' or 'get_yield_pools', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning that the pool ID 'can be retrieved from /pools', which implies a prerequisite. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_yield_chart_lend_borrow' or 'get_yield_pools', nor does it specify any exclusions or conditions for use. The guidance is implied but not comprehensive.
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:

[![crypto-mcp-beta MCP server](https://glama.ai/mcp/servers/0xReisearch/crypto-mcp-beta/badges/card.svg)](https://glama.ai/mcp/servers/0xReisearch/crypto-mcp-beta)

Score Badge

Copy to your README.md:

[![crypto-mcp-beta MCP server](https://glama.ai/mcp/servers/0xReisearch/crypto-mcp-beta/badges/score.svg)](https://glama.ai/mcp/servers/0xReisearch/crypto-mcp-beta)

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/0xReisearch/crypto-mcp-beta'

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