How do I use tydro-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tydro-mcp Check the supply APY for USDT0 on Tydro." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tydro-mcp

Official

by mavrkofficial

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

tydro-mcp

version license

The Tydro lending protocol MCP server — gives any MCP-compatible AI agent (Claude Code, Cursor, Claude Desktop, Windsurf, VS Code, OpenClaw, etc.) live read + write access to all 12 Tydro reserves on Ink. Tydro is an Aave V3 whitelabel, so everything you know about Aave V3 lending works here: supply, borrow, repay, withdraw, health factors, liquidation thresholds, variable-rate debt.

CAUTION

Experimental software. Interacts with the live Tydro lending pool on the Ink blockchain and can execute real financial transactions including supplies, borrows, repays, and withdrawals. Read theSecurity section before using with real funds or AI agents.

Related MCP server: mcp-server-justlend

Quick Start

1. Install (no manual install needed)

MCP clients resolve the package automatically via npx when you add it to your config — see MCP Client Setup below.

2. Fund a dedicated dev wallet

Do not use your main wallet private key with this MCP. Create a fresh EVM wallet, fund it with a small amount of ETH on Ink (just enough for gas + your test positions), and use that key only.

3. Add to your MCP client config

{
  "mcpServers": {
    "tydro": {
      "command": "npx",
      "args": ["tydro-mcp"],
      "env": {
        "PRIVATE_KEY": "0xYOUR_DEV_WALLET_PRIVATE_KEY"
      }
    }
  }
}

Restart your MCP client. 7 tools become available to your agent.

4. (Optional) Use a private RPC endpoint

If you have a private Ink RPC (Gelato, Alchemy, QuickNode, etc.), set TYDRO_RPC for faster reads and higher rate limits:

{
  "mcpServers": {
    "tydro": {
      "command": "npx",
      "args": ["tydro-mcp"],
      "env": {
        "PRIVATE_KEY": "0xYOUR_DEV_WALLET_PRIVATE_KEY",
        "TYDRO_RPC": "https://your-private-ink-rpc.example.com"
      }
    }
  }
}

Falls back to https://rpc-gel.inkonchain.com when unset.

Tool Catalog

7 tools across read-only and write operations. All target Ink mainnet (chain ID 57073).

Read-only — no private key required

Tool	Description
`get_reserve_data`	Live market data for any reserve: supply APY, borrow APY, total liquidity, total debt, available liquidity, utilization rate.
`get_user_account`	Full position overview for any wallet: collateral USD, debt USD, available borrow capacity, health factor, liquidation status, LTV, liquidation threshold.
`get_user_reserve`	Position in a specific reserve: amount supplied, variable debt, stable debt, collateral flag, current market APYs.

Write — requires `PRIVATE_KEY`

Tool	Description
`supply`	Deposit an asset to earn interest. ERC20 approval handled automatically.
`borrow`	Borrow against deposited collateral. Variable rate only (Aave V3 deprecated stable rate).
`repay`	Repay borrowed debt. Pass `"max"` to repay the full balance including accrued interest. Auto-approves.
`withdraw`	Withdraw supplied assets. Pass `"max"` for the full aToken balance.

`get_reserve_data`

Live market data for any reserve: supply APY, borrow APY, total liquidity, total debt, available liquidity, and utilization rate.

{ "asset": "WETH" }
{ "asset": "kBTC" }
{ "asset": "0x0200C29006150606B650577BBE7B6248F58470c1" }

Returns:

{
  "asset": "WETH",
  "supplyAPY": "2.14%",
  "variableBorrowAPY": "3.87%",
  "totalSupplied": "1482.33",
  "totalVariableDebt": "610.17",
  "availableLiquidity": "872.16",
  "utilizationRate": "41.17%",
  "lastUpdated": "2026-03-10T20:00:00.000Z"
}

`get_user_account`

Full position overview for any wallet: collateral value, debt, available borrow capacity, health factor, and liquidation status.

{ "address": "0xYourWalletAddress" }

Returns:

{
  "address": "0x...",
  "totalCollateral": "$4820.00",
  "totalDebt": "$1200.00",
  "availableToBorrow": "$1250.00",
  "healthFactor": "2.8731",
  "status": "✅ Healthy",
  "ltv": "80.00%",
  "liquidationThreshold": "82.50%"
}

`get_user_reserve`

Position in a specific reserve for any wallet: amount supplied, amount borrowed, collateral flag, and current market APYs.

{ "asset": "USDT0", "address": "0xYourWalletAddress" }

Returns:

{
  "asset": "USDT0",
  "supplied": "5000.00",
  "variableDebt": "0.00",
  "stableDebt": "0.00",
  "usedAsCollateral": true,
  "marketSupplyAPY": "4.21%",
  "marketVariableBorrowAPY": "6.83%",
  "activeBorrowType": "none"
}

`supply`

Deposit an asset into Tydro to earn interest. ERC20 approval is checked and submitted automatically if needed.

{ "asset": "WETH",  "amount": "1.5"  }
{ "asset": "USDT0", "amount": "5000" }
{ "asset": "kBTC",  "amount": "0.01" }

`borrow`

Borrow an asset against your deposited collateral. Variable rate only (stable rate deprecated in Aave V3).

{ "asset": "USDT0", "amount": "1000" }
{ "asset": "GHO",   "amount": "500"  }

`repay`

Repay borrowed assets. Pass "max" to repay the full debt balance including accrued interest. Auto-approves ERC20.

{ "asset": "USDT0", "amount": "500" }
{ "asset": "WETH",  "amount": "max" }

`withdraw`

Withdraw previously supplied assets. Pass "max" to withdraw your entire aToken balance.

{ "asset": "USDT0", "amount": "2000" }
{ "asset": "WETH",  "amount": "max"  }

Supported Assets

All 12 live Tydro reserves on Ink mainnet. Pass assets by symbol (WETH, USDT0) or raw contract address.

Symbol	Decimals	Contract Address
WETH	18	`0x4200000000000000000000000000000000000006`
kBTC	8	`0x73e0c0d45e048d25fc26fa3159b0aa04bfa4db98`
USDT0	6	`0x0200C29006150606B650577BBE7B6248F58470c1`
USDG	6	`0xe343167631d89b6ffc58b88d6b7fb0228795491d`
GHO	18	`0xfc421ad3c883bf9e7c4f42de845c4e4405799e73`
USDC	6	`0x2d270e6886d130d724215a266106e6832161eaed`
weETH	18	`0xa3d68b74bf0528fdd07263c60d6488749044914b`
wrsETH	18	`0x9f0a74a92287e323eb95c1cd9ecdbeb0e397cae4`
ezETH	18	`0x2416092f143378750bb29b79ed961ab195cceea5`
sUSDe	18	`0x211cc4dd073734da055fbf44a2b4667d5e5fe5d2`
USDe	18	`0x5d3a1ff2b6bab83b63cd9ad0787074081a52ef34`
SolvBTC	18	`0xae4efbc7736f963982aacb17efa37fcbab924cb3`

MCP Client Setup

Claude Code

Add to your project's .mcp.json (or to ~/.claude.json):

{
  "mcpServers": {
    "tydro": {
      "command": "npx",
      "args": ["tydro-mcp"],
      "env": {
        "PRIVATE_KEY": "0xYOUR_DEV_WALLET_PRIVATE_KEY"
      }
    }
  }
}

Cursor

Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (project-level):

{
  "mcpServers": {
    "tydro": {
      "command": "npx",
      "args": ["tydro-mcp"],
      "env": {
        "PRIVATE_KEY": "0xYOUR_DEV_WALLET_PRIVATE_KEY"
      }
    }
  }
}

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "tydro": {
      "command": "npx",
      "args": ["tydro-mcp"],
      "env": {
        "PRIVATE_KEY": "0xYOUR_DEV_WALLET_PRIVATE_KEY"
      }
    }
  }
}

Windsurf / VS Code / Codex

Any client that supports the standard MCP stdio transport. The command is always npx tydro-mcp with PRIVATE_KEY in the env block.

HTTP/SSE Transport

tydro-mcp ships a second binary — tydro-mcp-http — that exposes the same tools over HTTP with SSE streaming instead of stdio. Use this when stdio isn't available, e.g. for agent-to-agent usage where a remote agent (OpenClaw, self-hosted Railway/Fly agents, etc.) needs to call Tydro tools over the network.

Start the HTTP server

TYDRO_NETWORK=mainnet \
PRIVATE_KEY=0xYOUR_DEV_WALLET_PRIVATE_KEY \
PORT=3100 \
npx -p tydro-mcp tydro-mcp-http

Or from a clone:

npm install && npm run build
PRIVATE_KEY=0x... PORT=3100 node build/http.js

Endpoints

Path	Method	Purpose
`/sse`	`GET`	Server-Sent Events stream for MCP protocol messages
`/message`	`POST`	Client-to-server message delivery

Connect an agent

Configure your agent framework to connect to:

SSE endpoint: http://localhost:3100/sse
POST endpoint: http://localhost:3100/message

The tool surface is identical to the stdio variant — same 7 tools, same schemas, same env var requirements.

Security & Key Management

MCP servers run locally on your machine as child processes spawned by the MCP client. Communication happens over stdio — there are no open ports and no network exposure. Environment variables like PRIVATE_KEY stay on your machine and are never sent to any AI provider; the model only sees tool definitions and tool results.

That said, never put your main wallet private key in the MCP config. The config file is stored in plain text on disk, readable by any process running as your user. If accidentally committed to version control, the key is permanently exposed.

Recommended: dedicated dev wallet

Create a fresh EVM keypair specifically for use with tydro-mcp. Fund it with only the ETH you need for:

Gas fees for the on-chain txs you're about to run
The supply positions you intend to open

Treat the key as disposable. If it's compromised (accidental commit, disk leak, screen-share mistake), rotate it without losing significant funds.

Generate a disposable hot key

Any of these work:

Node.js (no extra install):

node -e "const{generatePrivateKey,privateKeyToAddress}=require('viem/accounts');const k=generatePrivateKey();console.log('Address: '+privateKeyToAddress(k)+'\nPrivate key: '+k)"

OpenSSL:

openssl rand -hex 32 | awk '{print "0x"$1}'

Foundry (cast):

cast wallet new

Save the printed address and private key. Import the address into a watch-only tool if you want a UI view of the positions. Never reuse this key for anything else.

Read-only mode (no key)

If you only want to read positions / reserve data and never execute writes, omit PRIVATE_KEY entirely. All read tools (get_reserve_data, get_user_account, get_user_reserve) work without a key.

{
  "mcpServers": {
    "tydro": {
      "command": "npx",
      "args": ["tydro-mcp"]
    }
  }
}

Write tools (supply, borrow, repay, withdraw) will return a clear error if called without a key configured.

What tydro-mcp cannot do

Liquidate other users. Not exposed as a tool. Use the Tydro frontend or contract directly.
Flashloans. Not exposed as a tool.
Set emode category. Use the Tydro frontend.
Anything outside Tydro. This server is purposefully scoped to the Tydro lending pool — no swaps, no cross-chain bridging, no token launches.

Environment Variables

Set these in the "env" block of your MCP client config. A .env file can be used as a fallback for local development.

Variable	Required	Default	Description
`PRIVATE_KEY`	For writes	—	EVM private key, `0x`-prefixed 32-byte hex. Omit for read-only mode.
`TYDRO_RPC`	No	`https://rpc-gel.inkonchain.com`	Custom Ink RPC endpoint override. Useful for private RPCs (Gelato, Alchemy, QuickNode, etc.) with higher rate limits or better reliability.
`TYDRO_NETWORK`	No	`mainnet`	Network selection. Currently only `mainnet` is supported — `testnet` throws on startup until testnet deployment is wired up.
`PORT`	No	`3100`	Listen port for the HTTP/SSE variant (`tydro-mcp-http`) only. Ignored by the stdio server.

Example Prompts

These work out of the box with Claude Code, Claude Desktop, or any MCP-compatible agent. Use them as starting points to see what Tydro tooling can do.

Yield comparison across all assets

"What are the current supply APYs for WETH, USDT0, sUSDe, and GHO on Tydro? Rank them best to worst."

Safe borrow sizing

"I want to supply 2 WETH to Tydro and borrow USDT0 against it. What's the current WETH supply APY, what's the USDT0 borrow APY, and how much USDT0 can I safely borrow while keeping my health factor above 2.0?"

Wallet health check

"Check this wallet's Tydro health factor and tell me if it's at liquidation risk: 0x..."

Full position audit

"Give me a complete breakdown of this wallet's Tydro positions — every asset they've supplied and borrowed, their health factor, and how close they are to liquidation: 0x..."

Rate arbitrage scout

"Compare Tydro's USDT0 and USDC borrow APYs. Which is cheaper to borrow right now, and what's the spread?"

Liquidation monitor

"Check these three wallets on Tydro and flag any with a health factor below 1.5: 0x..., 0x..., 0x..."

Leveraged long setup

"Using Tydro, supply 0.1 WETH as collateral, borrow $100 of USDT0 against it, then tell me what my new health factor is and how much more USDT0 I could safely borrow."

Yield carry check

"Look up my current Tydro position and compute my net interest — how much am I earning per year on my supply positions minus what I'm paying on my borrows?"

Notes

Decimals are asset-specific — kBTC is 8, USDT0/USDC/USDG are 6, everything else is 18. The server handles conversion automatically, so always pass amounts in human-readable units ("1.5" for 1.5 WETH, not "1500000000000000000").
Max repay / max withdraw uses type(uint256).max — Aave caps at the actual balance/debt on-chain, so you can never over-repay or over-withdraw. Use "max" freely.
Health factor of ∞ means no debt — the wallet is fully collateralized with no borrows open.
Liquidation threshold is 1.0 — health factor below 1.0 means the position can be liquidated. Below 1.5 is the danger zone. Above 2.0 is generally considered safe for volatile collateral.
No stable rate — Aave V3 deprecated stable rate borrowing. All borrows via tydro-mcp are variable rate.
Collateral flags are asset-specific — some reserves (particularly stablecoins) may be listed as supply/borrow-only with LTV 0, meaning they earn yield but can't be used as collateral. Use get_user_reserve to check usedAsCollateral per asset.

Contracts (Ink Mainnet)

Contract	Address
Pool (Aave V3 L2Pool)	`0x2816cf15F6d2A220E789aA011D5EE4eB6c47FEbA`
PoolDataProvider	`0x96086C25d13943C80Ff9a19791a40Df6aFC08328`
PoolAddressesProvider	`0x4172E6aAEC070ACB31aaCE343A58c93E4C70f44D`
UIPoolDataProvider	`0x39bc1bfDa2130d6Bb6DBEfd366939b4c7aa7C697`
Oracle	`0x4758213271BFdC72224A7a8742dC865fC97756e1`
WETHGateway	`0xDe090EfCD6ef4b86792e2D84E55a5fa8d49D25D2`

Development

git clone https://github.com/mavrkofficial/tydro-mcp.git
cd tydro-mcp
npm install
npm run build

npm run build      # Compile TypeScript to build/
npm run dev        # Watch mode (tsc --watch)
npm run typecheck  # Typecheck without emitting files

Local testing

Run the stdio server directly:

PRIVATE_KEY=0x... node build/index.js

Or the HTTP variant:

PRIVATE_KEY=0x... PORT=3100 node build/http.js

Then connect your MCP client to the local binary instead of via npx.

Contributing

Fork the repo and create a feature branch
Make your changes and ensure npm run typecheck && npm run build passes
Open a pull request against main

Contributions welcome, especially:

Testnet deployment wiring (currently TYDRO_NETWORK=testnet throws)
Additional Aave V3 features (e.g. setUserUseReserveAsCollateral, swapBorrowRateMode — though stable rate is deprecated)
Flashloan tool

Disclaimer

This software is experimental and interacts with the live Ink blockchain. It can execute real financial transactions including supplying collateral, borrowing against that collateral, and withdrawing positions. These operations involve real funds and can result in liquidation if positions become undercollateralized.

No warranty. MIT licensed, provided as-is.
No financial advice. This is infrastructure tooling, not investment guidance. Supplying and borrowing on Tydro carries market risk, smart contract risk, and liquidation risk.
Verify everything. Always review tool call parameters before approving execution, especially for writes that move funds or open debt positions.
Use a fresh dev wallet with only the funds you're willing to lose. Never use your main wallet private key.
Monitor your health factor. If it drops below 1.0, the position can be liquidated by anyone and you lose a portion of your collateral as a liquidation bonus to the liquidator.
The authors are not responsible for losses incurred through use of this software.

By installing and using tydro-mcp, you accept these risks.

License

MIT © MAVRK

Available Tools

7 tools

borrowA

Borrow an asset from Tydro. Requires existing collateral and PRIVATE_KEY env var. Only variable rate (mode 2) is supported — stable rate borrowing is deprecated in Aave V3.

ParametersJSON Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol or address to borrow
`amount`	Yes	Amount to borrow in human units

TDQS

A4.1/5.0

Behavior4/5

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

Discloses that only variable rate is supported and stable is deprecated, and authentication via PRIVATE_KEY env var. No annotations provided, so description carries full burden and does well.

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?

Three concise sentences, front-loaded with purpose, no redundancy. Every sentence earns its place.

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?

No output schema, but description doesn't explain return values or consequences of borrowing (e.g., debt accrual). Adequate for a simple action but could be more complete.

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 baseline is 3. Description adds 'in human units' for amount and repeats asset description. Minimal added value beyond schema.

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?

The description clearly states 'Borrow an asset from Tydro', specifies the action (borrow), resource (asset), and distinguishes from sibling tools like supply, withdraw, and repay.

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?

Explicitly states prerequisites (existing collateral, PRIVATE_KEY env var) and constraints (only variable rate mode 2 supported, stable deprecated). Clear when to use and when not, but no explicit alternative for stable rate borrowing.

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

get_reserve_dataA

Get supply APY, borrow APY, total liquidity, utilization, and available liquidity for any Tydro reserve. Supported assets: WETH, kBTC, USDT0, USDG, GHO, USDC, weETH, wrsETH, ezETH, sUSDe, USDe, SolvBTC.

ParametersJSON Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol (e.g. WETH, USDT0, kBTC) or raw contract address

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided. The description indicates a read operation by listing returned data fields, but does not mention authentication, rate limits, or any side effects. Adequate for a simple query tool.

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 concise sentences provide all necessary information without redundancy. Front-loaded with the core action.

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?

Given the single parameter and no output schema, the description adequately conveys what data is returned. Could be improved by mentioning numeric format or decimals, but it's sufficient.

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%, and the description adds value by specifying asset can be a symbol or contract address, and lists the supported symbols, which reduces ambiguity.

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?

The description clearly states the tool retrieves reserve data (supply APY, borrow APY, etc.) for any Tydro reserve, and lists supported assets. It distinguishes from sibling action tools like borrow, repay.

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?

The description implies usage for querying reserve data, but does not explicitly state when to use this tool over siblings or offer exclusions. With siblings being action-oriented, the purpose is clear enough.

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

get_user_accountB

Get a user's overall Tydro position: total collateral, total debt, borrowing capacity, health factor, and liquidation risk.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	User wallet address (0x...)

TDQS

B3.3/5.0

Behavior3/5

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

No annotations are present, so the description bears full burden. It correctly implies a read operation and lists returned data, but does not disclose authentication needs, rate limits, or potential errors. Adequate but minimal.

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?

Single sentence, no fluff, front-loaded with the verb and resource. Every word earns its place.

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 simple read tool with one parameter and no output schema, the description is functional but lacks details on return format, error cases, or usage constraints. Could be more complete but is minimally adequate.

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% with a single parameter, and the description does not add meaning beyond the schema. The parameter 'address' is well-defined in the schema, so baseline score of 3 is appropriate.

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 clearly states the tool retrieves a user's overall Tydro position, listing specific fields (collateral, debt, etc.). It is specific but does not explicitly differentiate from sibling tools like 'get_user_reserve', which may have narrower scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'borrow', 'supply', or 'get_user_reserve'. The description implies it is for overall position but lacks explicit context or exclusions.

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

get_user_reserveB

Get a user's position for a specific asset: how much they've supplied, borrowed, and whether it's used as collateral.

ParametersJSON Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol or address
`address`	Yes	User wallet address (0x...)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. It states outputs but omits any side effects, authentication needs, rate limits, or whether it's read-only.

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?

Single sentence, front-loaded, no wasted words. Efficiently conveys core purpose.

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?

No output schema, but description gives a high-level idea of returns. Could specify return format (e.g., object with numeric fields and boolean). Adequate for a simple read tool.

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% and parameter descriptions are adequate. Description adds no extra context beyond the schema for the two parameters.

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?

Clear verb ('get') and resource ('user's position for a specific asset'), with explicit outputs (supplied, borrowed, collateral). Distinguishes from siblings like 'get_user_account' and 'get_reserve_data'.

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

Usage Guidelines2/5

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

No guidance on when to use vs alternatives (e.g., 'get_user_account'), no prerequisites or exclusions stated.

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

repayA

Repay borrowed assets. Use amount "max" to repay the full debt. Requires PRIVATE_KEY env var.

ParametersJSON Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol or address to repay
`amount`	Yes	Amount to repay in human units, or "max" to repay full debt

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description carries burden. Mentions env var requirement but omits side effects, error handling, or transaction behavior.

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 concise sentences with zero waste. Efficiently conveys core purpose and key usage note.

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?

Covers essential usage and env requirement. Lacks output/error info but adequate for simple mutation tool given sibling context.

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% with descriptions for both parameters. Description adds no new meaning beyond schema, meeting baseline for high coverage.

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?

Description clearly states it repays borrowed assets, distinguishing it from siblings like borrow, supply, withdraw. However, it does not specify the protocol or context beyond repayment.

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?

Instructs using 'max' to repay full debt and mentions PRIVATE_KEY requirement. But lacks when-not-to-use or comparison with alternatives like repay vs withdraw.

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

supplyA

Supply (deposit) an asset to Tydro to earn interest. Requires PRIVATE_KEY env var. Automatically approves the Pool to spend your tokens if needed.

ParametersJSON Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol or address to supply
`amount`	Yes	Amount to supply in human units (e.g. "1.5" for 1.5 WETH)

TDQS

A4.5/5.0

Behavior4/5

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

Discloses side effects: requires PRIVATE_KEY and may auto-approve token spending. Since no annotations are provided, description carries full burden and does so adequately.

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?

Three concise sentences, front-loaded with primary purpose. Every sentence adds value without redundancy.

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?

For a simple deposit tool with two well-described parameters, the description covers function, prerequisite, and automatic behavior, making it complete for an AI agent.

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%; description adds that amount is in 'human units' (e.g., '1.5' for 1.5 WETH), clarifying format beyond schema.

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?

Clearly states 'Supply (deposit) an asset to Tydro to earn interest.' with specific verb and resource, and is distinguishable from siblings like borrow, withdraw, etc.

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?

Specifies requirement for PRIVATE_KEY env var and mentions automatic approval, providing context for usage. Does not explicitly state alternatives or when not to use, but the function is well-defined.

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

withdrawA

Withdraw supplied assets from Tydro. Use amount "max" to withdraw full balance. Requires PRIVATE_KEY env var.

ParametersJSON Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol or address to withdraw
`amount`	Yes	Amount to withdraw in human units, or "max" to withdraw all

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description bears the full burden. It discloses the PRIVATE_KEY requirement, which is important, but lacks details on success/failure behavior or side effects. Adequate but not thorough.

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 waste. Efficiently delivers purpose, usage hint, and a prerequisite.

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 simple withdrawal tool with full schema coverage and no output schema, the description covers purpose, special usage, and a key prerequisite. It could mention return behavior but is largely sufficient.

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%, and the description repeats the 'max' usage already documented in the amount parameter's schema. No additional semantic value is added beyond what the schema provides.

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?

The description clearly states the action 'Withdraw supplied assets from Tydro,' using a specific verb+resource pattern. This distinguishes it from sibling tools like borrow, repay, and supply.

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?

The description provides explicit guidance on using 'max' for full balance withdrawal and a critical prerequisite (PRIVATE_KEY env var). While it doesn't explicitly contrast with siblings, the context makes the tool's role clear.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose: borrow/repay/supply/withdraw for actions, and get_reserve_data/get_user_account/get_user_reserve for queries. No overlap in functionality.

Naming Consistency5/5

All tool names use lowercase with underscores for compound words, following a consistent verb_noun pattern. Action tools are single verbs, query tools use 'get_' prefix.

Tool Count5/5

Seven tools cover the core operations of a lending protocol without excess. Each tool serves a necessary purpose, and the set is well-scoped for user interactions.

Completeness4/5

All major operations (supply, borrow, repay, withdraw) and key queries are present. Missing a tool to toggle collateral usage on deposits, but the core lifecycle is covered.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

tenzro
xyz.tenzro
Tenzro Network MCP server: wallet, identity, payments, inference, staking, bridges, verification.
Blockchain Cryptocurrency Payments & Billing
2
AI.TV MCP Server
tv.ai
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
Entertainment & Media AI & Machine Learning
2
crypto-defi-mcp
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202

Related MCP Servers

Kaskad Protocol MCP Server
Kaskad-Lending
F
license
Not graded
quality
D
maintenance
First-party MCP server for Kaskad Protocol — a DeFi lending protocol on Igra L2 (Kaspa). Enables AI agents to autonomously supply, borrow, repay, withdraw, and stake. Includes 16 tools covering live market reads, governance params, health factor monitoring, emission state, and full write access to on-chain lending operations. Compatible with Claude, OpenClaw, and any MCP-compatible client.
Updated 3 months ago (2026-06-05 09:57 UTC)
mcp-server-justlendofficial
Blockchain Web3 & Decentralized Tech Cryptocurrency
justlend
A
license
A
quality
A
maintenance
An MCP server enabling AI agents to interact with JustLend DAO on TRON for lending, borrowing, and portfolio management, plus general TRON chain utilities.
Updated 7 days ago (2026-08-28 02:24 UTC)
98
227
2
MIT
nado-mcpofficial
Blockchain Cryptocurrency Finance
nadohq
A
license
Not graded
quality
D
maintenance
MCP server for the Nado Protocol on the Ink blockchain, enabling AI assistants to query market data, manage positions, place orders, and access historical trading data.
Updated 5 months ago (2026-04-07 07:44 UTC)
24
1
MIT
typus-perp-mcpofficial
Blockchain Cryptocurrency Finance
Typus-Lab
F
license
A
quality
D
maintenance
MCP server for Typus Perp, enabling AI agents to query markets, manage positions, and execute trades on the Typus Perp DEX on Sui.
Updated 6 months ago (2026-03-09 10:43 UTC)
19

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mavrkofficial/tydro-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

tydro-mcp

Table of Contents

Quick Start

1. Install (no manual install needed)

2. Fund a dedicated dev wallet

3. Add to your MCP client config

4. (Optional) Use a private RPC endpoint

Tool Catalog

Read-only — no private key required

Write — requires PRIVATE_KEY

get_reserve_data

get_user_account

get_user_reserve

supply

borrow

repay

withdraw

Supported Assets

MCP Client Setup

Claude Code

Cursor

Claude Desktop

Windsurf / VS Code / Codex

HTTP/SSE Transport

Start the HTTP server

Endpoints

Connect an agent

Security & Key Management

Recommended: dedicated dev wallet

Generate a disposable hot key

Read-only mode (no key)

What tydro-mcp cannot do

Environment Variables

Example Prompts

Yield comparison across all assets

Safe borrow sizing

Wallet health check

Full position audit

Rate arbitrage scout

Liquidation monitor

Leveraged long setup

Yield carry check

Notes

Contracts (Ink Mainnet)

Development

Local testing

Contributing

Disclaimer

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

mcp-server-justlendofficial

nado-mcpofficial

typus-perp-mcpofficial

Latest Blog Posts

MCP directory API

Write — requires `PRIVATE_KEY`

`get_reserve_data`

`get_user_account`

`get_user_reserve`

`supply`

`borrow`

`repay`

`withdraw`