Skip to main content
Glama

Quidli Connect

by li.quid.connect.mcp
OverviewDiscussionsAdmin

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. Changed1 schema field changed
    • addedInput schema / properties / trustFilter
      Added value: +{
+  "additionalProperties": false,
+  "description": "Keep only recipients in the sender EAS trust graph.",
+  "properties": {
+    "context": {
+      "description": "Restrict to this trust context. Omit to match any.",
+      "type": "string"
+    },
+    "mode": {
+      "description": "require = fail if anyone is outside the graph; skip = drop them",
+      "enum": [
+        "require",
+        "skip"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "mode"
+  ],
+  "type": "object"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / recipients / description
      Previous value: -"Wallet or social recipients (all wallet or all social, no mix). Optional amountInWei per recipient uses the same smallest-unit rules as amountInWeiPerRecipient. On Solana, wallet ids are base58 pubkeys; social lookup pays solWalletAddress."New value: +"Wallet 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."
    • changedInput schema / properties / recipients / items / properties / type / enum
      Previous value: -[
-  "email",
-  "phone",
-  "telegram",
-  "discord",
-  "farcaster",
-  "twitter",
-  "github",
-  "linkedin",
-  "slack",
-  "wallet",
-  "username"
-]New value: +[
+  "email",
+  "phone",
+  "telegram",
+  "discord",
+  "farcaster",
+  "twitter",
+  "github",
+  "wallet"
+]
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations, the description discloses rich behavioral detail: 201/202 return semantics, retry with the same idempotencyKey, Solana ATA rent costs, the ~5000-lamport fee, the 'Insufficient funds' failure pattern, and Token-2022 not being supported. This substantially exceeds what the annotations alone provide.

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 description is long, but it covers two blockchain paths, fee math, address selection, social recipient caveats, and retry behavior. It is front-loaded with the main action and well-organized by topic. Some content duplicates the schema, but the duplication emphasizes high-risk constraints rather than pure filler.

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?

Given 7 parameters, nested objects, two chains, social recipient resolution, and no output schema, this description is remarkably complete. It supplies prerequisites, return codes, retry guidance, rent/fee examples, and address-field selection rules. An agent has what it needs to make a correct first call.

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 86%, so the schema already documents most parameters. The description still adds critical nuance: omit tokenContract/null for the native token, 'do not use the zero address', smallest-unit integer strings with decimal examples, and Solana rent constraints tied to amounts. It enriches the tokenContract and amount parameters without needing to restate every field.

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?

The description opens with a specific verb and resource: 'Execute a Smart Send from the API key owner Connect embedded wallet.' It then clearly distinguishes EVM and Solana behavior and recipient types, making it unmistakable what connect_drop does versus siblings like connect_drop_balance or connect_lookup.

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?

It explicitly says 'Always call connect_drop_balance first,' giving a clear prerequisite. It also routes unsupported recipient types ('linkedin and slack are not on /drop') to connect_lookup first, and explains which address field to use after lookup. This is strong when-to-use guidance for a complex cross-chain tool.

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