onchain-activity-index

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

With no annotations provided, the description carries the full disclosure burden. It transparently states the tool's nature (quantitative, descriptive, based on trend/diversification/scale data), explicitly disclaims any predictive or advisory capability, and discloses that the MCP tool is free while the REST equivalent is charged. This sets accurate expectations about output interpretation and cost.

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: the first sentence covers the core function and scope, the second adds important limitations, and the third clarifies cost. It is somewhat longer than necessary but every sentence adds value, and the key information is front-loaded. Slightly wordy but effective.

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 tool with a single simple parameter and no output schema or siblings, the description is thorough: it explains the metric's composition, its non-predictive nature, the input format with examples, and the cost difference between MCP and REST. An agent has everything needed to invoke it correctly without further clarification.

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 schema provides only a type and title for 'protocol_slug', with zero description coverage. The tool description compensates fully by explaining it expects a DefiLlama protocol slug and gives concrete examples ('uniswap', 'aave'). This is essential for correct invocation and could not be inferred from the schema alone.

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 clear verb ('Returns'), a specific resource ('DeFi Protocol Activity Index'), and the exact input type (a DefiLlama protocol slug), with concrete examples ('uniswap', 'aave'). It also specifies the output range (0-100), leaving no ambiguity about what the tool does.

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

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

While there are no sibling tools to differentiate against, the description provides clear when-to-use context by stating the index is a pure descriptive metric and explicitly not a trading signal or financial advice, thereby telling the agent when NOT to use it. It also notes the free MCP call vs a charged REST endpoint, giving practical usage context.

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