Ekubo Protocol

Was du damit machen kannst

Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.

• Verbindung: Läuft in der Cloud
• Transport: Streamable HTTP
• Kategorie: Krypto & Blockchain

Installation

Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.

Du brauchst

• Läuft in der CloudNichts zu installieren; die Verbindung läuft übers Internet

Welche App nutzt du?

https://mcp.ekubo.org/mcp

claude mcp add --transport http ekubo https://mcp.ekubo.org/mcp

{
  "mcpServers": {
    "ekubo": {
      "url": "https://mcp.ekubo.org/mcp"
    }
  }
}

{
  "servers": {
    "ekubo": {
      "type": "http",
      "url": "https://mcp.ekubo.org/mcp"
    }
  }
}

https://mcp.ekubo.org/mcp

Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.

Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.

Was er kann

Tool-Namen und -Beschreibungen genau so, wie der Server sie am 6. Nov. 2026 gemeldet hat. Geschrieben hat sie der Entwickler, nicht wir; wir zeigen sie als reinen Text.

• list_tokens

  First step for symbol-based swaps, including tokenized stocks and stablecoins: list canonical Ekubo tokens by descending visibility_priority, so the preferred token wins an ambiguous symbol. Use search for a symbol prefix or suffix and min_visibility_priority to reach tokens the

• export_tokens

  Return a token_list_reference envelope (chain ID, address, symbol, name, decimals) and its count, with no entries, so a wallet can import token names; pass it unchanged as the wallet tool's reference argument. complete=false means the export is a prefix of the chain's list. Use l

• get_token

  Fetch canonical token metadata for an exact chain and address.

• get_tokens

  Fetch canonical metadata for up to 1,000 token identifiers in one batch request, preserving input order; identifiers absent from the canonical list are omitted.

• get_quotes_with_plans

  A quote, execution plan, simulation or wallet approval is not permission to trade. Robinhood Stock Tokens are tokenised debt securities subject to issuer restrictions and applicable law. Before requesting signatures or submitting approvals or trades, establish the user's relevant

• get_value_transfer_status

  Report whether an executed LayerZero or LI.FI transfer has been delivered; its origin receipt alone does not mean the user has the funds. Poll every 15 to 30 seconds while settled is false (it draws on the quote budget). UNKNOWN or NOT_FOUND right after submission usually means n

• prepare_ve33_vote

  Compile one actively voted ve-token into multiple allocations. Unconditionally claims its current pool first, then splits and changes votes in one atomic batch of decodable VeToken steps. Nothing is burned, withdrawn, or transferred: the source keeps a stake and every additional

• prepare_ve33_extend

  Prepare a direct extension for an unvoted VeToken or an atomic claim-and-extend call when current_pool_key identifies an active vote, so pending voter fees are preserved. Extending moves the stake to a later end time and clears its vote — that is why the claim is compounded into

• prepare_ve33_stake

  Create a new VeToken stake with an exact stake-token approval. Max duration is the safe default for new stakes; an explicit shorter duration is optional and no existing NFT, vote, fee balance, or ownership is changed.

• prepare_ve33_split

  Split a source ve-token with an explicit salt and return the deterministic child token ID; the source vote is preserved with reduced weight and the child starts unvoted with the same lock end. Non-destructive: no stake leaves the wallet, no NFT is burned, no vote is cleared, and

• prepare_ve33_claim_fees

  Generate one call, or an atomic batch of decodable VeToken steps, claiming voter fees from one or more ve-tokens. Fees only: votes, stake amounts, lock ends, and NFT ownership are all unchanged, so this is always safe to run before any other ve(3,3) action.

• prepare_ve33_reinvest

  Build the safe phased workflow for 'reinvest my fees': automatically claim all active voter fees, prepare one exact-input swap per claimed non-stake token, then increase one VeToken or every existing active allocation without changing ownership or replacing votes. phase=swap retu

• prepare_ve33_claim_all_fees

  Discover every active vote on VeTokens owned by the sender and generate one atomic batch of decodable VeToken steps claiming all indexed pool fees, with ownerOf and voteState validation calldata. Fees only: votes, stake amounts, lock ends, and NFT ownership are all unchanged.

• prepare_ve33_clear_vote

  Remove the active vote from one or more ve-tokens, claiming each stake's current pool fees immediately before its clearVote in one atomic batch. Use this instead of raw clearVote calldata: Ve33 discards pending voter fees when a stake's weight goes to zero, and a current_pool_key

• get_ve33_allocations

  Use for requests such as 'show all my Ekubo STONX allocations'. The production Ekubo ve(3,3) deployment is the STONX voting system, so pass only owner to select its production chain and canonical VeToken automatically. Returns every pool, selected swap fee, NFT, applied vote weig

• get_stonx_allocation_recommendation

  Return a provider-neutral STONX allocation recommendation with an emissions_efficiency KPI per pool and an executable target list (exactly 10,000 bps, at most 25 Ve33 pools). The snapshot refreshes daily; read snapshot_age_seconds. voter with ve33_emission_state makes targets vot

• prepare_ve33_reallocation

  Compile a reviewed current allocation into at most 25 target pool-weight shares as one atomic batch of decodable VeToken steps. The default path only claims, splits, and votes: nothing is burned, no lock is extended, and nothing is withdrawn. The optional compact_max_lock strateg

• get_positions_by_owner

  Enumerate an owner's indexed Ekubo position NFTs with pool keys, bounds, liquidity, indexed pool state and rewards. For fresh onchain state, pass each current_state_reads[].read_calls_reference to wallet_batch_eth_call as a value in the same code block; each position's current_st

• get_pool

  Resolve a chain/core/pool ID to its verified PoolKey, decoded config and indexed pool state. For fresh sqrtRatio, tick and liquidity, pass current_state_query.read_calls_reference unchanged to wallet_batch_eth_call.

• get_pool_liquidity

  Return tick-level net liquidity deltas for one exact chain/core/pool ID. Accumulate the deltas in ascending tick order to reconstruct active liquidity depth.

• list_pool_keys

  Discover initialized pools for one chain and Core deployment, ordered by pool_id with keyset pagination, optionally filtered by token, pair or extension. Each pool_id is re-derived from its PoolKey and each row carries the indexed state (null until indexed).

• derive_pool_id

  Pack or accept an exact PoolKey config and derive pool_id = keccak256(abi.encode(PoolKey)). The uint64 Q64 fee is string-only so JavaScript cannot silently round it.

• decode_pool_config

  Decode the packed bytes32 extension, exact uint64 Q64 fee, concentrated/stableswap discriminator, and tick spacing or stableswap parameters. The fee is never returned as a JSON number.

• get_position

  Hydrate one owner position: pool key, bounds, liquidity, pool state, NFT metadata, history, rewards, token prices, and a pending read of current principal, fees or Ve33 rewards and owner. Pass current_state_query.read_calls_reference as a value to wallet_batch_eth_call in the sam

• get_position_pool_candidates

  List indexed pools for a token pair with verified PoolKeys and pool IDs, Core generation, pool type, extension, 24-hour TVL/volume/fee stats and the right Positions or Ve33Positions manager.

• prepare_lp_position_deposit

  Prepare a v3 position mint or add_liquidity, initializing a new pool at initial_tick when requested, with every approval, refund and cleanup step. Ekubo ticks use base 1.000001, so tick = ln(price in base units) x 10^6 and a Uniswap-style 1.0001 calculation is 100x too small. The

• prepare_lp_position_earnings_claim

  Prepare collection of all accrued fees from an owned standard position or rewards from an owned Ve33 position, keeping its liquidity and NFT. Run its current_state_query first: require every inner call to succeed and the decoded owner to equal expected_owner, and pass the decoded

• prepare_lp_position_withdraw

  Prepare partial or full withdrawals from one or more owned positions in one plan, collecting fees or Ve33 rewards and keeping the NFTs. Read each position's current_state_query first and request no more liquidity than it decodes; require every inner call to succeed and owner to e

• prepare_wrap_unwrap

  Prepare a direct wrapped-native deposit or withdrawal on a chain with a verified wrapped native token. The response names the wrapped token, which is not WETH everywhere (BNB Chain wraps BNB, Polygon POL, Monad MON).

• prepare_transfers

  Prepare one atomic-capable plan of 1 to 4,096 ordered native, ERC-20, ERC-721 and ERC-1155 transfers on one EVM chain, mixed freely. Returns a compact summary and the execution_plan_reference.

• prepare_lp_position_transfer

  Prepare the exact safeTransferFrom transaction for an owned LP position and include pending ownership validation. The position, liquidity, and unclaimed earnings move together.

• prepare_fix_pool_price

  Run the interface-equivalent phased fix-price workflow: provide exact pending pool-price read calldata, then exact router quote calldata, then approvals and target-price execution calldata. The wallet never constructs a route or transaction.

• prepare_twamm_order

  Prepare one or more TWAMM order splits with approvals and native value as one atomic batch. details.token_id is the order's id before anything is sent: keep it, because prepare_twamm_order_collection and prepare_twamm_order_stop are keyed by it and orders are not enumerable by ow

• prepare_twamm_order_collection

  Prepare collection of every selected order key through the exact current or legacy Orders manager, as one atomic batch of decodable steps, with pending owner validation.

• prepare_twamm_order_stop

  Prepare the interface's complete stop flow: collect every selected order and decrease every still-active sale rate in one atomic batch of decodable steps.

• prepare_twamm_virtual_orders

  Prepare the permissionless lockAndExecuteVirtualOrders maintenance call for a current or legacy TWAMM pool.

• prepare_auction_create

  Pack the exact interface auction config and prepare mint plus sellAmountByAuction, including approval or native value and deterministic token ID.

• prepare_auction_complete

  Prepare permissionless auction completion and, when necessary, graduation-pool initialization in the same atomic batch.

• prepare_auction_creator_proceeds

  Prepare collection of creator proceeds for an auction NFT with pending owner validation.

• prepare_manual_pool_boost

  Compute the exact Q32 boost rates and prepare all token approvals, native value, and boost calldata used by the interface.

• prepare_oracle_capacity_expansion

  Prepare the interface's permissionless Oracle expandCapacity call for one ERC-20 token.

• prepare_approval_revocations

  Prepare every approve(spender,0) as an exact ordered multi-transaction execution plan. The wallet must not discover or construct the transaction list.

• get_rewards_claims_by_owner

  Fetch canonical reward-claim records and supply the exact per-chain isClaimed/isAvailable eth_call list used by the interface before preparing claim transactions.

• prepare_rewards_claim

  Prepare one Incentives claim or the interface's allow-failure Multicall3 aggregate for multiple claims.

• prepare_revenue_buybacks

  Prepare the exact selected ended-order collections, protocol-fee withdrawals, and token rolls in interface order within one atomic batch of decodable steps.

• prepare_ve33_increase_stake

  Prepare the exact approval/native value and increaseStakeAmount call while preserving the existing vote and fee accounting. Non-destructive: the vote is resized rather than cleared, no fees are discarded, and no NFT is burned. The added stake takes the NFT's existing lock end, so

• prepare_ve33_merge

  Prepare fee-safe merging of one or more source NFTs into a destination, including required claims and the selected resulting vote in one atomic batch of decodable steps. Destructive to the sources: each source's stake moves to the destination, its vote is cleared, and the source

• prepare_ve33_withdraw

  Prepare fee-safe withdrawal of an expired ve-token stake, claiming the active pool first when voted and returning pending owner/stake validation. Ends the position: the stake leaves Ve33 and returns to the owner and the vote is cleared. Only an expired stake can be withdrawn — Ve

• get_liquidity_opportunities

  Return the interface's boosted-fee, incentive and projected ve(3,3)-emission opportunities ranked by APR, with actionable pools or pool-discovery handoffs, freshness and risk context. Call this before asking the user to choose a pair. APR is an annualized snapshot, not guaranteed

• prepare_pool_initialization

  Prepare one permissionless maybeInitializePool transaction for a v3 PoolKey and initial tick; prepare_lp_position_deposit with pool_initialized=false does the same atomically with the mint.

• get_aave_v3_markets

  Locally return six major Aave V3 core deployments and a bounded set of popular reserve, aToken, and variable-debt-token addresses from a pinned official Aave address-book snapshot. This tool makes no RPC, indexer, API, or other network request. For live rates, caps, pause state,

• prepare_aave_v3_supply

  Prepare a fixed-market Aave V3 Pool supply with an exact ERC-20 approval, supply calldata, and allowance cleanup as one atomic wallet plan. No live balance, allowance, reserve, cap, pause, or rate data is queried.

• prepare_aave_v3_withdraw

  Prepare a direct Aave V3 Pool withdrawal for a supported fixed reserve. Pass uint256 maximum as amount to request the available aToken balance. The wallet establishes balance, health-factor, collateral, and liquidity validity by exact simulation.

• prepare_aave_v3_borrow

  Prepare a direct Aave V3 variable-rate borrow from a supported fixed reserve, including optional on-behalf-of credit delegation. This server does not query collateral, delegation, health factor, caps, or available liquidity.

• prepare_aave_v3_repay

  Prepare variable-debt repayment with underlying tokens or sender-owned aTokens. Underlying repayment carries an exact ERC-20 approval and cleanup in one atomic plan; uint256 maximum requests all available debt.

• prepare_aave_v3_collateral

  Prepare setUserUseReserveAsCollateral for a supported fixed reserve. Disabling collateral can reduce health factor or revert when open debt needs it, so exact wallet simulation is mandatory.

• prepare_aave_v3_emode

  Prepare setUserEMode with a caller-supplied current uint8 category ID; zero disables eMode. Discover live category configuration through Aave's public GraphQL API directly, because this server makes no data or RPC request.

• get_morpho_vaults

  Locally return a bounded, pinned catalog of listed Morpho Vault V2 deployments plus official direct-discovery guidance. This tool makes no API, RPC, indexer, or other network request. The agent must query Morpho's public GraphQL API and current onchain state directly, then inters

• prepare_morpho_vault_deposit

  Prepare an exact-approval Morpho Vault V2 deposit through the official SDK's VaultBundlesV1 route. The caller supplies a fresh RAY-scaled max share price, which is enforced onchain against ERC-4626 share-price inflation; shares are minted to the sender and the server performs no

• prepare_morpho_vault_withdraw

  Prepare a direct Morpho Vault V2 withdrawal for an exact underlying-asset amount from a fixed vault. Current shares, liquidity, permissions, and vault state are established by direct agent discovery and exact wallet simulation.

Basischecksi

Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026

• ✓ Bestanden

  Entwickler passt zum Repo

  Der Registry-Name wurde mit dem GitHub-Konto EkuboProtocol bestätigt, dem das Repo gehört

• … Noch nicht geprüft

  Wird noch gepflegt

  Dieses Repo haben wir noch nicht von GitHub gelesen

• … Noch nicht geprüft

  Hat eine Lizenz

  Dieses Repo haben wir noch nicht von GitHub gelesen

• ✓ Bestanden

  Endpunkt antwortet

  Antwort in 953 ms (HTTP 200)

• – Nicht zutreffend

  Anmeldung mit OAuth

  Keine Anmeldung nötig

• ✓ Bestanden

  Keine versteckten Anweisungen in Tool-Beschreibungen

  Wir haben 60 Tool-Beschreibungen gelesen und keine versteckten Anweisungen an die KI gefunden

Im Vergleich mit anderen in Krypto & Blockchaini

• Mehr Sterne als 0 % der anderen 1612 Server in dieser Kategorie
• Neuer in der Registry veröffentlicht als 95 % der anderen 1612 Server in dieser Kategorie
• Basischecks gleich gut wie oder besser als bei 100 % der anderen 1612 Server in dieser Kategorie

Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.

Alternativen

Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.

So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti

README vom Entwickler