getCryptoLoanCommonCollateralData

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

Annotations already mark the tool as readOnlyHint=true and openWorldHint=true, and the description adds useful behavioral context: it is a public endpoint with no authentication, has a rate limit of 1000 requests per time window, and can return either all collateral currencies or a filtered subset. This goes beyond the annotations and gives agents practical operational expectations.

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

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

The description is front-loaded with a clear one-sentence summary, followed by structured Features and Use Cases bullet lists. It is appropriately sized and readable, though there is some redundancy between the Features and Use Cases sections, such as repeating collateral ratio information.

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

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

For a low-complexity tool with one optional parameter, no output schema, and already-rich annotations, the description covers the key behavioral details: authentication, rate limit, filtering behavior, and the kind of data returned. It does not provide exact response structure or error scenarios, but those are not strongly required given the tool's simplicity.

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

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

Schema description coverage is 0%, but the single optional `currency` parameter is meaningfully explained: 'Query by specific currency or get all collateral currencies' tells the agent that omitting the parameter returns all currencies and supplying it filters to one. It does not specify the expected currency format (e.g., code vs. name), which prevents a 5.

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

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

The description states a specific verb and resource: 'Query information about currencies available as collateral in the crypto loan system.' It further clarifies the tool's scope by listing specific capabilities such as querying all collateral currencies, getting liquidation order, and retrieving tiered collateral ratios. It does not explicitly distinguish itself from overlapping siblings like getTieredCollateralRatio or getCollateralInfo, so it stops short of a 5.

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

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

The 'Use Cases' section gives clear practical guidance: checking collateral eligibility, viewing liquidation priority, getting collateral ratios, and understanding risk parameters before pledging assets. This is clear contextual usage guidance, but it does not mention when to choose this tool instead of alternatives or when not to use it, so it lacks explicit exclusion criteria.

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