@gblin-protocol/mcp-server

analyze_treasury_health

Read-onlyIdempotent

Assess an agent wallet's treasury health: GBLIN/USDC/ETH balances, whether ETH covers exit gas, redemption cooldown, and USDC runway plus a spend-preserving recommendation from daily burn.

Instructions

Analyze an agent wallet's treasury health: GBLIN/USDC/ETH balances, whether the ETH covers an exit at the live gas price, the redemption cooldown, and (if daily_burn_usd is provided) days of USDC runway plus a recommendation that keeps seven days of spend in USDC and treats only the surplus as a candidate for GBLIN. Free by default; metered at $0.003 USDC only when the operator sets MCP_PAYWALL=true.

Input Schema

TableJSON Schema

Name	Required	Description
`_payment`	No	Base64-encoded x402 PaymentProof JSON. Omit on first call to receive the 402 payment manifest.
`daily_burn_usd`	No	Optional. Average daily spend in USD (e.g. 1.5).
`wallet_address`	Yes	Agent's 0x address.

Output Schema

TableJSON Schema

Name	Required	Description
`ratios`	No
`wallet`	Yes
`balances`	Yes
`cooldown`	Yes	Whether the redemption cooldown is active and for how long.
`gas_health`	Yes	Whether the wallet holds enough ETH for the next transactions.
`recommendation`	Yes	hold, rebalance_to_gblin or rebalance_to_usdc, with the reason.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.5Oct 1, 2026

addedInput schema / properties / _payment

Added value: +{
+  "description": "Base64-encoded x402 PaymentProof JSON. Omit on first call to receive the 402 payment manifest.",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "balances": {
+      "type": "object"
+    },
+    "cooldown": {
+      "description": "Whether the redemption cooldown is active and for how long.",
+      "type": "object"
+    },
+    "gas_health": {
+      "description": "Whether the wallet holds enough ETH for the next transactions.",
+      "type": "object"
+    },
+    "ratios": {
+      "type": "object"
+    },
+    "recommendation": {
+      "description": "hold, rebalance_to_gblin or rebalance_to_usdc, with the reason.",
+      "type": "object"
+    },
+    "wallet": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "wallet",
+    "balances",
+    "gas_health",
+    "cooldown",
+    "recommendation"
+  ],
+  "type": "object"
+}

First observedv1.1.2May 25, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: the analysis depends on live gas price, includes a redemption cooldown and a recommendation policy that reserves seven days of USDC spend and treats only surplus as GBLIN-eligible, plus a conditional cost model ($0.003 USDC only when MCP_PAYWALL=true). That pricing and the recommendation heuristic are real value-adds not present in structured fields.

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?

Two dense sentences, front-loaded with the core purpose and enumerating outputs in a single pass; the conditional cost model is placed last where it belongs. Every clause carries substance, though the first sentence is long and clause-heavy.

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 read-only analysis tool with a full output schema and 100% parameter coverage, the description supplies the computation semantics, the daily_burn_usd trigger, and the free/metered billing condition, which is nearly everything an agent needs before calling. The missing piece is explicit sibling differentiation, which is a contextual gap rather than a correctness one.

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 description coverage is 100%, so the baseline is 3. The description nevertheless adds meaning beyond the schema for daily_burn_usd: it explains that supplying it produces days-of-runway and a recommendation with the seven-day buffer rule, which is more than the schema's 'Optional. Average daily spend in USD'.

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 states a specific verb (analyze) and resource (treasury health) and enumerates the concrete outputs: GBLIN/USDC/ETH balances, ETH exit coverage at live gas price, redemption cooldown, and runway when daily_burn_usd is supplied. It is far from a tautology. It does not, however, name or contrast the closely related siblings get_treasury_state and plan_treasury, so an agent must infer the boundary itself.

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: passing daily_burn_usd is what unlocks runway and the recommendation, which suggests when to call it in a richer mode. There is no explicit statement of when to choose this over get_treasury_state or plan_treasury, and no exclusions. Adequate but leaves the sibling-routing decision to the agent.

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