@gblin-protocol/mcp-server

get_treasury_state

Read-onlyIdempotent

Read the current GBLIN protocol state on Base mainnet to check NAV, basket weights, and Crash Shield status before any swap so you know price and risk regime.

Instructions

Read the current GBLIN protocol state on Base mainnet: NAV in USD, basket composition with dynamic weights, and Crash Shield status. Use this BEFORE any swap to know the current price and risk regime.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	No
`basket`	Yes	Assets in the basket with base and dynamic weights.
`nav_usd`	Yes	Net asset value of one GBLIN share in USD.
`auction_open`	Yes	True while a rebalancing auction is running.
`nav_reliable`	Yes	False when a price feed is stale or a basket asset cannot be read; do not trade on the NAV then.
`eth_price_usd`	Yes	ETH price in USD from the oracle.
`slippage_reason`	No
`crash_shield_active`	Yes	True when the crash shield has cut the weight of a falling asset.
`slippage_buffer_pct`	No
`management_fee_bps_per_year`	Yes	Management fee in basis points per year, read from the contract.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.5Oct 1, 2026

addedInput schema / required
```
Added value: +[]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "auction_open": {
+      "description": "True while a rebalancing auction is running.",
+      "type": "boolean"
+    },
+    "basket": {
+      "description": "Assets in the basket with base and dynamic weights.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "crash_shield_active": {
+      "description": "True when the crash shield has cut the weight of a falling asset.",
+      "type": "boolean"
+    },
+    "eth_price_usd": {
+      "description": "ETH price in USD from the oracle.",
+      "type": "number"
+    },
+    "management_fee_bps_per_year": {
+      "description": "Management fee in basis points per year, read from the contract.",
+      "type": "number"
+    },
+    "meta": {
+      "type": "object"
+    },
+    "nav_reliable": {
+      "description": "False when a price feed is stale or a basket asset cannot be read; do not trade on the NAV then.",
+      "type": "boolean"
+    },
+    "nav_usd": {
+      "description": "Net asset value of one GBLIN share in USD.",
+      "type": "number"
+    },
+    "slippage_buffer_pct": {
+      "type": "number"
+    },
+    "slippage_reason": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "nav_usd",
+    "eth_price_usd",
+    "nav_reliable",
+    "management_fee_bps_per_year",
+    "auction_open",
+    "crash_shield_active",
+    "basket"
+  ],
+  "type": "object"
+}

First observedv1.1.2May 25, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real context beyond that: it reads live mainnet state and defines the three data domains returned, plus the pre-swap sequencing. It omits auth requirements and any freshness/latency caveats, keeping it at a 4 rather than a 5.

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

Conciseness5/5

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

Two sentences, zero filler. The returned fields are front-loaded and the usage constraint follows immediately, so an agent gets the payload and the trigger in the first read.

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

Completeness5/5

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

An output schema exists, so return-value explanation is technically not required, yet the description still summarizes the key outputs helpfully. With no parameters and annotations covering the safety profile, nothing an agent needs to call this correctly 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the schema needs compensation from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ("Read") plus specific resource ("GBLIN protocol state on Base mainnet"), and it enumerates the returned content: NAV in USD, basket composition with dynamic weights, and Crash Shield status. This clearly distinguishes it from sibling tools like analyze_treasury_health (analysis) and get_nav_history (historical series).

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

Usage Guidelines4/5

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

"Use this BEFORE any swap to know the current price and risk regime" gives an explicit trigger and sequencing constraint, which is actionable guidance. It does not, however, name the neighboring alternatives (analyze_treasury_health, get_market_risk_regime, get_nav_history) or state when NOT to use it, so it falls short of a full 5.

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