This server provides an AI-agent-accessible DeFi operations toolkit for managing wallets, swapping tokens, and interacting with Aave across Base, Citrea, HyperEVM, and Monad.
Check authentication status and Fibrous API health before performing transactions.
Manage per-chain RPC configuration: set, get, reset, or list custom RPC URLs.
View wallet balances for native and ERC-20 tokens on any supported chain.
Send native tokens or ERC-20 tokens to any address, with optional simulate-only preview.
Query transaction status and receipt details by transaction hash.
View a cross-chain portfolio with USD valuations, including Aave positions and net worth.
Get token swap quotes without needing a wallet or session.
Execute token swaps through Fibrous aggregation with slippage control and optional simulation.
Inspect Aave V3 account health and reserve markets on Base.
Perform Aave supply, borrow, repay, and withdraw actions, including ETH/WETH auto-wrap/unwrap and 'max' amounts.
A command-line tool and MCP server for DeFi operations on Base, HyperEVM, and Monad, powered by Fibrous aggregation. Sign with your own wallet over WalletConnect, with a Privy server wallet, or with an imported key — every path bounded by a signing policy that lives on your machine.
Multi-Chain Support: Base, HyperEVM, and Monad
Portfolio: Cross-chain portfolio overview with USD valuations and DeFi positions
Token Swaps: Optimal routing via Fibrous aggregation with auto-slippage
Transfers: Send ETH or any ERC-20 token
Aave V3: Supply, borrow, repay, withdraw, and browse markets on Base
MCP Server: Built-in AI agent integration for Cursor, Claude Desktop, and Antigravity (19 tools)
The FibX app, in the chat: in hosts that render MCP Apps UI such as Claude Desktop, open_fibx shows the wallet, balances, signing policy and a swap form with the Fibrous route inline — the model opens it, and you press Simulate and Swap
Agent Skills: Prompt-based AI skills via fibx-skills
Your own wallet: Pair over WalletConnect and approve every transaction on your phone
Privy Server Wallets: Server-side signing — the CLI receives signed transaction payloads or signatures, not Privy app credentials or raw keys
Private Key Import: Use an existing wallet with AES-256-GCM encrypted local storage
Local signing policy: A file you own — native value cap per chain, allowed chains, allowed destinations, expiry — enforced before every signature on all three paths (Privy adds its own server-side policy on top)
Preflight Checks: Transaction flows validate or estimate execution where the underlying RPC supports it
Dry‑Run Mode: --simulate previews write operations without broadcasting; gas estimates are included where available
JSON Output: --json flag for scripting and pipelines
Zero-Dependency Install: Single-file bundle via tsup — npx fibx runs near-instantly
Related MCP server: Fibrous MCP Server
Chain | Native Token | Aave V3 |
Base | ETH | ✅ |
HyperEVM | HYPE | — |
Monad | MON | — |
Run directly with npx (no install needed):
npx fibx statusOr install globally:
npm install -g fibxNode.js >= 18
A running fibx-server instance (required for Privy wallet operations; not needed for private key imports)
Try FibX instantly — no sign-up, no wallet, no keys:
npx fibx quote 0.01 ETH USDC # Check price on Base
npx fibx quote 100 USDC DAI --chain base # Compare pairs
npx fibx quote 0.5 MON USDC --chain monad # Check Monad pricesOption A — Email Login (Privy Server Wallet, no keys to manage):
npx fibx auth login you@email.com # Sends OTP to your email
npx fibx auth verify you@email.com 123456 # Verify & create walletOption B — Import Private Key (use an existing wallet):
npx fibx auth import # Paste your key (encrypted at rest)npx fibx trade 0.01 ETH USDC # Execute the swap
npx fibx balance # Check your balancesThat's it. Three steps from zero to first swap.
Run fibx auth setup and it will ask. The three paths differ on one thing:
Path | Key held by | Runs while you are away | Bounded by |
| your own wallet | no | you, on your phone |
| Privy | yes | Privy's signing policy |
| this machine | yes | the local policy you set |
Keeping your own wallet and having FibX act unattended needs ERC-7715, which
wallets do not yet expose over WalletConnect. fibx auth setup explains the
closest options.
Security: When using
auth import, your private key is encrypted at rest with AES-256-GCM. The encryption key is auto-generated per machine and stored in the OS config directory (e.g.~/.config/fibx-nodejs/encryption-keyon Linux). You can also set theFIBX_SESSION_SECRETenvironment variable for CI/Docker environments.
npx fibx auth connectPairs FibX with a wallet you already have — MetaMask, Rabby, Rainbow, Phantom — over WalletConnect. A QR code appears in the terminal; scan it with your phone. Every transaction is then approved in your wallet, so the keys never leave it.
The chain you trade on must already be in your wallet, and it is approved when
you pair. If you try to sign on a chain the session does not carry, FibX stops
before contacting the wallet and names the chain: add it in your wallet, then run
npx fibx auth connect again so the new chain is included.
With --json, output is NDJSON — one JSON document per line, not one document
for the whole run: the pairing URI prints first as {"uri":"wc:..."} so a
script can act on it while it waits, then the result prints as its own compact
JSON line once the wallet approves.
npx fibx auth logout ends the connection on both sides: it tells your wallet to
drop the session, so FibX stops appearing in its connected-apps list, and removes
the pairing keys from disk along with the session.
A shared WalletConnect project id ships in the published bundle, so this works
with no setup. It is public by necessity — a CLI has no origin to allowlist — so
its only real exposure is quota consumed by third parties. If pairing starts
failing on quota, create a free project at
cloud.reown.com and set FIBX_WC_PROJECT_ID to your
own id.
auth login (email OTP) and auth import (private key) are unchanged and remain
available.
fibx policy bounds what FibX is allowed to sign, on top of whichever path
from the table above holds the key — a client-side cap evaluated before every
local-key, Privy, or WalletConnect transaction:
npx fibx policy show # Print the active policy
npx fibx policy set base.maxValue 0.05
npx fibx policy set allowedChains base,monad
npx fibx policy set base.allowedDestinations 0xYourColdWallet,0xTheRouter
npx fibx policy set expiry 2026-12-31 # UTC midnight starting that day
npx fibx policy clear base.maxValue # Remove one rule
npx fibx policy clear # Remove the whole policy (asks first)A local policy guarding a local key is advisory: anything that can read the key can edit the policy, so this is worth nothing against malware. What it does bound is the agent — a model that misbehaves, or a prompt injection telling it to.
Know what each rule bounds, because they are not the same:
maxValue caps the native value of a single transaction — ETH on Base,
HYPE on HyperEVM, MON on Monad. It does not bound tokens. An ERC-20 transfer
reaches the policy as a call to the token's contract carrying value: 0, so
the amount is invisible to it: base.maxValue 0.05 places no limit on
fibx send 50000 USDC 0xsomewhere, on the token side of a trade, or on an
Aave borrow. A token-value cap needs decimals and a token registry, and is
not in this release.
allowedDestinations is the rule that bounds tokens, by bounding where
anything may go. It is the one to set if the worry is an agent moving your
holdings somewhere. Note that allowlisting a token's contract so a trade can
approve it also permits transfers of that token.
allowedChains and expiry do exactly what they say. A lapsed or
unparseable policy refuses everything rather than permitting it.
Option | Description | Default |
| Target chain ( |
|
| Output results as JSON |
|
npx fibx balance
npx fibx balance --chain hyperevmConsolidated cross-chain portfolio view with USD valuations:
npx fibx portfolio # Table output across all chains
npx fibx portfolio --json # Structured JSON for scriptingShows all token holdings across Base, HyperEVM, and Monad with USD values. Includes DeFi positions (Aave V3 collateral/debt) and total portfolio net worth. Token prices are sourced live from Fibrous.
npx fibx send 0.001 0xRecipient # Send native token on Base (ETH)
npx fibx send 10 0xRecipient USDC # Send ERC-20 on Base
npx fibx send 1 0xRecipient --chain monad # Send MON on Monad
npx fibx send 0.1 0xRecipient --simulate # Preview without sendingGet swap prices without authentication:
npx fibx quote 0.01 ETH USDC # Price check on Base
npx fibx quote 1 MON USDC --chain monad # Check Monad prices
npx fibx quote 0.1 ETH USDC --json # JSON output for scriptsNo wallet or authentication required. Use
quoteto explore prices, thentradeto execute.
npx fibx trade <amount> <from> <to>
npx fibx trade 0.0001 ETH USDC
npx fibx trade 20 USDC DAI
npx fibx trade 1 MON USDC --chain monad
npx fibx trade 0.1 ETH USDC --simulate # Preview without broadcastingOptions: --slippage <n> (default: 0.5%), --approve-max, --simulate, --json
Note: The
tradecommand automatically detects Wrap (Native -> Wrapped) and Unwrap (Wrapped -> Native) operations and executes them directly via contract calls, bypassing aggregator routing to save gas.
npx fibx tx-status <hash>
npx fibx tx-status 0x123...abc --chain monadnpx fibx address # Print active wallet address
npx fibx wallets # Show active wallet detailsnpx fibx aave status # Account health
npx fibx aave markets # List all active reserves with APY & TVL
npx fibx aave supply 1 ETH # Auto-wraps ETH -> WETH and supplies
npx fibx aave supply 100 USDC # Supply ERC-20
npx fibx aave borrow 50 USDC # Borrow
npx fibx aave repay 50 USDC # Repay
npx fibx aave repay max ETH # Auto-wraps ETH and repays full WETH debt
npx fibx aave withdraw max ETH # Withdraws WETH and auto-unwraps to ETH
npx fibx aave supply 1 ETH --simulate # Preview without broadcastingNote:
supply,repay, andwithdrawsupport automatic ETH <-> WETH wrapping/unwrapping on Base.
Set custom RPC URLs to avoid rate limits on public endpoints:
npx fibx config set-rpc base https://mainnet.base.org
npx fibx config get-rpc base
npx fibx config reset-rpc base # Reset single chain to default
npx fibx config reset-rpc # Reset all chains to default
npx fibx config listHot-reload: Config changes are picked up automatically — no need to restart the CLI or MCP server.
fibx includes a built-in MCP server for AI editors like Cursor, Claude Desktop, and Antigravity. See MCP.md for setup and available tools.
npx fibx mcp-startThe MCP server exposes 19 tools: the FibX app (open_fibx, list_tokens), read-only queries, three transactional tools, and session and policy management. All write operations support a simulate=true preview that does not broadcast; gas estimates are returned only where available.
In a host that renders MCP Apps UI — Claude Desktop today — open_fibx is the entry point: ask about your wallet, a balance, a price or a swap and the whole app opens inline, pre-filled from the conversation. It executes nothing on its own; Simulate and Swap are buttons you press. In a text-only host the same call returns a JSON snapshot the model can summarise, and the headless tools do the rest.
For prompt-based agent integration (Claude Code, Cursor, etc.), see the fibx-skills repository.
Letting an AI agent operate a wallet requires controls outside the model. fibx combines signing-layer policies, server-side validation, client hints, and explicit previews. These controls reduce risk, but the server credentials, MCP client configuration, and deployment policy remain part of the trust boundary:
Layer | What it does |
Privy signing policy | The default policy allowlists configured chains, caps each transaction's native-token |
fibx-server schemas |
|
MCP tool annotations | Every transactional tool advertises |
Simulation |
|
Local key storage | Imported private keys are encrypted at rest with AES-256-GCM using a per-machine key stored |
Wallet policy limits are configured per deployment — see the fibx-server wallet policy docs.
Note: policies are attached when a wallet is created. Wallets provisioned before policies were introduced keep signing without them until migrated.
This repository is the CLI and MCP server. Three sibling repositories complete the stack:
Repository | Role |
fibx (this repo) | CLI + stdio MCP server, shipped as a single dependency-free bundle |
Hono backend that proxies Privy — holds the app secret so the CLI never does, and owns the wallet signing policy | |
Prompt-based Agent Skills for Claude Code, Cursor, and other skill-aware agents | |
Telegram bot that drives this CLI over MCP, with one process and separate config paths per active user |
src/
├── commands/ # CLI commands (auth, policy, trade, send, aave, config)
├── mcp/ # Modular MCP server
│ ├── server.ts # Entry point + MCP_INSTRUCTIONS
│ ├── ui.ts # The ui://fibx/app.html resource (the built widget, inlined)
│ ├── tools/ # Tool registrations (app, auth, wallet, trade, defi, policy)
│ └── handlers/ # Tool implementations
├── services/ # Business logic (chain, fibrous, auth, policy, walletconnect, defi, portfolio)
└── lib/ # Shared utilities (errors, fetch, format, crypto)
ui/
├── src/ # The FibX app widget — Preact, one document, no network
└── dev-host/ # A local MCP Apps host for the widget: fixtures, or a bridge to the real serverThe widget is built by Vite into a single HTML document and embedded in
dist/index.js by tsup, so the published package is still one file with no
runtime dependencies.
pnpm install
pnpm dev # run the CLI from source
pnpm test # vitest unit tests
pnpm typecheck # tsc --noEmit
pnpm lint # eslint
pnpm format:check # prettier
pnpm build # vite (the app widget) then tsup, to dist/
pnpm dev:ui # the app widget in a local host, against fixtures — no wallet neededpnpm dev:ui:bridge runs the same host against the real MCP server; a Swap
there is a real swap.
Fibrous Finance — DEX aggregator powering swaps
MCP registry listing — finance.fibrous/fibx
Execute an Aave V3 action on Base: supply, borrow, repay, or withdraw. ETH supply/repay can auto-wrap and ETH withdraw can auto-unwrap; borrowing the ETH market returns WETH. Use 'max' as amount to repay or withdraw the full balance. Set simulate=true for a no-broadcast operation preview.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol (e.g. 'ETH', 'USDC', 'WETH') | |
| action | Yes | Aave action to perform | |
| amount | Yes | Amount (e.g. '100', '0.5', 'max'). Use 'max' for full repay/withdraw. | |
| simulate | No | Set true for a no-broadcast operation preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral details beyond annotations: auto-wrap/unwrap, borrowing returns WETH, 'max' uses full balance, simulate preview. Annotations only provide destructiveHint, so description adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, each sentence adds essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers the tool's behavior for an AI agent to use correctly, given the parameter count, annotations, and sibling context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds nuance (ETH auto-wrap/unwrap, 'max' behavior) that enhances understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes Aave V3 actions (supply, borrow, repay, withdraw) on Base, distinguishing it from sibling read-only tools like get_aave_status and get_aave_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage hints: auto-wrap/unwrap for ETH, 'max' for full repay/withdraw, simulate for preview. However, does not explicitly state when not to use (e.g., for reading positions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View and modify fibx RPC configuration. Use 'set-rpc' to set a custom RPC URL for a chain (helps avoid rate limits), 'get-rpc' to view the current RPC for a chain, 'reset-rpc' to reset a chain's RPC to default (omit chain to reset all), or 'list' to show all custom RPC settings.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | RPC URL to set (required for set-rpc) | |
| chain | No | Target chain (required for set-rpc and get-rpc) | |
| action | Yes | Config action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false and destructiveHint=false, indicating a safe modification tool. The description adds behavioral context: set-rpc helps avoid rate limits, reset-rpc can reset all if chain omitted. This provides useful guidance beyond the annotations, though it could mention the irreversible nature of reset more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, containing only two sentences. The first sentence states the overall purpose, and the second enumerates sub-actions with brief explanations. No extraneous words; each phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more complete by specifying what each action returns (e.g., confirmation messages or current settings). However, it covers the core functionality and parameter usage well, so it's mostly complete for a configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by linking each action to required parameters (url for set-rpc, chain for set-rpc and get-rpc) and clarifying the behavior of reset-rpc with omitted chain. This enables correct parameter usage beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: viewing and modifying fibx RPC configuration. It lists four specific sub-actions (set-rpc, get-rpc, reset-rpc, list) and their distinct roles, differentiating it from sibling tools which handle balances, transactions, swaps, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each sub-action: set-rpc to avoid rate limits, get-rpc to view current RPC, reset-rpc to reset (with note to omit chain for all), list to show all custom settings. It does not explicitly state when not to use the tool, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Aave V3 reserve markets on Base with supply/borrow APY, total supply, total borrow, and LTV. Always call this before Aave supply/borrow operations. No wallet required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false. The description adds valuable context: 'No wallet required,' indicating no authentication needed. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers the tool's purpose (listing markets), return data (APY, supply, borrow, LTV), and usage advice. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description naturally adds no param info, but baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Aave V3 reserve markets on Base with specific fields (APY, total supply, total borrow, LTV). This distinguishes it from siblings like aave_action (which performs operations) and get_aave_status (different data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Always call this before Aave supply/borrow operations,' providing clear when-to-use context. Implies alternatives (e.g., aave_action for actual operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Aave V3 position health on Base: health factor, total collateral, total debt, and available borrows in USD.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the exact return data (health factor, collateral, debt, borrows), which is beyond the annotation fields. However, it does not disclose potential side effects, rate limits, or authentication requirements, though none are expected for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence that is front-loaded with the key verb ('Get') and includes all relevant information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema exists, the description lists all returned fields. For a zero-parameter, read-only tool, this is largely complete. It could mention that it queries the connected wallet's position, but this is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description need not add parameter details; the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Aave V3 position health on Base, listing specific metrics (health factor, total collateral, total debt, available borrows in USD). This distinguishes it from sibling tools like get_aave_markets (market data) and aave_action (performing actions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking account health but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check authentication status and Fibrous API health. Always call this first to verify the session is active before performing any transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Target chain to check Fibrous health for | base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by specifying it checks both authentication and Fibrous API health, which is beyond the annotations and clarifies the tool's safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It front-loads the purpose and immediately provides usage guidance, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no required, no output schema), the description covers the key aspects: authentication check and health check. However, it does not describe the return value, which would be helpful for an agent to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'chain' with enum values and default. The description does not add any additional meaning beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool checks authentication status and Fibrous API health. It explicitly says to call it first before any transaction, distinguishing it from sibling tools like get_balance or send_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Always call this first to verify the session is active before performing any transaction.' This tells when to use it, but does not mention when not to or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get native token and all ERC-20 token balances for the active wallet on a specific chain. Only returns tokens with non-zero balances.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Target blockchain network | base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns only non-zero balances, but does not contradict annotations. No further behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words; front-loaded with the core action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with good annotations, the description sufficiently explains the return value scope (native + ERC-20, non-zero balances). No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the chain parameter fully described as 'Target blockchain network'. Description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get', the resource 'native token and all ERC-20 token balances', and scope 'for the active wallet on a specific chain' with 'non-zero balances' filter. Differentiates from siblings like get_portfolio and send_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for checking wallet balances on a specific chain, but does not explicitly state when to use versus alternatives like get_portfolio or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a complete cross-chain portfolio overview with USD valuations for all token holdings across Base, Citrea, HyperEVM, and Monad. Includes DeFi positions (Aave V3). Returns total net worth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds valuable context: includes USD valuations, DeFi positions (Aave V3), and returns total net worth, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading key information: complete cross-chain overview, USD valuations, specific chains, DeFi positions, and return value. No redundant elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly specifies it returns total net worth and includes token holdings and DeFi positions. With no parameters and readOnlyHint, the description provides sufficient guidance for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. The description adds context about the tool's output (token holdings, DeFi, total net worth), which is helpful for understanding the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a complete cross-chain portfolio overview with USD valuations across four specific chains and includes DeFi positions, distinguishing it from sibling tools like get_balance and get_aave_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool provides a portfolio overview, implying use when needing aggregated holdings across chains. However, it does not explicitly exclude use cases or mention alternatives, though sibling differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a price quote for a token swap without authentication. Shows expected output amount, exchange rate, and route info. No wallet or session required — use this to check prices before committing to a swap. Supported chains: Base, Citrea, HyperEVM, Monad.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Target blockchain network | base |
| amount | Yes | Amount to quote (e.g. '0.1', '100') | |
| slippage | No | Slippage tolerance percentage (default: 0.5) | |
| to_token | Yes | Destination token symbol | |
| from_token | Yes | Source token symbol (e.g. 'ETH', 'USDC', 'MON') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds beyond annotations: 'No wallet or session required' and lists supported chains. Discloses return fields (output amount, rate, route). Consistent with readOnlyHint and openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description explains return fields (output amount, exchange rate, route info) and lists supported chains. Covers all necessary context for a quote tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add new details for each parameter beyond general context. Schema descriptions already cover meaning adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a price quote for a token swap' with specific verb and resource. It distinguishes from siblings like swap_tokens by noting no authentication and preview use. Supported chains are listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'use this to check prices before committing to a swap.' No authentication required, which informs when to use. Does not directly name alternatives but context makes it clear vs. swap_tokens.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the on-chain status and receipt of a transaction by its hash. Returns confirmation status, block number, gas used, and addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash (0x...) | |
| chain | No | Chain the transaction was submitted on | base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds marginal value by listing returned fields but does not elaborate on behavior beyond annotations, such as data freshness or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the purpose without superfluous words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic use case but lacks details on the response format (e.g., structure of receipt) which would be helpful since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (hash format, chain enum with default). The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'on-chain status and receipt', and lists returned fields such as confirmation status, block number, gas used, and addresses. This distinguishes it from sibling tools like get_balance or get_auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does without providing usage context, exclusions, or pointers to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send native tokens (ETH, cBTC, HYPE, MON) or ERC-20 tokens to a recipient address. If token is omitted, the chain's native token is used. Set simulate=true for a no-broadcast preview; a gas estimate is returned where available.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Target blockchain network | base |
| token | No | Token symbol (e.g. 'USDC', 'ETH'). Omit for native token transfer. | |
| amount | Yes | Amount to send (e.g. '0.1', '100') | |
| simulate | No | Set true for a no-broadcast preview; gas estimates may be unavailable | |
| recipient | Yes | Recipient address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (write operation) and idempotentHint=false. The description adds key context: simulation mode (simulate=true) for no-broadcast preview and gas estimate availability. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the main action and options, the second adds simulation capability. Information is front-loaded and essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description doesn't detail return format (e.g., transaction hash), but it explains simulation and gas estimates. For a write tool, this covers most agent needs, though explicit output specification would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds that omitting token uses chain's native token, which adds meaning beyond the schema's 'omit for native token transfer.' It also mentions simulate and gas estimates, providing extra usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends native tokens or ERC-20 tokens to a recipient address. It specifies conditions (omitting token for native) and option to simulate. It distinguishes from sibling tools like swap_tokens (swap vs send) and get_balance (read vs write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (sending tokens) but does not explicitly exclude alternatives or state when not to use it. The sibling tools are clearly different in purpose, so the guidance is adequate but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Swap tokens using Fibrous aggregator for optimal routing. Handles ERC-20 approvals and wrap/unwrap automatically. Supported chains: Base, Citrea, HyperEVM, Monad. Set simulate=true for a no-broadcast preview; a gas estimate is returned where it can be calculated safely.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Target blockchain network | base |
| amount | Yes | Amount to swap (e.g. '0.1', '100') | |
| simulate | No | Set true for a no-broadcast preview; gas estimates may be unavailable | |
| slippage | No | Slippage tolerance percentage (default: 0.5) | |
| to_token | Yes | Destination token symbol | |
| from_token | Yes | Source token symbol (e.g. 'ETH', 'USDC', 'MON') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by specifying automatic handling of ERC-20 approvals and wrap/unwrap, and the simulate option for preview. No contradiction with annotations (destructiveHint=true is consistent with swap).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences, front-loaded with purpose and key behaviors. No wasted words, each sentence provides distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description doesn't mention return values (e.g., transaction hash) except gas estimates for simulate. Lacks details on failure behavior, token prerequisites, or error handling, which is significant for a swap tool with 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. Description adds specific explanation for simulate parameter (preview and gas estimates) but doesn't enhance meaning for other parameters beyond schema strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Swap' and resource 'tokens using Fibrous aggregator' immediately conveys the action. Distinguishes from siblings like send_tokens and get_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes what the tool does but lacks explicit guidance on when to use it vs alternatives (e.g., send_tokens) or when not to use it. No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0aave_actionconfig_actionget_aave_marketsget_aave_statusget_auth_statusget_balanceget_portfolioget_quoteget_tx_statussend_tokensswap_tokensScored across 11 tools
Each tool has a distinct purpose: wallet balance, authentication, config, sending, transaction status, portfolio, quote, swap, Aave status, Aave markets, and Aave actions. No two tools have overlapping functionality; the boundaries are clear.
Most tool names follow a clear verb_noun pattern (e.g., get_balance, send_tokens, get_aave_status). Two tools (config_action, aave_action) use a noun_noun pattern, but the overall naming is readable and mostly consistent.
With 11 tools covering wallet management, token operations, swapping, portfolio tracking, and Aave DeFi interactions, the set is well-scoped for a DeFi assistant. Each tool earns its place without redundancy.
Core workflows are covered: balance queries, sending, swapping, Aave operations, and portfolio overview. Minor gaps exist, such as lack of a bridging tool or a dynamic list of supported chains, but these do not severely hinder functionality.
Doc search, intent & cross-chain swaps, limit orders, portfolio, spot prices, gas & all APIs.
Li.Fi MCP: cross-chain aggregation — quotes, routes, status, chains, tokens, execution.
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Cross-network DeFi API data, AMM analytics, and SDK docs for 17+ networks.
