list_assetsReturns every asset dcamethod.com can backtest, with category, calculator URL and whether historical data is available. Optional category filter: crypto, stocks, commodities.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or side effects. It is a simple read operation, but the description lacks explicit transparency beyond the immediate action.
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?
Two sentences with no wasted words. The first sentence front-loads the purpose and returned fields. Highly efficient.
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?
Without an output schema, the description adequately lists what is returned (category, calculator URL, historical data flag). However, it does not mention pagination, ordering, or potential limits, making it slightly incomplete for a thorough understanding.
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 coverage is 100% with one optional enum parameter. The description adds context by naming the filter options, but the schema already enumerates 'crypto', 'stocks', 'commodities', so the added value is marginal.
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 returns every asset with specific fields (category, calculator URL, historical data availability). It distinguishes from siblings like 'get_method' and 'run_dca_backtest' which 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an optional category filter and implies usage for listing assets, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear, distinct purpose: explaining the method, listing assets, and running backtests. No functional overlap.
All tool names follow a consistent verb_noun pattern (get_method, list_assets, run_dca_backtest) with snake_case, making them predictable.
Three tools cover the essential needs for a DCA toolset: method description, asset discovery, and backtesting. The count is well-scoped without being too sparse or excessive.
The set covers core DCA operations, but lacks features like comparing multiple assets or customizing backtest parameters, which could be useful. Still, no critical gaps for basic usage.