Skip to main content
Glama

Quidli Connect

by io.github.Quidli
OverviewDiscussionsAdmin

Send Tokens (Smart Send)

connect_drop
DestructiveIdempotent

Execute a Smart Send from the API key owner Connect embedded wallet. EVM: batch native or ERC-20 (need native gas plus the token). Solana (chainId 1399811149): SOL or SPL from the Solana embedded wallet; packs up to 20 native or 10 SPL recipients per transaction. Social recipient types: email, phone, telegram, discord, farcaster, twitter, github (id or username). linkedin and slack are not on /drop — use connect_lookup first, then type wallet. After connect_lookup, EVM payouts use ethWalletAddress (never solWalletAddress); Solana payouts use solWalletAddress (never ethWalletAddress). Social types on /drop resolve server-side; for type wallet, pass the resolved payout address for the target chain. Omit tokenContract or set it to null for the native token; pass an ERC-20 contract or SPL mint otherwise — do not use the zero address. Amounts are smallest-unit integer strings (ETH 18 decimals, SOL 9, USDC usually 6). Solana native (tokenContract null): no ATA. Sending to a recipient without an existing funded account requires amount ≥ 890880 lamports (rent-exempt minimum for a system account); that SOL stays with the recipient. Below that the tx fails. Sender also pays a ~5000-lamport fee. Solana SPL: tokens sit in Associated Token Accounts (ATA), not on the wallet pubkey. Recipients need not already hold the token — the API prepends CreateIdempotent. The sender (not the recipient) pays ~2039280 lamports (~0.002039 SOL) rent per newly created dest ATA, plus tx fees, on top of the token amount (which can be as small as 1 unit). A 400 "Insufficient funds" on SPL is often missing SOL for ATA rent, not missing USDC. Token-2022 is not supported; USDC mint is EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. Always call connect_drop_balance first. Returns 201 when submitted or 202 when recipients still processing — retry with the same idempotencyKey.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainIdYesEVM chain ID or 1399811149 for Solana mainnet
recipientsYesWallet or social recipients (all wallet or all social, no mix). Social types: email, phone, telegram, discord, farcaster, twitter, github (numeric id or username). linkedin and slack are not supported — use connect_lookup first, then type wallet. Optional amountInWei per recipient uses the same smallest-unit rules as amountInWeiPerRecipient. On EVM, wallet ids are 0x addresses; on Solana, base58 pubkeys. Social lookup payouts use ethWalletAddress on EVM and solWalletAddress on Solana.
trustFilterNoKeep only recipients in the sender EAS trust graph.
tokenContractNoEVM ERC-20 contract or Solana SPL mint. Omit or null for the native token (ETH/POL/AVAX, or SOL on 1399811149). Do not use the zero address.
idempotencyKeyYes
ignoreFailedRecipientsNoWhen true, send to recipients that resolved successfully and skip failed lookups.
amountInWeiPerRecipientNoUniform amount in smallest units. Native ETH uses 18 decimals; SOL uses 9; ERC-20/SPL uses token decimals from connect_drop_balance (USDC usually 6). Omit when setting amountInWei on each recipient.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: per-chain gas/rent economics (890880 lamports rent-exempt minimum, ~2039280 lamports ATA rent paid by sender), ATA creation via CreateIdempotent, the cryptic 400 'Insufficient funds' meaning, and the 201/202 return-and-retry-with-same-idempotencyKey behavior. This is exactly the destructive/irreversible detail an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the action, but the body is a dense run-on that repeats schema content ('Omit tokenContract or set it to null', 'do not use the zero address') and cycles back through rent/fee details. Much of it earns its place, but structure and trimming are lacking.

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 complex, destructive, multi-chain, 7-parameter tool with nested recipients, the description covers recipient types, mixed-wallet constraints, amounts, rent/fee edge cases, error interpretation, and return codes. Nothing essential to correct invocation is missing.

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 high (86%), so the baseline is 3, but the description adds real meaning: omit/null tokenContract for native, smallest-unit amounts per chain (ETH 18, SOL 9, USDC 6), and the ethWalletAddress vs solWalletAddress routing rule after connect_lookup. It clarifies semantics the schema alone does not.

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?

Opens with a specific verb+resource+scope: 'Execute a Smart Send from the API key owner Connect embedded wallet.' It further disambiguates from siblings by naming connect_lookup and connect_drop_balance and describing chain/recipient handling, so an agent can distinguish it immediately.

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 explicit routing rules ('Always call connect_drop_balance first', and for linkedin/slack 'use connect_lookup first, then type wallet'), which is clear context for use. It lacks a general when-not-to-use statement or comparison against other transfer tools, so it falls short of the 5 bar.

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

All Quidli Connect 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