sa-ecosystem-node

Treasury history

treasury_history

Read-onlyIdempotent

Retrieve historical treasury balances over time from cached snapshots, including DAO Treasury ATLAS end-of-day figures and replayed balances for other assets. Read-only; flags unpopulated cache.

Instructions

Balance over time from the same cache as the treasury flows. DAO Treasury ATLAS uses end-of-day snapshots. Other assets replay parsed balances. If the cache file is not in this deployment yet, the result says the cache is not yet populated and includes no figures. Read-only.

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": "treasury_history"
  }
}

Input Schema

Name	Required	Description
`to`	No
`from`	No
`mint`	No	ATLAS, USDC, or SOL.
`wallet`	No	dao_treasury, ecosystem_fund, or one of those two published addresses.
`granularity`	No
`allowPartial`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 4, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the description rightly spends its words elsewhere: it discloses the cache dependency, the empty-cache failure mode (message, no figures), and that ATLAS uses end-of-day snapshots while other assets replay parsed balances. The trailing 'Read-only' is redundant with readOnlyHint=true, and the response shape is not described.

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?

Four short sentences, front-loaded with the core purpose and cache relationship, then the empty-cache caveat. The closing 'Read-only' duplicates the annotations and could be dropped, but otherwise there is no filler.

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

Completeness3/5

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

For a 6-parameter, zero-required tool with no output schema, the description covers behavior and edge cases well but leaves four parameters unexplained and gives no sense of return shape (per-day rows? which asset fields?). Adequate but with real gaps an agent would hit on first call.

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

Parameters2/5

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

Schema coverage is only 33% — only mint and wallet have descriptions — so the description must carry the load for from, to, granularity, and allowPartial. It adds meaning only for mint (ATLAS snapshots vs other assets replaying parsed balances) and says nothing about date format constraints, granularity choice, or what allowPartial toggles.

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 lead phrase 'Balance over time' names the resource (balances) and its temporal shape (time series), and the reference to 'the same cache as the treasury flows' links it to dao_treasury_flows. It stops short of an explicit verb and never names treasury_balances as the alternative, so the split with that sibling is left to inference.

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?

'Balance over time' implies this is the time-series variant versus a point-in-time balance tool, and the shared-cache note hints at consistency with treasury_flows. But there is no explicit when-to-use, when-not-to-use, or named alternative, so an agent must guess between this and treasury_balances.

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