Skip to main content
Glama

buy_tvl_cronos

Paid. Cronos total value locked (TVL) in DeFi, live, with 1d/7d/30d change (DefiLlama data). $0.01 USDC on Base or Solana. No account, no API key. Failed calls not charged. URL https://southpow.media/v1/defillama/tvl/cronos.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "buy_tvl_cronos"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it declares the tool is paid ($0.01 USDC on Base or Solana), requires no account or API key, and — importantly — that failed calls are not charged. It omits the response shape and whether the 1d/7d/30d changes are percent or absolute, but for a zero-param read that is a modest 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?

It is dense and front-loaded: 'Paid' and the resource come first, then source, price, auth, and billing semantics, with the URL last. Nearly every clause earns its place, though the raw URL is arguably schema/metadata rather than description content.

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?

For a zero-parameter, no-output-schema read tool, the essentials an agent needs before spending money — cost, payment chain, auth, and failure billing — are all present. The only missing piece is what the returned values look like (field names, units), which matters only slightly here.

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 takes no parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies the call is self-contained (all inputs — chain, metrics — are baked into the endpoint).

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 names a specific resource (Cronos total value locked in DeFi) with a clear scope ('live, with 1d/7d/30d change') and a named data source (DefiLlama), which is enough to tell it apart from the many buy_tvl_* and buy_yields_* siblings. It falls just short of 5 because it never explicitly says how it differs from the closely named buy_yields_chain_cronos.

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?

Usage is implied by the specificity of the data ('Cronos TVL with 1d/7d/30d change'), so an agent can infer when the data fits. There is no explicit when-to-use/when-not guidance and no named alternative for related Cronos data; the $0.01 price is stated but not framed as a reason to prefer a cheaper sibling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources