Skip to main content
Glama
Sign In

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. ERC-721: set tokenStandard to erc721, tokenContract to the collection, and tokenId on each recipient. Do not send an amount. One safeTransferFrom per NFT. ERC-1155: set tokenStandard to erc1155, tokenContract to the contract, and tokenId plus tokenAmount (quantity, at least 1) on each recipient. The same id can go to several recipients. One safeTransferFrom per recipient. An EIP-7702 delegation signed before the matching standard must be replaced. Smart Send wallets enrolled on the previous Privy policy must re-enable Smart Send. Always call connect_drop_balance first. Returns 201 when submitted or 202 when recipients still processing — retry with the same idempotencyKey.

Input 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, ERC-721 collection, ERC-1155 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.
tokenStandardNoSet to erc721 to send one NFT per recipient (tokenId, no amount). Set to erc1155 to send a quantity of one id per recipient (tokenId and tokenAmount). Omit for native, ERC-20, or SPL. An existing EIP-7702 delegation must be replaced first. A Smart Send wallet on the previous Privy policy must re-enable Smart Send.
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. Changed4 schema fields changed
    • addedInput schema / properties / recipients / items / properties / tokenAmount
      Added value: +{
+  "description": "ERC-1155 quantity of tokenId. Required on every recipient when tokenStandard is erc1155. At least 1. The same id may be sent to several recipients.",
+  "pattern": "^\\d+$",
+  "type": "string"
+}
    • addedInput schema / properties / recipients / items / properties / tokenId
      Added value: +{
+  "description": "ERC-721 or ERC-1155 token id. Required on every recipient when tokenStandard is erc721 or erc1155.",
+  "pattern": "^\\d+$",
+  "type": "string"
+}
    • changedInput schema / properties / tokenContract / description
      Previous value: -"EVM 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."New value: +"EVM ERC-20 contract, ERC-721 collection, ERC-1155 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."
    • addedInput schema / properties / tokenStandard
      Added value: +{
+  "description": "Set to erc721 to send one NFT per recipient (tokenId, no amount). Set to erc1155 to send a quantity of one id per recipient (tokenId and tokenAmount). Omit for native, ERC-20, or SPL. An existing EIP-7702 delegation must be replaced first. A Smart Send wallet on the previous Privy policy must re-enable Smart Send.",
+  "enum": [
+    "erc721",
+    "erc1155"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The annotations only declare destructive/idempotent/openWorld, but the description adds concrete operational behavior an agent could not infer: the 890880-lamport rent-exempt minimum for Solana native sends, the ~2039280-lamport ATA rent paid by the sender, the ~5000-lamport fee, the CreateIdempotent prepend so recipients need not hold the token, the misleading 'Insufficient funds' 400 diagnosis, and the EIP-7702 / Privy policy preconditions. This is exactly the failure-mode context mutations need.

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?

The length is earned by genuine complexity (8 params, nested recipients, two chains, three token standards), and the critical constraints are front-loaded before the edge cases. It reads as one dense block with no headings, and the EIP-7702 / Privy-policy caveats are duplicated verbatim in the tokenStandard schema description, which is minor waste.

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 destructive, multi-chain, multi-standard transfer tool with no output schema, the description covers everything an agent needs before calling: asset-type branching, rent and fee costs, per-recipient tokenId/tokenAmount requirements, and what the 201/202 statuses mean. Nothing material is left to inference.

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 already 88%, so the baseline is 3; the description still adds meaning beyond it by fixing decimal conventions per asset (ETH 18, SOL 9, USDC usually 6), specifying that tokenContract must be omitted or null for native and must never be the zero address, and stating that Solana native sends create no ATA. It stops short of documenting idempotencyKey and trustFilter beyond what the schema says.

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 and resource: 'Execute a Smart Send from the API key owner Connect embedded wallet.' It immediately scopes the tool by chain (EVM vs Solana chainId 1399811149) and by asset type (native, ERC-20, SPL, ERC-721, ERC-1155), which is far more than a restatement of the name.

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

Usage Guidelines5/5

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

Gives an explicit prerequisite ('Always call connect_drop_balance first'), an explicit routing rule away from this tool ('linkedin and slack are not on /drop — use connect_lookup first, then type wallet'), and retry guidance tied to the 201/202 response codes. The when-to-use and when-not-to-use conditions are both stated.

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