Skip to main content
Glama
Sign In

JW3 MCP Server

by io.github.agnostic4321-ops
OverviewDiscussionsAdmin

Read Binance Web3 DeFi data

read_defi
Read-only

READ-ONLY: query DeFi protocols, yield/lending/liquid-staking/LP/RWA markets, or wallet positions across all 10 Binance Web3 DeFi chains (BNB 56, Ethereum 1, Base 8453, Arbitrum 42161, Arc 5042, Polygon 137, Optimism 10, Avalanche 43114, Robinhood 4663, Katana 747474). Returns APY, base/reward APY breakdown, TVL, redeemDelayDays, yieldAnalytics, and investmentId with a fetch timestamp. Use propose_defi when the user wants an action card.

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

Input Schema

NameRequiredDescriptionDefault
chainNoOptional chain filter by slug or chainId: bnb (56), ethereum (1), base (8453), arbitrum (42161), arc (5042), polygon (137), optimism (10), avalanche (43114), robinhood (4663), katana (747474).
limitNoMax items to return, 1..50 (default 20).
scopeNoWhat to read: investments (default, yield/lending/LP markets), protocols (21+ audited platforms), positions (wallet-scoped DeFi holdings & rewards), protocol_detail (single protocol + markets), or investment_detail (single pool by investment_id).
tokenNoOptional underlying token symbol or contract address filter (e.g. USDC, USDT, BNB, ETH, sUSDe).
addressNoOptional 0x EVM wallet address for scope=positions (auto-resolved from user's connected wallets when omitted).
categoryNoOptional DeFi category filter.
protocolNoOptional defiProtocolId filter (e.g. aave3, aave4, uniswap3, uniswap4, pancakeswap3, pancakeswap4, morphoblue, venus, venusflux, helio, astherus, lido, pendle2, spark, solv, renzo, rocketpool, quickswap3, benqi, frax, maple, cian, emberso, rexyz, usdai).
investment_idNoInvestment pool ID for scope=investment_detail (e.g. bn-aave4-5042-usdc).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substance beyond them: the exact chain set, the returned metrics (APY with base/reward breakdown, TVL, redeemDelayDays, yieldAnalytics, investmentId) and a fetch timestamp. It omits auth requirements, rate limits, and pagination/ordering behavior.

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 sentences, front-loaded with the read-only guarantee and the resource scope before the routing advice. The chain list is long but functional since it enumerates the supported networks; little else is wasted.

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?

No output schema exists, so the description usefully enumerates what comes back, and all 8 optional parameters are covered by the schema. An agent has enough to call it correctly; only edge behaviors (what an empty result looks like, ordering of results) are unaddressed.

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 description coverage is 100%, so every parameter (chain slugs/IDs, limit, scope enum, token, address, category, protocol, investment_id) is already documented at source. The description adds only the chain roster and return fields, not new parameter semantics — the baseline 3 applies.

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 and resource ('query DeFi protocols, yield/lending/liquid-staking/LP/RWA markets, or wallet positions') and pins the scope to the 10 named Binance Web3 DeFi chains. The contrast with propose_defi makes the read-vs-propose boundary explicit.

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?

Gives a clear routing rule: use propose_defi when the user wants an action card, which implies this tool is for inspection. It does not cover other plausible alternatives (e.g. on-chain balance or transaction-building siblings), but the primary read/propose split is stated outright.

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

All JW3 MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources