@gblin-protocol/mcp-server

invest_usdc_to_gblin

Read-onlyIdempotent

Invest surplus USDC into GBLIN when idle balance exceeds operating needs. Generates approve and buy calldata to mint managed crypto exposure at NAV, redeemable via USDC swap.

Instructions

When your agent's idle USDC exceeds operating needs (rule of thumb: more than 7x daily burn), call this to park the SURPLUS into GBLIN — managed crypto exposure minted at NAV, redeemable any time via swap_gblin_to_usdc_jit. Returns two steps of calldata: (1) approve USDC to the GBLIN Zap, (2) GBLINZap.buyGBLINWithToken, which swaps the USDC to WETH on Uniswap V3 and mints at NAV with a non-zero minimum output. Free to call. The mint fee and the yearly management fee are governance parameters: read them live from get_treasury_state rather than from this text.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`usdc_amount`	Yes	USDC amount to invest (decimal string).
`wallet_address`	Yes	User's wallet address that holds the USDC and signs the transactions.

Output Schema

TableJSON Schema

Name	Required	Description
`steps`	Yes	Transactions to send in order.
`action`	Yes	Always sequential_txs: send the steps one after the other.
`expected`	Yes	Shares expected and the minimum applied.
`gas_hint`	Yes	Gas limit to set on the Zap step.
`security`	No
`gas_hint_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.5Oct 1, 2026

addedInput schema / properties / wallet_address

Added value: +{
+  "description": "User's wallet address that holds the USDC and signs the transactions.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "usdc_amount"
-]New value: +[
+  "usdc_amount",
+  "wallet_address"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "action": {
+      "description": "Always sequential_txs: send the steps one after the other.",
+      "type": "string"
+    },
+    "expected": {
+      "description": "Shares expected and the minimum applied.",
+      "type": "object"
+    },
+    "gas_hint": {
+      "description": "Gas limit to set on the Zap step.",
+      "type": "number"
+    },
+    "gas_hint_note": {
+      "type": "string"
+    },
+    "security": {
+      "type": "object"
+    },
+    "steps": {
+      "description": "Transactions to send in order.",
+      "items": {
+        "description": "One transaction to send, in order: target, calldata, value in wei, and gas when the step needs an explicit limit. The same call is repeated as to, data and chainId (8453) for wallet batch APIs such as send_calls.",
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "action",
+    "steps",
+    "expected",
+    "gas_hint"
+  ],
+  "type": "object"
+}

First observedv1.1.2May 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations: it discloses that the call is free, that it returns two calldata steps (approve + buyGBLINWithToken), that the swap routes through Uniswap V3, that minting happens at NAV with a non-zero minimum output, and that fees are live governance parameters rather than fixed text. There is mild tension with readOnlyHint=true given the returned calldata approves and mints, but the tool itself only constructs calldata and does not execute or mutate state, so this reads as preparation rather than an outright contradiction. Auth/permission requirements are not stated.

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?

Front-loaded with the decision rule, then the mechanism, then the return shape, then the fee caveat — logical order with no filler. It is on the longer side for a two-parameter tool, but each sentence carries distinct operational information (threshold, reverse path, calldata steps, fee source).

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?

With an output schema present, the description need not document return values, yet it still sketches the two calldata steps. Combined with annotations covering safety and the schema covering both parameters, an agent has everything needed to decide and invoke correctly; the fee pointer to get_treasury_state closes the last gap.

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

Parameters3/5

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

Schema coverage is 100%, so usdc_amount and wallet_address are already fully documented by the schema. The description reinforces context (surplus, wallet that holds USDC and signs) but adds no format, bounds, or unit detail beyond what the schema provides. Baseline 3 applies when the schema carries the parameter burden.

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?

States a specific verb+resource (park surplus USDC into GBLIN) and immediately distinguishes itself from siblings by naming swap_gblin_to_usdc_jit as the reverse path and get_treasury_state for fee data. The agent can tell exactly what this tool does without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger condition with a concrete threshold ('idle USDC exceeds operating needs — rule of thumb: more than 7x daily burn'), restricts scope to SURPLUS only, and names the escape hatch (redeemable any time via swap_gblin_to_usdc_jit). When-to-use and the alternative are both spelled out.

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