getFundingRateHistory

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 that no authentication is required, explains the reverse chronological sorting, and mentions the funding settlement intervals. For a read-only query tool, this is transparent and sufficient. A higher score would require additional details like rate limits or pagination behavior, but these are not critical.

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 well-structured with clear sections, bullet points, and a hint at the end. It is appropriately sized for the tool's complexity. Some redundancy exists (e.g., 'Use this endpoint' and 'Agent hint' overlap), but overall it is concise and easy to parse.

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

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

Given the tool has 5 parameters and no output schema, the description covers the essential aspects: purpose, required parameters, time filtering, and alternative tools. It lacks details on return format or error handling, but these are not mandatory for a simple query tool. The description is complete enough for an AI agent to select and invoke correctly.

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

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

The description mentions 'category' and 'symbol' as required, and 'startTime' and 'endTime' for time filtering. However, it does not explain the 'limit' parameter or the enum values for 'category'. With schema coverage at 0%, the description should compensate more fully. The provided hints are helpful but incomplete.

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

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

The description clearly states the tool's purpose: 'Query historical funding rate records for perpetual contracts.' It specifies the supported products (USDT contract, Inverse contract) and how records are sorted (reverse chronological order). This distinguishes it from sibling tools like getTickers, which provides current funding rate.

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

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

The description explicitly lists use cases: analyze historical trends, calculate funding cost, compare rates. It also gives a clear 'Do not use' directive for current funding rate, directing users to getTickers instead. This provides excellent guidance on when to use this tool versus alternatives.

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