AlphaGrowth

Project TVL history

project_tvl_history

Read-only

A crypto project's total value locked per day (USD, with its staking part) for up to 3650 days, and its TVL on each chain it runs on: the latest value and share, plus one point per day (at most 365 days back) with chain_history=yes. Chain projects carry their chain's TVL and no chain split. Free data from AlphaGrowth (alphagrowth.io).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "project_tvl_history"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Days of daily history, counting today.
`slug`	Yes	The project's slug; find it with find_projects.
`chain_history`	No	yes to add each chain's daily series over the same days.	no

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish a read-only, closed-world read, so the description's added context is the valuable part: the 3650-day cap, the distinct 365-day cap on chain series, the fact that chain projects return the chain's TVL with no split, and the free AlphaGrowth data source. This materially shapes expectations about results and limits beyond the annotations.

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

Conciseness3/5

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

It is compact, but the opening sentence is a dense run-on that stacks three separate facts (main series, per-chain snapshot, per-chain series) without structural separation. Front-loading the resource is good; readability suffers from the packing.

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?

With only three parameters, full schema coverage, no output schema, and annotations covering safety, the description supplies the remaining essentials: what values are returned (USD TVL with staking component, latest value and share per chain), the time limits, and the chain-project special case. Only a concrete note on output shape/pagination behaviour is missing.

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?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds real meaning: it clarifies what 'days' counts toward and that chain_history produces a per-day series capped at 365 days back. That cap is not stated in the schema (which says 'over the same days'), so the description resolves an ambiguity the schema leaves open.

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 and verb: daily TVL history for a crypto project, plus per-chain TVL snapshots and series. It is clear enough that an agent can separate it from a metrics or ranking tool, though it never names a sibling (e.g. chain_metrics, project_metrics) to draw the boundary explicitly.

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 only implied: chain_history=yes is explained as the way to get per-chain daily series, and chain-native projects are noted as an edge case. There is no explicit 'use this instead of X' statement nor any stated prerequisite beyond the slug reference to find_projects.

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

All AlphaGrowth tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?